преимущества erlang-а? - Декларативное программирование

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

P>Немного перефразирую свой предыдущий вопрос:
P>Хотелось бы услышать от тех, кто РЕАЛЬНО, использует Erlang в своих проектах, КАКИЕ ощущения от его использования, какие СИЛЬНЫЕ стороны от использования erlang-а ВЫ для СЕБЯ подметили, какие неудобства... ????

Плюсы Ерланга :
Очень легковесные процессы. Я запускал на домашней машине 200 000 процессов без заметных тормозов.
Быстрый и удобный обмен сообщениями. На Пне-4 в среднем занимает 100-300 наносекунд ( в пределах одной виртуальной машины, естественно )
Весьма удобный механизм MATCH PATTERH ( сравнение/совпадение по образцу )
Функции высшего порядка
Очень легкая работа в распределенной среде
Компактный, легко читаемый и достаточно удобопонятный код
Модульная структура, и есть возможность обьединения в пакеты
Весьма изобильные библиотеки. Я построил компилятор спец. языка, пользуясь только штатными средствами Ерланга, за 3 месяца

Минусы :
Как числомолотилка — не покатит. С целыми числами все хорошо, и с большими целыми тоже, а вот производительность на операциях с плавающей точкой — так себе
Нет штатного способа запихать все в один выполняемый файл ( несколько неудобно )
Файловый ввод/вывод мог бы и побыстрее быть. TCP, как ни странно, весьма быстр.

P>Синтаксис я пока не осилил, но если это динамический типизируемый язык (типа Ruby или Smalltalk) — значит должна быть мега-выразительность языка, но что-то я опять же не заметил, может все таки плохо смотрел?
Ерланг ОЧЕНЬ выразителен. Вот пример, который я делал для изучающих язык . Это поиск кратчайшего пути в лабиринте. На мой взгляд, достаточно наглядно и просто. И студенты быстро прониклись...

-module(pfind).
-export([start/0,start/1]).

start()->
start("place.data").

start(Fname)->
Dic=load_data(Fname),
Ldic=link_data(Dic),
StartP=find_pos(Ldic,$a),
EndP=find_pos(Ldic,$b),
io:fwrite("~nstart=~w end=~w ~n",[StartP,EndP]),
IList2=emit_wave(Ldic,[{StartP,0}]],0),
Path=unwind(IList2),
io:fwrite("~nPath=~w ~n",[Path]),
io:fwrite("~nPath length=~w ~n",[length(Path)]),
io:fwrite("~n",[]).

%%% Load data from file into hash
load_data(Fname)->
{ok,Bin1}=file:read_file(Fname),
L1=string:tokens(binary_to_list(Bin1),[10,13]),
{_,Dic}=lists:foldl(fun(Line,{Y,Dic1})->
{_,Dic3}=lists:foldl(fun(C,{X,Dic2})->
{X+1,dict:store({X,Y},C,Dic2)}
end,{0,Dic1},Line),
{Y+1,Dic3}
end,{0,dict:new()},L1),
Dic.

%%%%%% Build links between cells
link_data(Dic)->
dict:fold(fun({X,Y}=K,V,Dic1)->
L1=[{X-1,Y-1},{X-1,Y},{X-1,Y+1},{X,Y+1},{X+1,Y+1},{X+1,Y},{X+1,Y-1},{X,Y-1}],
L2=[Key||Key<-L1,dict:is_key(Key,Dic)],
dict:store(K,{V,L2},Dic1)
end,dict:new(),Dic).

%%%% Find first occurence of tag
find_pos(Dic,C)->
[Pos]=[K||{K,{V,_}}<-dict:to_list(Dic),V==C],
Pos.

%%%%%%% Emit wave
emit_wave(LDic,[Front|_]=IList,Num)->
case step(LDic,Front,[],Num) of
{done,Res}->[Res]|IList];
{LDic1,NF}->emit_wave(LDic1,[NF|IList],Num+1)
end.

%%%%%% Check all points neighbours on wave front
step(LDic,[],NF,_Num)->{LDic,NF};
step(LDic,[{Pt,_}|Rest],NF,Num)->
{_V,Neibs}=dict:fetch(Pt,LDic),
case step_one(LDic,Neibs,NF,Num,Pt) of
{done,Res}->{done,Res};
{LDic1,NF1}->step(LDic1,Rest,NF1,Num)
end.

%%%%%% Check and mark cells around one point
step_one(LDic,[],NF,_Num,_Parent)->{LDic,NF};
step_one(LDic,[Pt|Rest],NF,Num,Parent)->
{V,NB1}=dict:fetch(Pt,LDic),
case V of
$b->{done,{Pt,Parent}};
32->step_one(dict:store(Pt,{Num,NB1},LDic),Rest,[{Pt,Parent}|NF],Num,Parent);
_->step_one(LDic,Rest,NF,Num,Parent)
end.

%%%%%%% Backtrace path from finish to start
unwind([{Coord,Par}]|Rest])->unwind(Par,Rest,[Coord]).
unwind(_Par,[],Path)->Path;
unwind(Par,[Front|Rest],Path)->
[{Coord,Parent}|_]=[{C,P}||{C,P}<-Front,C==Par],
unwind(Parent,Rest,[Coord|Path]).

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

VD>>Мне вот интересно, а на чем написан рантайм Эрлэнга? Сдается мне, что все те же С/С++.
G> Только С, и никаких ++. Собственно, как и у большинства других компиляторов и сред выполнения.

Компилятор Эрланга сделан на эрланге. По крайней мере, его бОльшая часть. Парсер с лексером — точно.

Вы ожидали чего-то другого?

А рантайм, разумеется, на plain C. Было бы странно увидеть там другой язык.

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

G>Компилятор Эрланга сделан на эрланге. По крайней мере, его бОльшая часть. Парсер с лексером — точно.
Это я криво сформулировал ответ. Вопрос был о рантайме — его я и имел в виду

G>А рантайм, разумеется, на plain C. Было бы странно увидеть там другой язык.
Есть некие странные поделия, в коих используются ++. Но их весьма мало

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

G>Компилятор Эрланга сделан на эрланге. По крайней мере, его бОльшая часть. Парсер с лексером — точно.
Сейчас посмотрел — целиком на нем. И HIPE тоже.
На С++ в рантайме есть один модуль для КОРБЫ.

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

G> Весьма изобильные библиотеки. Я построил компилятор спец. языка, пользуясь только штатными средствами Ерланга, за 3 месяца
Дык

G>1) Операции со строками — слабое место Erlang.

Но все же ejabberd как-то справляется

G>Из пропущенных плюсов самый важный — binaries. Языку нет равных в описании бинарных данных и протоколов, сериализации и прочего. В этом он рвет всех, благодаря binaries.

Хммм, а C++ ?

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

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

VD>>Вот только ты забыл добавить следущие характеристики с которыми не все согласны:
VD>>9. Интерпретирвемый язык.

WF>А как же HiPe?

Ну да

. А насчет "отсутствия статической типизации" можно было бы сказать "Dyalizer".

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

G>>1) Операции со строками — слабое место Erlang.

A>Но все же ejabberd как-то справляется

И не только он

. Так же совершенно пострясяюще справляется yaws.
И меня это сильно удивляет

. Вспоминается анекдот про летающих крокодильчиков в цирке.

Короче, пытливому уму нет препятствий. "Были бы крылья, разбить можно", как говорил один из персонажей Duck Tales.

Но тезиса это не снимает. Написать быстрый код, работающий со строками — не самая прямолинейная задача. Надо либо переходить от строк к атомам, либо к binaries. Так, кстати, и сделано в парсерах XML для Erlang. Так они и справляются.

G>>Из пропущенных плюсов самый важный — binaries. Языку нет равных в описании бинарных данных и протоколов, сериализации и прочего. В этом он рвет всех, благодаря binaries.

A>Хммм, а C++ ?

Даже не смешно. Посоревнуемся?

В этом вопросе — готов спорить на деньги. Впрочем, покажу сначала, с чем придется соревноваться. Я ж не зверь, все-таки — надо предупредить.

-define(IP_VERSION, 4).
-define(IP_MIN_HDR_LEN, 5).

DgramSize = size(Dgram),
case Dgram of 
    <<?IP_VERSION:4, HLen:4, SrvcType:8, TotLen:16, 
      ID:16, Flgs:3, FragOff:13,
      TTL:8, Proto:8, HdrChkSum:16,
      SrcIP:32,
      DestIP:32, RestDgram/binary>> when HLen >= 5, 4 * HLen =< DgramSize ->
            OptsLen = 4*(HLen - ?IP_MIN_HDR_LEN),
            <<Opts:OptsLen/binary, Data/binary>> = RestDgram,
    ...
end.

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

G> Дык

, Когда в основу библиотеки ложится значительная часть фреймворка промышленного коммутатора AXD301, то получается весьма изобильно. Как вам, например, наличие в стандартной библиотеке полного стека мультимедийных протоколов (Megaco)? Или распределенной отказоустойчивой базы данных (mnesia)? А вебсервера (inets)? И все в исходниках.
Пока не встречал людей, которые используют Мегако. И задачи с ним не попадались. Вот ASN.1 другое дело — вещь популярная и универсальная. Мнезию использую часто, но для сильно больших баз собираюсь приделать к ней back-end BERKELEY DB, чтоб Мнезия обрабатывала логику только верхнего уровня.

G>Все не так плохо, кстати. Hipe компилирует плавающую запятую по человечески, если на забыть поставить guard на float.
G>В Erlang maillist есть люди, которые рещают на Erlang DSP-задачи, и производительностью довольны.
У меня почему-то получается так, что задачи под Юниксами не нуждаются в float операциях, а вот под Вынями, где HIPE не собран, занимаются расчетами интенсивно

G>Но — если задача состоит в основном из числодробления — то Erlang все равно не лучший выбор.
Именно. Для этого есть Окамл, Сисал, Фортран...

G>> Нет штатного способа запихать все в один выполняемый файл ( несколько неудобно )
G>Есть работы в этом направлении. Я их не отслеживаю — но скоро все будет хорошо. Если не уже.
Да ? Я думал, что как Джо Армстронг на это поклал, то и работ никаких было

G>Пропущен один серьезный недостаток. Даже два.

G>1) Операции со строками — слабое место Erlang. Чтобы добиться хорошей скорости, надо использовать binaries для представления строк. По умолчанию, если написать "прпропро" — это будет список целых чисел. Оверхэд на ровном месте в 8 раз. Erlang — не самый лучший выбор для строковых манипуляций, если задача состоит только из них. Он не конкурент перлу.
Это по памяти...А по быстродействию — очень даже хорошо получается !

G>2) Массивы. В языке нет средств деструктивного изменения массивов. Это — реально плохо и неудобно, так как длинные массивы тормозят.
Вот чего не надо ! Принцип Once-Bounded Variable очень полезен, и спасает от многих глюков. Зачем вообще нужны очень большие списки ( или имелся в виду dict ) ?

G>Из пропущенных плюсов самый важный — binaries. Языку нет равных в описании бинарных данных и протоколов, сериализации и прочего. В этом он рвет всех, благодаря binaries.
Это да — но для очень некоторых применений. Я их использовал широко при работе с железом, но вот последние полгода бинарисы мне совершенно не нужны

G>Впрочем, покажу сначала, с чем придется соревноваться. Я ж не зверь, все-таки — надо предупредить.

По-моему тут демонстрируется pattern-mathcing и binding

А само описание битовых полей тут очень похоже на C++ ,кажется

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

G>>Из пропущенных плюсов самый важный — binaries. Языку нет равных в описании бинарных данных и протоколов, сериализации и прочего. В этом он рвет всех, благодаря binaries.

A>Хммм, а C++ ?
Вах ! Когда, после долгого писания классов для обмена с левыми устройствами и системами по левым протоколам на С++, я использовал Ерланг, меня обуяло Щастье ! Обычное соотношение количества строк С++/Ерланг около 6, но для таких вещей — все 20
Да и скорость, как ни странно, часто бывает выше для Ерланга. Это за счет более эффективной логики обработки ( соответственно, не очень эффективной для С++ ) 8))

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

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

G>> Дык

, Когда в основу библиотеки ложится значительная часть фреймворка промышленного коммутатора AXD301, то получается весьма изобильно. Как вам, например, наличие в стандартной библиотеке полного стека мультимедийных протоколов (Megaco)? Или распределенной отказоустойчивой базы данных (mnesia)? А вебсервера (inets)? И все в исходниках.
G> Пока не встречал людей, которые используют Мегако. И задачи с ним не попадались. Вот ASN.1 другое дело — вещь популярная и универсальная. Мнезию использую часто, но для сильно больших баз собираюсь приделать к ней back-end BERKELEY DB, чтоб Мнезия обрабатывала логику только верхнего уровня.

Это уже сделали ребята из Synapse, они доклад делали на эту тему на конференции. Тока не знаю, выложили ли они исходники. Говорят, к мнезии довольно легко прикрутить backend.

G>>Пропущен один серьезный недостаток. Даже два.

G>>1) Операции со строками — слабое место Erlang. Чтобы добиться хорошей скорости, надо использовать binaries для представления строк. По умолчанию, если написать "прпропро" — это будет список целых чисел. Оверхэд на ровном месте в 8 раз. Erlang — не самый лучший выбор для строковых манипуляций, если задача состоит только из них. Он не конкурент перлу.
G> Это по памяти...А по быстродействию — очень даже хорошо получается !

Возможно. Но в конфе пришли к выводу, что для строк рулят binaries.

G>>2) Массивы. В языке нет средств деструктивного изменения массивов. Это — реально плохо и неудобно, так как длинные массивы тормозят.
G> Вот чего не надо ! Принцип Once-Bounded Variable очень полезен, и спасает от многих глюков. Зачем вообще нужны очень большие списки ( или имелся в виду dict ) ?

Надо! Попробуй заведи тупл размером в 100 тыщ элементов (это аналог массива). И сделай ему несколько setelement-ов.

G>>Из пропущенных плюсов самый важный — binaries. Языку нет равных в описании бинарных данных и протоколов, сериализации и прочего. В этом он рвет всех, благодаря binaries.
G> Это да — но для очень некоторых применений. Я их использовал широко при работе с железом, но вот последние полгода бинарисы мне совершенно не нужны

Строки. Строки. И еще раз строки. А также сериализация. Плюс — binaries не копируются при передаче от процесса к процессу в качестве мессаги — оч. полезное свойство.

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

G>>Впрочем, покажу сначала, с чем придется соревноваться. Я ж не зверь, все-таки — надо предупредить.

A>По-моему тут демонстрируется pattern-mathcing и binding

Конечно. А еще тут демонстрируются binaries, на которых происходит и то и другое.

A>А само описание битовых полей тут очень похоже на C++ ,кажется

Похоже

Ну мало ли что на что похоже — ты берешься написать программу короче и понятнее — на С++?

Даже не так. Пусть у тебя есть некие объекты, и бинарный протокол. И тебе надо написать сериализацию этих объектов. Посмотрим, на что это будет похоже в С++ и в Erlang?

Или и так понятно? Я вот писал и то, и другое, причем больше на С++. Разницу представляю. Она должна получиться раза в 4 — суммарно.

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

G>> Это по памяти...А по быстродействию — очень даже хорошо получается !

G>Возможно. Но в конфе пришли к выводу, что для строк рулят binaries.
Странно...Сколько использую, для типично строчных операций — строки и быстрее. Для типично байтовых — понятно, быстрее бинарисы. как пример :
getb(Out,<<L,D:L/binary,R/binary>>)->getb([proceed(D)|Out],R).

G>Надо! Попробуй заведи тупл размером в 100 тыщ элементов (это аналог массива). И сделай ему несколько setelement-ов.
Гм. А зачем такое ? Я дикт заведу, или в етс положу. Это уже архитектурные проблемы

G>Строки. Строки. И еще раз строки. А также сериализация. Плюс — binaries не копируются при передаче от процесса к процессу в качестве мессаги — оч. полезное свойство.
При shared куче — вообще ничего не копируется

A>>По-моему тут демонстрируется pattern-mathcing и binding

G>Конечно. А еще тут демонстрируются binaries, на которых происходит и то и другое.

A>>А само описание битовых полей тут очень похоже на C++ ,кажется

G>Похоже

Я, скажем вежливо, не спец в C++, я его синтаксис очень ен люблю.
Но именно в битовых полях, как мне показалось, Эрланг и плюсы одинаковы.
Т.е. я возражаю против фразы "нет равных в описании бинарных данных "

G>Ну мало ли что на что похоже — ты берешься написать программу короче и понятнее — на С++?
Нет, не берусь, но не потому что битовые поля сделаны (офрмлены, описаны) лучше — так же.
А потому что работать с ними удобнее, равно как и с другими структурами — тот самый pattern-matching и binding

Ты же не будешь говорить, что описания структур в C++ сделаны хуже описаний record'ов в Эрланге ,потому что другие средства языка позволяют с ними удобнее работать

G>>Ну мало ли что на что похоже — ты берешься написать программу короче и понятнее — на С++?
A>Нет, не берусь, но не потому что битовые поля сделаны (офрмлены, описаны) лучше — так же.
A>А потому что работать с ними удобнее, равно как и с другими структурами — тот самый pattern-matching и binding

A>Ты же не будешь говорить, что описания структур в C++ сделаны хуже описаний record'ов в Эрланге ,потому что другие средства языка позволяют с ними удобнее работать

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

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

M>Имеется в виду не только описание, но и сериализация/десериализация описанных структур — все же данные надо будет потом передавать куда-то. В этом отношении Эрланг рулит

И все же главное — изоляция процессов и возможность написания НАДЕЖНОГО софта в присутстсвии программных ошибок.

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

G>Ну да

. А насчет "отсутствия статической типизации" можно было бы сказать "Dyalizer".

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

... << RSDN@Home 1.2.0 alpha rev. 631>>

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

G> Не то чтоб совсем так. Байт-код, порождаемый компилятором, весьма быстр, И не уступит, к примеру, Жабе по скорости. И это именно КОМПИЛЯТОР.

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

Любой "быстрый" байткод в 10 и более раз медлнеее чем оптимизированный машинный.

VD>>Использовать в риалтайм системах может и можно, а вот написать на оном реалтайм-рантайм вряд ли. Хотя железо сейчас конечно многое позволяет, так что как знать.
G> Опять-таки не то говорите. Пару лет писал на Ерланге диспетчерские задачи ( мягкий реалтайм ), работу с железом... Время реакции порядка миллисекунд обеспечиваются свободно, причем на весьма дохлом железе.

Еще раз. Надо понимать разницу между понятием "риалтайм" и "быстрый". Не удивлюсь если самые тормозные интерпретаторы вроде Руби окажутся пригодными для софт-риалтам-задач. Вот только говорить о создании на таких языках софта способного конкурировать по скорости с тем что создается на компилируемых языках нельзя. А задач живущих на грани (а то и за гранью) процессорных возможностей еще ой как не мало.

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

G> Только С, и никаких ++. Собственно, как и у большинства других компиляторов и сред выполнения.

Это уже не важно. Главное, что не на самом себе.

... << RSDN@Home 1.2.0 alpha rev. 631>>

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

G>А рантайм, разумеется, на plain C. Было бы странно увидеть там другой язык.

Интересно, а почему не странно, что в Singularity рантайм написан в основном на C#? Что есть какие-то координальные различия между C# и Эрлэнг (как у языков)?

... << RSDN@Home 1.2.0 alpha rev. 631>>

M>>Имеется в виду не только описание, но и сериализация/десериализация описанных структур — все же данные надо будет потом передавать куда-то. В этом отношении Эрланг рулит

G> И все же главное — изоляция процессов и возможность написания НАДЕЖНОГО софта в присутстсвии программных ошибок.

И не только программных, но и хардварных тоже

Making reliable distributed systems in the presence of hardware errors

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

VD>Любой "быстрый" байткод в 10 и более раз медлнеее чем оптимизированный машинный.
Это верно. Но только если сравнивать голое быстродействие. А вот ежели сравнивать на реальных задачах, то появляются очень странные результаты
Кроме того, HIPE сейчас является частью стандартной библиотеки. К сожалению, код под Виндозу пока не генерит — только под Линукс и Соляру

VD>Еще раз. Надо понимать разницу между понятием "риалтайм" и "быстрый". Не удивлюсь если самые тормозные интерпретаторы вроде Руби окажутся пригодными для софт-риалтам-задач. Вот только говорить о создании на таких языках софта способного конкурировать по скорости с тем что создается на компилируемых языках нельзя. А задач живущих на грани (а то и за гранью) процессорных возможностей еще ой как не мало.
Что такое скорость ? Если приложение на С++ работает медленнее, чем на Ерланге, это о чем говорит ? О скорости кода ? Совсем не уверен

VD>Простой пример. Интерактивные игршуки. Да скрпты с успехом применяются для отработки логики в играх. Хотя игры ой как требуют скорости. Но писать движок физики или рендеринга на скриптах — это маразм. Работать конечно будет, но со скоростью черепахи.
Для этого есть биндинг к низкоуровневым вещам. На Ерланге существуют игрушки, отображение у них сделано через OpenGL/SDL

G>> Только С, и никаких ++. Собственно, как и у большинства других компиляторов и сред выполнения.

VD>Это уже не важно. Главное, что не на самом себе.
Чтобы быть точнее :
Виртуальная машина на С ( + несколько встроенных функций )
Библиотеки на Ерланге (+ небольшой С++ модуль для КОРБЫ + махонький С модуль для АСН.1 + С для криптографии)

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

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

VD>>Любой "быстрый" байткод в 10 и более раз медлнеее чем оптимизированный машинный.
G> Это верно. Но только если сравнивать голое быстродействие. А вот ежели сравнивать на реальных задачах, то появляются очень странные результаты

Это от "рельных" задач зависит. Если задача укладывается в область действия высокоуровневых библиотечкных функций, то да. А если нет, и нужно именно что на самом языке написать, то приплыли. Иначе зачем бы делали эти эксперементальные проекты на которыет тут ссылки давали рядом?

G> Кроме того, HIPE сейчас является частью стандартной библиотеки. К сожалению, код под Виндозу пока не генерит — только под Линукс и Соляру

Вот. Вот. И таких "к сожалению" море.

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

G> Что такое скорость ? Если приложение на С++ работает медленнее, чем на Ерланге, это о чем говорит ?

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

... << RSDN@Home 1.2.0 alpha rev. 631>>

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

A>Я, скажем вежливо, не спец в C++, я его синтаксис очень ен люблю.
A>Но именно в битовых полях, как мне показалось, Эрланг и плюсы одинаковы.
A>Т.е. я возражаю против фразы "нет равных в описании бинарных данных "
Дело в том, что в C++ битовые поля вообще не предназначены для сериализации. Ну т.е. вообще никак (хотя их можно для этого использовать, если хотеть проблем или не нужна переносимость). Это неудивительно, т.к. в стандарте C++ ничего не гарантируется — ни представление чисел, ни порядок битовых полей в слове, ни порядок байт. Битовые поля позволяют экономить память — это все, что они переносимо могут делать.
Ну и pattern matching'a тоже в С++ нет.
Сравнивать нечего.

Здравствуйте, VladD2, Вы писали:
VD>Вот. Вот. И таких "к сожалению" море.

Ш-ш-... Остыньте "горячие эстонские парни"

"К сожалению" море в любом языке...

G>> Что такое скорость ? Если приложение на С++ работает медленнее, чем на Ерланге, это о чем говорит ?
VD>Ни о чем. Вот если они алогоритмически эквивалентны, и оба оптимизированны, то о чем-то говорит. Вот только чудес на свете не бывает.

Вот именно что "алгоритмически эквивалентны"... здесь-то собака и порылась.
Во-первых, в большинстве задач time-китичными является не более 10% кода. Который достаточно просто уложить на стандартные библиотеки. И практически везде они этими стандартными библиотеками уже закыты. ( Исключения — задачи типа "рендеинга", но они в большинсве случаев так же оформлены в виде библиотек, но уже специализированных. )

А вот дальше уже интереснее.
Пусть есть некий time-критичный элемент алгоритма T.
И есть два алгритма верхнего уровня A и B. Причем алгоритм A вызывает элемент T 100 раз, а алгоритм B — 1 раз.
Если весь остальной код не time-критичен, то получим, что алгоритм B, быстрее на два порядка.
НО! Может оказаться так, что на том же C (C++) алгорим B писать просто нельзя.
И не потому что "невозможно", а потому что там он "слипнется" в огромный кусок "лапши"... и в результате
1) станет неотлаживаемым (или крайне долго отлаживаемым)
2) станет несопровождаемым (главное! ведь речь не о системном, а о прикладном алгоритме).

Что же касается "чистого" быстродействия то я сравнивал ОДИНАКОВЫЕ алгоимтмы типа "проверки-вычисления" (АСКУЭ-биллинг с вариантами) на erlang и borland c++ builder. Соответсвенно под виндами, и без компиляции erlanga в HIPE.
В этих условиях erlang проигрывает c++ примерно в 1,8 раза (если откомпилить c++ интеловским компиляорм разрыв станет больше — примерно 2,6). Все это весьма легко перекрывается алгоримикой.
Кстати, что касается С#... делали ребята этот алгоритм на нем (переписали c++ версию) — .Net проиграл плюсам примерно в 3 раза, а значит получается проиграл и erlang-у. Не смотря на Jit-компилятор. Уж не знаю почему (подозреваю, что if-ы там слишком навороченно обрабатываются)...

VD>Вот если услышишь слово "байт-код" и рядом не услышишь слова Jit-компилятор или пре-Jit, то сразу знай, что тебя обманывают.

Нет, погоди, так байт-код или JIT ?
Были когда-то тесты Portable.NET интерпретатора (unroller'a, преобразует MSIL в более простой промежуточный язык, и дальше, кажется, пытается что-то типа шитого кода устроить) и JIT-компилятора — и цифры были сильно разные.
А ты на все[ одну десятку лепишь

VD>Интересно, а почему не странно, что в Singularity рантайм написан в основном на C#?

Экспериментальный проект. Запрототипируют, определятся на каких процессорах это будет запускаться, определят требования к скорости — и привет. А кроме того, кстати, неплохой тест для .NET библиотек и JIT

VD>Что есть какие-то координальные различия между C# и Эрлэнг (как у языков)?
Функциональный vs императивный ? Наверное есть

А уж библиотеки у них точно разные.

VD> Иначе зачем бы делали эти эксперементальные проекты на которыет тут ссылки давали рядом?

Да просто потому что любой язык/платформа развиваются, елси не умерли.
Зайдем на MS Research и увидим там кучу экспериментальных языков для .NET
Не будем же говорить теперь, что C# отстой раз MS как убдто лихорадочно и массово опробует ему на замену все те языки ? Ведь нет?
Серьезно будет сказать по другому: есть места, где у C# (и тесно связанной с ним .NET) недостатки, и чтобы покрыть эти места Майкрософту нужны другие свои языки под .NET, что она и пытается сделать.
Идет нормальное развитие проекта. Посмотрели где в .NET могут образоваться узкие места — делают попытки их расшить. Будет удачно — в следующей версчии VisualStudio штатно будет какой-нибудь F# или Haskell.
Точно так же идет развитие Питона или Руби. Точно так же — Эрланга.

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

VD>Это от "рельных" задач зависит. Если задача укладывается в область действия высокоуровневых библиотечкных функций, то да. А если нет, и нужно именно что на самом языке написать, то приплыли. Иначе зачем бы делали эти эксперементальные проекты на которыет тут ссылки давали рядом?
Собственно, почему ? Библиотеки написаны на том же Ерланге. Согласен, хорошо написаны, и что-то соптимизировать в них сложно. Но ежели их не хватает, написать свое — проблем не представляет

G>> Кроме того, HIPE сейчас является частью стандартной библиотеки. К сожалению, код под Виндозу пока не генерит — только под Линукс и Соляру
VD>Вот. Вот. И таких "к сожалению" море.
Если взять не бинарный дистрибутив, а сорцы, и собрать под Виндозу с включенным HIPE, то все заработает...Но меня это не сильно жмет , потому и не напрягаюсь
По поводу моря сожалений — это, мягко говоря, преувеличение. Меня не устраивает 3 вещи ( не говоря о мелочах ) : медленные float операции, недоделанная генерация нативного кода, отсутствие standalone бинарника для полученного приложения

VD>А вообще, я не очень понимаю как без хоть какой-то аннотации типов получить быстрый код. А если они будут, то это уже другой язык.
запросто ! в форте и намека на типы нет, а работает ! я уж не говорю про ассемблер, где вся типизация представляет собой обман зрения 8))

VD>Ни о чем. Вот если они алогоритмически эквивалентны, и оба оптимизированны, то о чем-то говорит. Вот только чудес на свете не бывает.
Алгоритмически эквивалентны на столь разных языках ? Воистину, чудес не бывает

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

VD>>А вообще, я не очень понимаю как без хоть какой-то аннотации типов получить быстрый код. А если они будут, то это уже другой язык.
G>запросто ! в форте и намека на типы нет, а работает ! я уж не говорю про ассемблер, где вся типизация представляет собой обман зрения 8))

Да, но они не типобезапосны, в отличие от Erlang-а.

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

G>>запросто ! в форте и намека на типы нет, а работает ! я уж не говорю про ассемблер, где вся типизация представляет собой обман зрения 8))
WF>Да, но они не типобезапосны, в отличие от Erlang-а.
Ерланг тоже не безопасен в этом отношении. Самая частая причина глюков при работе в изменяющейся среде — mismatch. Например, сменился протокол работы некоей внешней системы :

func1({packet1,X})->X;
func1({packet2,X})->X+1.
если я вызову func1 с аргументом, отличающимся от этих двух видов, то что произойдет ? падение процесса !
конечно, это можно обработать. И более того, можно предотвратить :
func1(X)->io:fwrite("ERROR: ~p",[X]).

но все же это не та безопасность типов, как в Clean, например
хотя вопрос о том, что лучше — сложен и туманен

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

G>func1({packet1,X})->X;
G>func1({packet2,X})->X+1.
G>если я вызову func1 с аргументом, отличающимся от этих двух видов, то что произойдет ? падение процесса !
G>конечно, это можно обработать. И более того, можно предотвратить :
G>func1(X)->io:fwrite("ERROR: ~p",[X]).

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

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

В FORTH такого нет — там что число, что адрес памяти (где лежит тупл, например) — разницы нет. Все проверки — только вручную. То ли тебе число передали, то ли адрес некоторого тупла, то ли адрес какой-нибудь другой структуры (P.S. возможно, мои знания о FORTH-е немного устарели

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

WF>Да, но это как раз и показывает, что Erlang типобезопасен, просто типы проверяются в рантайме (в процессе паттерн-матчинга). Если функция принимает тупл, то список или число ты туда не впихнешь. Соответственно, должны быть накладные расходы на эти проверки.
Ну, если так подходить — то да. Просто обычно несколько другое под типобезопасностью подразумевается

WF>В том же Clean-е наверняка часть подобных проверок делается еще при компиляции и, соответственно, в рантайме проверки уже будут и не нужны.
Это верно. Система типов там еще более мощная, чем в Окамле. Развивался бы он еще...

WF>В FORTH такого нет — там что число, что адрес памяти (где лежит тупл, например) — разницы нет. Все проверки — только вручную. То ли тебе число передали, то ли адрес некоторого тупла, то ли адрес какой-нибудь другой структуры (P.S. возможно, мои знания о FORTH-е немного устарели

).
Я тоже не слышал о типизированном Форте 8)

Приветствую All
Изначальный вопрос был не о реализациях, а о сфере применимости и достоинствах/недостатках Ерланга
Про плюсы/минусы вроде бы понаписали уже достаточно, а вот теперь и о том, где его выгодно применять :
1. Сложная логика обработки. Вместо 1000 строк с if/switch получится 50 строк case
2. параллельность. Тут конкурентов вообще нет
3. обработка потоков данных, сложных бинарных структур
4. системы повышенной надежности, для непрерывной работы на протяжении месяцев и лет. У меня есть несколько приложений, в которых сдохшие по какой-то причине системы перезапускаются себе и работают дальше, никому не вредя.
5. когда нужна портабельность — полностью переносим, без каких-либо заморочек. У меня один и тот же код работает под Linux/FreeBSD/Windows
6. распределенные системы — опять-таки не с чем сравнивать

Если хоть что-то из этого используется в разрабатываемом приложении — Ерланг в руки !

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

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

G>>> Это по памяти...А по быстродействию — очень даже хорошо получается !

G>>Возможно. Но в конфе пришли к выводу, что для строк рулят binaries.
G> Странно...Сколько использую, для типично строчных операций — строки и быстрее. Для типично байтовых — понятно, быстрее бинарисы. как пример :
G> getb(Out,<<L,D:L/binary,R/binary>>)->getb([proceed(D)|Out],R).

Строки не могут быть быстрее при представлении в виде списка 4-х байтовых чисел. И они не быстрее.

При потребности активно манипулировать строками переходят к представлениям binaries и atom.
Посмотри исходники XML-парсеров, почитай мэйл-лист на эту тему. Например, что по этому поводу думает Армстронг.

G>>Надо! Попробуй заведи тупл размером в 100 тыщ элементов (это аналог массива). И сделай ему несколько setelement-ов.
G> Гм. А зачем такое ? Я дикт заведу, или в етс положу. Это уже архитектурные проблемы
Затем. Потому, что чтение их тупла по индексу — это O(1) с очень низкой константой. Асимптотика dict на чтении — O(N), а ets — это O(1) c копированием элемента при чтении и большой константой (это хэштаблица), плюс отсутствие сборки мусора и побочные эффекты. Их используют именно из-за убогости (вернее, отсутствия) массивов, это workaround, а не достоинство. Отсутствие массивов — неудобно, хоть и обходится.

G>>Строки. Строки. И еще раз строки. А также сериализация. Плюс — binaries не копируются при передаче от процесса к процессу в качестве мессаги — оч. полезное свойство.
G> При shared куче — вообще ничего не копируется
shared heap, который есть в стабильной версии сейчас, применяется только для binaries. Тот shared heap, о котором говоришь ты — исследовательский проект. Мало ли что можно сделать. Я тебе говорю, как есть.

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

G>Строки не могут быть быстрее при представлении в виде списка 4-х байтовых чисел. И они не быстрее.
Зато ими гораздо проще манипулировать в большинстве случаев

G>При потребности активно манипулировать строками переходят к представлениям binaries и atom.
G>Посмотри исходники XML-парсеров, почитай мэйл-лист на эту тему. Например, что по этому поводу думает Армстронг.
я избегаю порождать атомы динамически по вполне понятным причинам

G>Затем. Потому, что чтение их тупла по индексу — это O(1) с очень низкой константой. Асимптотика dict на чтении — O(N), а ets — это O(1) c копированием элемента при чтении и большой константой (это хэштаблица), плюс отсутствие сборки мусора и побочные эффекты. Их используют именно из-за убогости (вернее, отсутствия) массивов, это workaround, а не достоинство. Отсутствие массивов — неудобно, хоть и обходится.
Не совсем так. Dict = O(log(N)). Но я не об этом, а о том, зачем может понадобиться огромный массив с произволным доступом.

G>shared heap, который есть в стабильной версии сейчас, применяется только для binaries. Тот shared heap, о котором говоришь ты — исследовательский проект. Мало ли что можно сделать. Я тебе говорю, как есть.
Странно, а по времени и размеру кучки мне показалось, что для всех видов

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

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

G>>Строки не могут быть быстрее при представлении в виде списка 4-х байтовых чисел. И они не быстрее.
G>Зато ими гораздо проще манипулировать в большинстве случаев
Конечно.

G>>При потребности активно манипулировать строками переходят к представлениям binaries и atom.
G>>Посмотри исходники XML-парсеров, почитай мэйл-лист на эту тему. Например, что по этому поводу думает Армстронг.
G>я избегаю порождать атомы динамически по вполне понятным причинам
Естественно (ведь имеется в виду отсутствие GC для таблицы атомов?)

. Поэтому в мэйллисте и сошлись на binaries

G>>Затем. Потому, что чтение их тупла по индексу — это O(1) с очень низкой константой. Асимптотика dict на чтении — O(N), а ets — это O(1) c копированием элемента при чтении и большой константой (это хэштаблица), плюс отсутствие сборки мусора и побочные эффекты. Их используют именно из-за убогости (вернее, отсутствия) массивов, это workaround, а не достоинство. Отсутствие массивов — неудобно, хоть и обходится.
G>Не совсем так. Dict = O(log(N)). Но я не об этом, а о том, зачем может понадобиться огромный массив с произволным доступом.

Точно? А разве простой dict не на сортированном списке сделан? Впрочем, неважно — доступен и dict на базе gb_trees.

G>>shared heap, который есть в стабильной версии сейчас, применяется только для binaries. Тот shared heap, о котором говоришь ты — исследовательский проект. Мало ли что можно сделать. Я тебе говорю, как есть.
G>Странно, а по времени и размеру кучки мне показалось, что для всех видов
Дело в реализации куч — там одна куча на каждый процесс для термов со stop-and-copy GC, и отдельная общая на все процессы куча для binaries с подсчетом ссылок. В этом и причина разницы.

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

G>>Затем. Потому, что чтение их тупла по индексу — это O(1) с очень низкой константой. Асимптотика dict на чтении — O(N), а ets — это O(1) c копированием элемента при чтении и большой константой (это хэштаблица), плюс отсутствие сборки мусора и побочные эффекты. Их используют именно из-за убогости (вернее, отсутствия) массивов, это workaround, а не достоинство. Отсутствие массивов — неудобно, хоть и обходится.
G>Не совсем так. Dict = O(log(N)). Но я не об этом, а о том, зачем может понадобиться огромный массив с произволным доступом.

Да много зачем. Затем же, зачем и в любом другом языке. Не хочешь же ты сказать, что никто никогда не заводит длинных массивов — за ненадобностью?

Например, какой у нас самый естественный и эффективный способ представления двумерных матриц (допустим, мне марковский автомат нужен — да мало ли что)? Неужели хэштаблицы?

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

G>Точно? А разве простой dict не на сортированном списке сделан? Впрочем, неважно — доступен и dict на базе gb_trees.
Вроде бы да. Но это как раз и дает логарифмическую зависимость ( метод половинного деления 8)) ). Разумеется, для сильно больших обьемов простой dict неприменим.Но dict процесса почему-то работает существенно быстрее, и кривая зависимости скорости от размеров у него другая

G>Дело в реализации куч — там одна куча на каждый процесс для термов со stop-and-copy GC, и отдельная общая на все процессы куча для binaries с подсчетом ссылок. В этом и причина разницы.
Возможно, время на конвертацию терм-бинарис и обратно компенсировало время на пересылку терма для моих задач...Для больших бинарисов и термов это, возможно, будет не так

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

G>Да много зачем. Затем же, зачем и в любом другом языке. Не хочешь же ты сказать, что никто никогда не заводит длинных массивов — за ненадобностью?

Тут я согласен...Хотя, какие тут размеры, если подумать ? В компиляторе, который я делал, всего 390 правил и несколько больше состояний. Это и тупль потянет без проблем

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

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

G>>Точно? А разве простой dict не на сортированном списке сделан? Впрочем, неважно — доступен и dict на базе gb_trees.
G>Вроде бы да. Но это как раз и дает логарифмическую зависимость ( метод половинного деления 8)) ). Разумеется, для сильно больших обьемов простой dict неприменим.Но dict процесса почему-то работает существенно быстрее, и кривая зависимости скорости от размеров у него другая

Не, это дает только О(N). К сожалению. По причине отсутствия произвольного доступа к элементам списков, половинное деление невозможно — только линейный поиск.

G>Не, это дает только О(N). К сожалению. По причине отсутствия произвольного доступа к элементам списков, половинное деление невозможно — только линейный поиск.

Тогда нафиг список сортированный ?
Вообще жаль, что Жрланг не может попытаться предсказать модель использования и добавить обратные ссылки

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

A>Тогда нафиг список сортированный ?
A>Вообще жаль, что Жрланг не может попытаться предсказать модель использования и добавить обратные ссылки
Завтра померяю еще раз зависимости. Мне казалось, что уж никак не линейная, но могу ошибаться

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

G>>Не, это дает только О(N). К сожалению. По причине отсутствия произвольного доступа к элементам списков, половинное деление невозможно — только линейный поиск.

A>Тогда нафиг список сортированный ?
Их сливать можно за O(N), например.

A>Вообще жаль, что Жрланг не может попытаться предсказать модель использования и добавить обратные ссылки
Этого не умеет делать ни один из известных мне языков. И вообще — я не понимаю как это можно сделать, и главное — как тебе помогут обратные ссылки получить произвольный доступ.

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

M>А можно поинтересоваться, какие системы? Ну хотя бы приблизительно

Распределенный сбор данных с промышленных датчиков. В основном потребление энергии, напряжение и ток, хотя иногда заводят данные и с других агрегатов, например, от контактов.
На одном из рудников эта система ( являющаяся частью большей ) покрывает почти сотню кв. километров поверхности, не говоря уж о шахтных горизонтах. На нее заведена аварийная сигнализация, диспетчерское отображение и расчеты. Первая ступень больше 2-х лет работает. Последний рестарт системы был полгода назад ( это не везде, кое-где часто перезапускают по сврим причинам )
На одном из крупнейших заводов страны собираются и обрабатываются данные со всех подстанций, а потом выгоняются в SQL, чтоб можно было стандартными средствами извне заходить. Последний раз перезапуск был ранней весной
Это к примеру...

.

<< X:3/little-signed-integer-unit:8 >> = Number.
Я только что считал знаковое целое число в кодировке little endian, состоящее из трех элементов по 8 бит. Повтори на С++ — посмотрим, сильно ли помогут тебе битовые поля.

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

A>Экспериментальный проект. Запрототипируют, определятся на каких процессорах это будет запускаться, определят требования к скорости — и привет. А кроме того, кстати, неплохой тест для .NET библиотек и JIT

Там нет JIT. И возможно ОС станет доступна открыто.

VD>>Что есть какие-то координальные различия между C# и Эрлэнг (как у языков)?
A>Функциональный vs императивный ? Наверное есть

Я тебе без проблем на Шарпе в функциональном стиле напишу. А любой рантайм любого ФЯ является императивным. (железо такое) Так что это все разговор о высокоуровневых концепциях. Фактической разницы нет.

A>А уж библиотеки у них точно разные.

И что? Это не позволяет писать рантайм на Эрлэнге?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

EXO>Вот именно что "алгоритмически эквивалентны"... здесь-то собака и порылась.

Не нужно рассказывать сказки.

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>Ни о чем. Вот если они алогоритмически эквивалентны, и оба оптимизированны, то о чем-то говорит. Вот только чудес на свете не бывает.
G>Алгоритмически эквивалентны на столь разных языках ? Воистину, чудес не бывает

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

ЗЫ

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

Сейчас исследователи капают в сторону совмещения аннотации типов с выводом типов. Хороший прпимер такого подхода — это Немерл. Но для этого язык должен поддерживать аннотакцю типов! А Эрлэнг или Лисп с аннотацией типов (да и вообще Лисп с типами) — это уже другой язык!

По этому я говорю, чудес не бывает. КОмпиляторы ОКамл, и др. клонов МЛ, а так же других статически-типизированных языков имеют все шансы рано или поздно сровняться с С++-компиляторами по скорости. Возможно даже обойти их на некоторых задачах. В общем, конкурировать с ними. Но чистые динамически типизированные языки конуренты для скриптов, коеми они в общем-то и являются. И лучшее на что они могут претиндовать — это на 5х тормоза, ну, и на большую библиотеку написанную на С.

И это принципиальное ограничение, так как контоль типов в рантайме и вообще таскание описания типов за собой в рантайме не бесплатны!

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>Нет, погоди, так байт-код или JIT ?
A>Были когда-то тесты Portable.NET интерпретатора (unroller'a, преобразует MSIL в более простой промежуточный язык, и дальше, кажется, пытается что-то типа шитого кода устроить) и JIT-компилятора — и цифры были сильно разные.
A>А ты на все[ одну десятку лепишь

Не может быть интерпретатор быстрее компилятора. Ну, не может. Это уже деверсия.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>>запросто ! в форте и намека на типы нет, а работает ! я уж не говорю про ассемблер, где вся типизация представляет собой обман зрения 8))

WF>Да, но они не типобезапосны, в отличие от Erlang-а.

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

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

То есть к знающим о типах во время компиляции, но не предоставляющих никакой защиты типов.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Извини, но ты полностью не владешь терминологией. То того и разговор конструктивный получиться не может. Зайди в Википедию и прочти определения терминов:
Type Safe.
Staticaly typet.
и т.п.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>1. Сложная логика обработки. Вместо 1000 строк с if/switch получится 50 строк case

Верится с трудом.

G>2. параллельность. Тут конкурентов вообще нет

Есть.

G>3. обработка потоков данных, сложных бинарных структур

Хм. Хотел бы я знать на чем это нельзя делать?

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

Хм. На Яве их тоже делают. Единственная заслуга Эрлэнга в этом плане — это тпобезопасность и относительно безопасная система работы с потоками (за каким-то хреном названная процессами).

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

G>5. когда нужна портабельность — полностью переносим, без каких-либо заморочек. У меня один и тот же код работает под Linux/FreeBSD/Windows

Боюсь, С в этом лане более выигрышен.

G>6. распределенные системы — опять-таки не с чем сравнивать

Опять таки на той же Яве их делают тоннами.

G>Если хоть что-то из этого используется в разрабатываемом приложении — Ерланг в руки !

Сдается мне ты преукрашиваешь.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Ну, а МТС вроде как учет то ли на С++-ных, то ли на Явских приложениях ведет. Тоже вроде связать неплохая.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

M>>А можно поинтересоваться, какие системы? Ну хотя бы приблизительно

G>Распределенный сбор данных с промышленных датчиков.

OPC не используете? А то я на досуге по вечерам пишу библиотеку для доступа к OPC-серверам из Erlang-а. Велосипед изобретаю?

Здравствуйте, VladD2, Вы писали:
VD>Не нужно рассказывать сказки.

А никто и не рассказывает.

Цифры с реальных проектов...

Ты похоже допускаешь одну и ту же ошибку (в разных темах на разных форумах):
например сравниваешь с "идеальным" кодом на C/С++... И скорее даже надо говорить "на С", поскольку как только в куске кода вылазят классы/полиморфизм/виртуальные функции, так производительность сразу плывет сам знаешь куда.

Но вот только я уже давно не встречал в прикладных алгоритмах этого самого "идеального кода". Это нонче совершенно реликтовый зверь. Реально же тот же C++ это часто например STL (а реализация map-ов в нем "мама не горюй..."). Или офигеннейшее "дерево классов" или еще что в том же духе. Тот же dynamic cast например (порой зарытый в библиотеки).
Или посмотри асемблерник дельфийского приложения, там местами вообще шитый код с динамической типизацией вылазит.

Народ и на статически типизированных, компилируемых языках пишет так, как "удобнее" и "сопровождаемее", а вовсе не под "идеальное быстодействие". И правильно делает — time-критичные куски надо выносить в библиотеки на плоском C. И если таких кусков много — то это косяк постановки.

Так что ты просто "не туда копаешь". Erlang — не самый быстый из декларативных языков (OCaml его уделает на раз), но он есть часть полноценной промышленной платформы. И сравнивать его надо с такими же языками платформ.
Бенчмарков с C# .Net я не нашел, но нашлись сравнения с C# Mono.
Тесты правда "фрагментарные" — на отдельные элементы алгоритмов, что "не выгодно" Erlang-у, в котором оптимизиуется именно сложные алгоритмы в целом. Ну да пусть.
Итак:
1. Аккерман (вычисления): C#, Erlang
Здесь Erlang серьезно проигрывает по быстродействию — 2,85 раза (хотя выигрывает по памяти в 1,4 раза).
Иными словами чистые вычисления C# делает лучше.

2. Добавляем элементы логики. Хотя бы минимальные — обход двоичного дерева: C#, Erlang
Здесь проигрыш Erlang-а по производительности составляет уже только 1,45 раза и при этом выигрышь по памяти в 1,63 раза. Если еще учесть 29 строк исходного кода Erlang-а против 42 строк C#, то еще большой вопрос, кто здесь выигрывает.

3. Еще увеличим "логический элемент" теста. Вычисление знаков числа Pi. Алгоритм содержит достаточно много условных конструкций. (По этому показателю приближается к биллинговым задачам, о которых я писал в прошлом сообщении.)
Вот тесты: C# и Erlang.
Здесь уже Erlang выигывает у C# в 1,9 раза (проигрывая по памяти в 1,02 — практически на равне).
Но самое существенное: 34 строки кода Erlang-а против 126 строк на C#.
Последнее, для прикладных алгоитмов (требующих постоянного сопровождения) — решающий фактор.
Очень советую зайти по ссылочкам и глазами посмотреть исходники последнего теста...

И еще (чтобы небыло разговоров, про сравнение только с C#) вот последний тест на Java.
Java здесь проигрывает Erlang-у в 2,5 раза по скорости и в 2,6 раза по памяти.
При этом имеет 78 строк кода (правда стоит признать — выигрышь по строкам отностительно C# отчасти за счет фоматирования циклов в однк строку).

То есть одна из основных "родных" областей Erlang-а — анализ ситуаций (в сумме например с некотрым количеством вычислений или управляющих воздействий).

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

Лет 8 назад занимался я этим классом задачь. Так что знакомо.
Там критичного кода много — на вскидку около 30% (это действительно много). Да только вот доля "физики" в общем коде игрушки (если это не совершенно тупая стрелялка) не столь уж велика. Так что "физику" целиком можно рассматривать как некую "библиотеку". ("Специализированную", как я уже и писал.)

A>>Вообще жаль, что Эрланг не может попытаться предсказать модель использования и добавить обратные ссылки
G>Этого не умеет делать ни один из известных мне языков. И вообще — я не понимаю как это можно сделать, и главное — как тебе помогут обратные ссылки получить произвольный доступ.

Это меня переглючило

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

A>>Экспериментальный проект. Запрототипируют, определятся на каких процессорах это будет запускаться, определят требования к скорости — и привет. А кроме того, кстати, неплохой тест для .NET библиотек и JIT

VD> Там нет JIT.
Определятся с требованиями и железом — и подумают, решат, что нужно — сделают. Пока может в любую стороны изменться.

VD> И возможно ОС станет доступна открыто.
Это, типа, евангелизм? Зачем?
Ну хорошо, станет доступна открыто — будет еще больше похожа на уже открытый Erlang :D

VD>>>Что есть какие-то координальные различия между C# и Эрлэнг (как у языков)?
A>>Функциональный vs императивный ? Наверное есть

VD>Я тебе без проблем на Шарпе в функциональном стиле напишу. А любой рантайм любого ФЯ является императивным. (железо такое) Так что это все разговор о высокоуровневых концепциях. Фактической разницы нет.

Ну изхвини, так можно скзаат mxnj между языками разницы вообще нет, в конце концов рано или поздно исполняется машинный код

A>>А уж библиотеки у них точно разные.
VD>И что? Это не позволяет писать рантайм на Эрлэнге?

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

Что до рантайма — не знаю, на Яве вроде писали soft-realtime мини-OS.
Может быть не сильно нужно. Ну вот к примеру, захочу я сделать распределенную систему работающую с деньгами.
Понятно что возникает куча проблем с перехватом / подменой данных.
Сейчас я запускаю рантайм в Win/Linux/etc,etc а в рамках ОС настраиваю фиксированные зашифрованные соединения, которыми Эрланг пользуется.

Делаем ОС на Эрланге — и эти же проблемы надо решать с нуля. Сетевые настройки, шифрование... Зачем? Just for fun ? Можно и существующий рантайм улучшать, пример — HiPE.
Вдруг что интересное пропустишь? Так нет у Эрлангеров ресурсов Microsoft Research.

VD>И это принципиальное ограничение, так как контpоль типов в рантайме и вообще таскание описания типов за собой в рантайме не бесплатны!

Ну, ты совсем не веришь в E2K

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

A>>А ты на всё одну десятку лепишь

VD>Не может быть интерпретатор быстрее компилятора. Ну, не может. Это уже деверсия.

Не может. По крайней мере в при равном качестве реализации.
Но согласись, что JIT и интерпретатор — тоже сильно разные вещи, а ты их в одно валишь.

И кроме того, тут вроде никто не предлагает сравнивать в чистом виде C и Erlang ,как компиляторы/интерпретаторы.

Говорят о том, что на Erlang'e привычно и удобно писать некотороые классы программ, используя алгоритмы, которые обгонят алгоритмы, которые (для этих классов задач) привычно и удобно писать на C++.

Мне этот спор напоминает ASM vs C.
Ясно, что если у меня нет ограничений по времени и мозги на месте, то я оттюнингую ассемблерный код лучше компиляторного. Также ясно, что случаи где эта оптимизация оправдает гигантское потраченное время сейчас исчезающе редки. И аньше они были много чаще, но постепенно баланс стал смещаться. И тамкже Erlang vs С++, сегодня один баланс, завтра будет другой и т.д.

В конце концов, ты же пишешь на C#, хотя сам говоришь, что JIT должен проигрывать нативному компилятору

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

F>OPC не используете? А то я на досуге по вечерам пишу библиотеку для доступа к OPC-серверам из Erlang-а. Велосипед изобретаю?
OPC — это по определению WIN32, ибо COM. У меня система гетерогенная, и на Виндовс только клиентские машины, так что OPC не использую.
Но встречал я упоминание в сетях об открытых сорцах С++ OPC сервера, в эхе ASUTP мелькало. По слухам, код там небольшой, и его можно будет прикрутить как драйвер к Ерлангу.

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

VD>Алгоритм есть алгоритм. Он может быть не реализуем на чистых ФЯ, но на любом ИЯ любой рабочий алгоритм реализуем. Так что если есть алгоритм Х на ФЯ, то его за всегда можно переписать на ИЯ.

Вообще-то, алгоритм не есть самоцель. Некую поставленную задачу я буду решать разными способами, в зависимости от инструмента. Так и реализация алгоритмов на ФЯ и ИЯ будут существенно отличаться. Возможно, будут отличаться и сами алгоритмы.

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

G>>1. Сложная логика обработки. Вместо 1000 строк с if/switch получится 50 строк case
VD>Верится с трудом.

Тем не менее — это так. Паттерн матчинг рулит !

G>>2. параллельность. Тут конкурентов вообще нет
VD>Есть.
Гм. А что еще имеет столь же легковесные процессы и такую же простоту взаимодействия между ними ?

G>>3. обработка потоков данных, сложных бинарных структур
VD>Хм. Хотел бы я знать на чем это нельзя делать?

А вот я хотел бы знать, на чем это можно ПРОСТО сделать ?

G>>4. системы повышенной надежности, для непрерывной работы на протяжении месяцев и лет. У меня есть несколько приложений, в которых сдохшие по какой-то причине системы перезапускаются себе и работают дальше, никому не вредя.
VD>Хм. На Яве их тоже делают. Единственная заслуга Эрлэнга в этом плане — это тпобезопасность и относительно безопасная система работы с потоками (за каким-то хреном названная процессами).
Я еще понял бы, если б упоминалась Ада, Модула-2/3...Но Ява ! Можно пример таковых систем ?
И процессы в Ерланге — это именно процессы, ибо они полностью изолированы, и обмениваются лишь сообщениями.

G>>5. когда нужна портабельность — полностью переносим, без каких-либо заморочек. У меня один и тот же код работает под Linux/FreeBSD/Windows
VD>Боюсь, С в этом лане более выигрышен.
Да ? А как с длиной целого, например ? Портабельность С — это легенда. Даже при смене версии ОС может вылезти что-нибудь непотребное...

G>>6. распределенные системы — опять-таки не с чем сравнивать
VD>Опять таки на той же Яве их делают тоннами.
Не такого размаха, я бы сказал.

G>>Если хоть что-то из этого используется в разрабатываемом приложении — Ерланг в руки !
VD>Сдается мне ты преукрашиваешь.
Да не ! Правда-правда ! 8))

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

VD>Ну, а МТС вроде как учет то ли на С++-ных, то ли на Явских приложениях ведет. Тоже вроде связать неплохая

Весь вопрос в человеко-месяцах, которыми обеспечивается должная надежность и устойчивость.
Мне есть с чем сравнивать — первая версия системы была на С++, и в нее вбито 20 чел. месяцев
на Ерланге, с ноля, я написал БОЛЕЕ устойчивую вещь менее чем за 3 месяца
я говорю о пересекающейся функциональности обоих систем, конечно
А про биллинг на С++/Жабе лучше и не упоминать ! Я знаю положение дел в 4 более-менее крупных конторах, кои пишут биллинг для сотовых, и везде кучи глюков, падения и прочие радости. А сколько там народа на этом сидит !

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

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

F>>OPC не используете? А то я на досуге по вечерам пишу библиотеку для доступа к OPC-серверам из Erlang-а. Велосипед изобретаю?
G>OPC — это по определению WIN32, ибо COM. У меня система гетерогенная, и на Виндовс только клиентские машины, так что OPC не использую.
G>Но встречал я упоминание в сетях об открытых сорцах С++ OPC сервера, в эхе ASUTP мелькало. По слухам, код там небольшой, и его можно будет прикрутить как драйвер к Ерлангу.

Теоретически есть возможность писать OPC-сервера и клиенты под Unix, видел библиотеки. Правда, не помню, платные они или нет. Исходников серверов и клиентов в сети много валяется. Просто по моему опыту написания систем, обращающихся с OPC-серверам, их удобнее всего делать на Эрланге. Вот мне и захотелось написать клиентскую библиотеку. Собственно, почти написал

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

F>Теоретически есть возможность писать OPC-сервера и клиенты под Unix, видел библиотеки. Правда, не помню, платные они или нет. Исходников серверов и клиентов в сети много валяется. Просто по моему опыту написания систем, обращающихся с OPC-серверам, их удобнее всего делать на Эрланге. Вот мне и захотелось написать клиентскую библиотеку. Собственно, почти написал

Тут есть проблема. А именно, стабильность работы ДКОМа под Юниксами.
А ты через COMET лазишь к OPC серверам ?

EXO,

EXO>Итак:
EXO>1. Аккерман (вычисления): C#, Erlang
EXO>Здесь Erlang серьезно проигрывает по быстродействию — 2,85 раза (хотя выигрывает по памяти в 1,4 раза).
EXO>Иными словами чистые вычисления C# делает лучше.

Здесь конечно (в данном случае очень весомый) оверхед возникает из-за неявных дополнительных проверок аргументов при выполнении арифметических операций. Казалось бы, если ввести аннотацию типов, то это позволит компилятору обойтись без проверок типов, но это ещё не всё. Требуются рантайм проверки следующего плана.

Если в C# сложить два int, мы конечно же получим int, но необязательно сумму:

int a = 2147483647;
int b = a + 1; // b стал отрицательным

Эрланговские целые на такое не способны:

A = 2147483647,
B = A + 1,      %%% 2147483648, как это неудивительно

В последнем случае требуется расширение внутреннего представления. Тов. Bjorn Gustavsson пишет

The "i_plus_jd" instruction handles additions of small
integers directly. Only if one or both of the operands
are not small, or if the sum is not small, will the
erts_mixed_plus() function be called.

Knowing beforehand that both operands are integers would
not help because they may be bignums, so the type tests
would still be needed.

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

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

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

F>>Теоретически есть возможность писать OPC-сервера и клиенты под Unix, видел библиотеки. Правда, не помню, платные они или нет. Исходников серверов и клиентов в сети много валяется. Просто по моему опыту написания систем, обращающихся с OPC-серверам, их удобнее всего делать на Эрланге. Вот мне и захотелось написать клиентскую библиотеку. Собственно, почти написал

G>Тут есть проблема. А именно, стабильность работы ДКОМа под Юниксами.

Да он и под винду стабильностью не радует, особенное если сеть падает. Но тут у Эрланга преимущество — весь КОМ в отдельном экзешнике, который при падении будет передернут супервизором, так что клиент ничего не заметит.

G>А ты через COMET лазишь к OPC серверам ?

Нет, штатными средствами.

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

F>Да он и под винду стабильностью не радует, особенное если сеть падает. Но тут у Эрланга преимущество — весь КОМ в отдельном экзешнике, который при падении будет передернут супервизором, так что клиент ничего не заметит.
В смысле — весь КОМ ? со всеми потрохами ? а это не слишком жЫрно будет ?

G>>А ты через COMET лазишь к OPC серверам ?
F>Нет, штатными средствами.
До R8 COMET был в составе дистрибутива. А потом они его оттуда удалили, мотивируя слабой надобностью сего и нехваткой времени для поддержки и развития

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

F>Теоретически есть возможность писать OPC-сервера и клиенты под Unix, видел библиотеки.
Есть OPC XMLDA — SOAP-based протокол, недавно участвовал в разработке на C++, никаких DCOM. Но, ИМХО, на роль действительно кросс-платформенного протокола он не тянет — спецификация постоянно за деталями отсылает к более проработаноой спецфикации COM-based OPC DA 3.0. Если почитать про допустимые преобразования типов, становится ясно, что они подогнаны под функцию VariantChangeType. А в спецификации запроса Browse прямым текстом сказано, что поиск элементов по маске работает, как оператор Like из VB

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

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

F>>Да он и под винду стабильностью не радует, особенное если сеть падает. Но тут у Эрланга преимущество — весь КОМ в отдельном экзешнике, который при падении будет передернут супервизором, так что клиент ничего не заметит.
G>В смысле — весь КОМ ? со всеми потрохами ? а это не слишком жЫрно будет ?

Кажется, мы друг друга не понимаем. Я пишу под винду, по принципу наименьшего сопротивления. (Про то, что можно писать по Юникс, я только знаю, сам не пробовал). В порт (отдельный экзешник) вынесена вся низкоуровневая работа с OPC (и, следовательно, с КОМ-ом). Эрланговская программа общается уже с этим портом (по пайпу, вестимо). В общем, стандартный способ расширения Эрланга. Делать port driver с КОМ-ом внутри — спасибо, не хочется. В итоге, если что-то в КОМе пойдет не так (а он, например, очень не любит сетевых неполадок), есть возможность передернуть весь этот экзешник и заново подключиться к серверу. В контексте OPC (по крайней мере, для простых задач, вроде "считать данные с контроллера") это, по-моему, вполне допустимо.

G>>>А ты через COMET лазишь к OPC серверам ?
F>>Нет, штатными средствами.
G>До R8 COMET был в составе дистрибутива. А потом они его оттуда удалили, мотивируя слабой надобностью сего и нехваткой времени для поддержки и развития

R8 я не застал.

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

F>Кажется, мы друг друга не понимаем. Я пишу под винду, по принципу наименьшего сопротивления. (Про то, что можно писать по Юникс, я только знаю, сам не пробовал). В порт (отдельный экзешник) вынесена вся низкоуровневая работа с OPC (и, следовательно, с КОМ-ом). Эрланговская программа общается уже с этим портом (по пайпу, вестимо). В общем, стандартный способ расширения Эрланга. Делать port driver с КОМ-ом внутри — спасибо, не хочется. В итоге, если что-то в КОМе пойдет не так (а он, например, очень не любит сетевых неполадок), есть возможность передернуть весь этот экзешник и заново подключиться к серверу. В контексте OPC (по крайней мере, для простых задач, вроде "считать данные с контроллера") это, по-моему, вполне допустимо.
А ! Я отчего-то решил, что все это добро крутится под юниксами, а в отдельном бинарнике собран КОМ из сырцов. Оттого и ужаснулся
КОМ вообще не подходит для задач промышленной телеметрии в наших условиях. Конечно, ежели поставить ПРОФИБАС, то оно будет работать, но затраты...

F>R8 я не застал.
можно скачать сорцы. сначала посмотри change-log, когда удалили КОМ-сервер из дистрибутива. Насколько я помню, на чистом Ерланге написано

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

VD>Сейчас исследователи капают в сторону совмещения аннотации типов с выводом типов. Хороший прпимер такого подхода — это Немерл. Но для этого язык должен поддерживать аннотакцю типов! А Эрлэнг или Лисп с аннотацией типов (да и вообще Лисп с типами) — это уже другой язык!

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

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

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

G>>>1. Сложная логика обработки. Вместо 1000 строк с if/switch получится 50 строк case
VD>>Верится с трудом.

G>Тем не менее — это так. Паттерн матчинг рулит !

G>>>2. параллельность. Тут конкурентов вообще нет

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

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

. Что-то тут не так...

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

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

G>КОМ вообще не подходит для задач промышленной телеметрии в наших условиях.

Золотые слова! Промышленная телеметрия на ДКОМ — это звучит как анекдот. Поэтому факт существования OPC меня ставит в тупик. Посмотреть бы в глаза тому человеку, который принял решение заложиться на КОМ для таких задач.

F>>R8 я не застал.
G>можно скачать сорцы. сначала посмотри change-log, когда удалили КОМ-сервер из дистрибутива. Насколько я помню, на чистом Ерланге написано

Любопытно. Гляну на досуге.

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

P>Я так понял "Паттерн матчинг", одна из базовых возможностей Erlang-а как языка, но что-то мне кажется (с точки зрения реализации этого в виртуальной машине) скорость "матчинга" будет существенно проигрывать вызову статического метода класса (а наверняка и виртуальному ). Наскоко я понял для "матчинга" виртульная машина при выполнении байт-кода должна:
P>- разобрать с какими параметрами вызывается функция
P>- подобрать подходящую по сигнатуре функцию
P>- вызвать ее.

Совершенно не так. Код строится компилятором

%%%%%%%%%%% исходник %%%%%%%%%%%%%%%
func({atom1,X})-&gt;X;

func({atom2,X})-&gt;X+5;

func(X)-&gt;{fail,X}.

%%%%%%%%%% полученный код %%%%%%%%%%%%%%%%%%%%%
{function, func, 1, 2}.
  {label,1}.
    {func_info,{atom,b4},{atom,func},1}.
  {label,2}.
    {test,is_tuple,{f,5},[{x,0}]}.
    {test,test_arity,{f,5},[{x,0},2]}.
    {get_tuple_element,{x,0},0,{x,1}}.
    {get_tuple_element,{x,0},1,{x,2}}.
    {test,is_atom,{f,5},[{x,1}]}.
    {select_val,{x,1},{f,5},{list,[{atom,atom2},{f,3},{atom,atom1},{f,4}]}}.
  {label,3}.
    {bif,'+',{f,0},[{x,2},{integer,5}],{x,0}}.
    {'%live',1}.
    return.
  {label,4}.
    {move,{x,2},{x,0}}.
    return.
  {label,5}.
    {test_heap,3,1}.
    {put_tuple,2,{x,1}}.
    {put,{atom,fail}}.
    {put,{x,0}}.
    {move,{x,1},{x,0}}.
    return.

P>Ну не вериться что при тотальном использовании такой механики скросторельность сможет хотя бы близко тягяться с компиляторами

. Что-то тут не так
Наоборот, еще и выигрыш большой. Например :

case {func1(),func2(),X,Y} of
{nil,0,_,_}-&gt;...
{1,_,undefined,timeout}-&gt;...
{0,_,_,_}-&gt;......
%и так далее
end.

уже при десятке альтернатив код на С/С++ будет велик и нечитаем. Бинарный код — тоже

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

F>Золотые слова! Промышленная телеметрия на ДКОМ — это звучит как анекдот. Поэтому факт существования OPC меня ставит в тупик. Посмотреть бы в глаза тому человеку, который принял решение заложиться на КОМ для таких задач.
Как обычно, политическое решение. И лобби производителей кой-какого железа ( Сименсы, Шнайдеры... )

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

P>Ну не вериться что при тотальном использовании такой механики скросторельность сможет хотя бы близко тягяться с компиляторами

. Что-то тут не так...

а ведь можно еще guard добавить :

case {func1(),func2(),X,Y} of
{nil,Z,_,_} when Z <5 ->...
{Z,_,undefined,timeout} when is_integer(Z) ->...
{0,_,_,_}->......
%и так далее
end.

как это будет на С, даже представить страшно

gandalfgrey,

Маленький оффтоп: постарайся использовать форматирование кода (напр. с помощью code) хорошо? Читать и тебе самому и нам будет чуть удобнее.

%%%%%%%%%%% исходник %%%%%%%%%%%%%%%
func({atom1,X})->X;
func({atom2,X})->X+5;
func(X)->{fail,X}.

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

LCR>Маленький оффтоп: постарайся использовать форматирование кода (напр. с помощью code) хорошо? Читать и тебе самому и нам будет чуть удобнее.
Попробую, может и получится чего...

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

EXO>Ты похоже допускаешь одну и ту же ошибку (в разных темах на разных форумах):
EXO>например сравниваешь с "идеальным" кодом на C/С++... И скорее даже надо говорить "на С", поскольку как только в куске кода вылазят классы/полиморфизм/виртуальные функции, так производительность сразу плывет сам знаешь куда.
Классы сами по себе ничего не тормозят. Еще ты забыл про шаблоны. Они позволяют писать на С++ код который легко уделывает С как по читабельности так и по скорости. Сравни хотябы qsort и std::sort на массиве int'ов.
А полиморфизм с виртуальными функциями используется там где без него никак, а на С в этих случаях придется руками эмулировать виртуальные функции со всеми вытикающими.
Короче не надо расказывать байки про то что С++ тормозит. Это не правда.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

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

P>>... Наскоко я понял для "матчинга" виртульная машина при выполнении байт-кода должна:
P>>- разобрать с какими параметрами вызывается функция
P>>- подобрать подходящую по сигнатуре функцию
P>>- вызвать ее.
G>Совершенно не так. Код строится компилятором

G>%%%%%%%%%%% исходник %%%%%%%%%%%%%%%
G>func({atom1,X})->X;

G>func({atom2,X})->X+5;

G>func(X)->{fail,X}.

G>%%%%%%%%%% полученный код %%%%%%%%%%%%%%%%%%%%%
G>{function, func, 1, 2}.
G> {label,1}.
G> {func_info,{atom,b4},{atom,func},1}.
G> {label,2}.
G> {test,is_tuple,{f,5},[{x,0}]}.
G> {test,test_arity,{f,5},[{x,0},2]}.
G> {get_tuple_element,{x,0},0,{x,1}}.
G> {get_tuple_element,{x,0},1,{x,2}}.
G> {test,is_atom,{f,5},[{x,1}]}.
G> {select_val,{x,1},{f,5},{list,[{atom,atom2},{f,3},{atom,atom1},{f,4}]}}.
G> {label,3}.
G> {bif,'+',{f,0},[{x,2},{integer,5}],{x,0}}.
G> {'%live',1}.
G> return.
G> {label,4}.
G> {move,{x,2},{x,0}}.
G> return.
G> {label,5}.
G> {test_heap,3,1}.
G> {put_tuple,2,{x,1}}.
G> {put,{atom,fail}}.
G> {put,{x,0}}.
G> {move,{x,1},{x,0}}.
G> return.

"полученный код" не осилил

, можно пример как-нить более ИЯ-подобно

Другой пример:

fac(1)->1;
fac(N)->N*fac(N-1).

когда fac откудо-то вызовут то VM при проходе внутри fac(N) ,
работать должна примерно так (как я понимаю на данный момент):

fac_n(x){
//бла бла бла
//добрались до места " fac(N-1) " 
//теперь надо вызвать одну из функций fac , но какую?
//это зависит от результата вычисления N-1, т.е.
if (x-1)=1  //в общем случае эта проверка может быть достаточно сложной а значит времязатратной
{ ... fac_1(1)... }
else
{ ...fac_n(x)... }
//бла бла бла
}

fac_1(x) { retrun 1 }

Т.е. еще раз поясню свою мысль, т.к. при выполнении кода виртуальной машиной (VM) "паттерн матчинг" выполняется динамически, т.к. зависит от результата вычисления предыдущего выражения ( в моем примере: N-1 ), в общем случае задача нетривиальная, что не может быть быстрее обычного виртуального вызова (фактически одна ассемблерная инструкция с выборкой адреса метода по ссылке из VMT), а уж тем более статического .
Соответственно если "паттерн матчинг" является одним из базовых механизмов ран-тайма, который как мы видим "медленнее" традиционного вызова метода , то соответственно это должно заметно сказываться и на общей скорострельности программ (в сравнении с компилируемыми).

Все верно? где здесь собака зарыта ? (если она есть)

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

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

F>Золотые слова! Промышленная телеметрия на ДКОМ — это звучит как анекдот. Поэтому факт существования OPC меня ставит в тупик. Посмотреть бы в глаза тому человеку, который принял решение заложиться на КОМ для таких задач.
Я бы тоже хотел посмотреть в глаза этому человеку. Ведь OPC это не просто COM это кривой COM. Один IOPCServer::RemoveGroup чего стоит.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

P>"полученный код" не осилил

, можно пример как-нить более ИЯ-подобно
это и так ассемблер для виртуальной машины

P>Другой пример:
P>fac(1)->1;
P>fac(N)->N*fac(N-1).
а здесь у тебя будет истинная рекурсия, что нехорошо

P>Т.е. еще раз поясню свою мысль, т.к. при выполнении кода виртуальной машиной (VM) "паттерн матчинг" выполняется динамически, т.к. зависит от результата вычисления предыдущего выражения ( в моем примере: N-1 ), в общем случае задача нетривиальная, что не может быть быстрее обычного виртуального вызова (фактически одна ассемблерная инструкция с выборкой адреса метода по ссылке из VMT), а уж тем более статического .
P>Соответственно если "паттерн матчинг" является одним из базовых механизмов ран-тайма, который как мы видим "медленнее" традиционного вызова метода , то соответственно это должно заметно сказываться и на общей скорострельности программ (в сравнении с компилируемыми).
Он не медленнее ! Вызов виртуального метода не позволяет какой-либо логической обработки, в этом-то все и дело

P>Все верно? где здесь собака зарыта ? (если она есть)

Собака зарыта не более чем по пояс и очень хорошо видна ! Паттерн матчинг — это механизм обработки логики
вот более простой пример :

исходный текст ( обрати внимание, что здесь будет хвостовая рекурсия, то-есть просто цикл )

fact(1,N)->N;
fact(X,N)->fact(X-1,N*X).

ассемблерный текст ( ассемблер виртуальной машины ерланга )

{function, fact, 2, 4}.
  {label,3}.
    {func_info,{atom,b6},{atom,fact},2}.
  {label,4}.
    {test,is_eq_exact,{f,5},[{x,0},{integer,1}]}. проверка Х на 1
    {move,{x,1},{x,0}}.                           если да, то в результат
    return.                                       и вернуть
  {label,5}.                                      иначе
    {bif,'-',{f,0},[{x,0},{integer,1}],{x,2}}.    уменьшить Х
    {bif,'*',{f,0},[{x,1},{x,0}],{x,1}}.          умножить N на предыдущее значение Х
    {move,{x,2},{x,0}}.                           в список аргументов
    {call_only,2,{f,4}}.                          новый оборот цикла

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

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

G>fact(1,N)->N;
G>fact(X,N)->fact(X-1,N*X).
G>

Тогда уж для единообразия внешнего интерфейса

fac(N)->fact(N,1).

fact(1,N)->N;
fact(X,N)->fact(X-1,N*X).

Здравствуйте, WolfHound, Вы писали:
WH>Классы сами по себе ничего не тормозят.

Так "сами по себе" они ничего особенного и не дают.
Просто "плоские" классы с невиртуальными методами не так уж сильно ушли от C.
Иными словами "это собствено говоря не C++".

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

WH>Еще ты забыл про шаблоны. Они позволяют писать на С++ код который легко уделывает С как по читабельности так и по скорости.

В смысле скорости, они просто позволяют избежать накладных расходов "виртуализации".
Не более того. С на одинаковых алгоримах они не уделают (я надеюсь, ты сам понимаешь, что ерунду сказал.)

WH> Сравни хотябы qsort и std::sort на массиве int'ов.

некорректное сравнение.
из-за того, что шаблон делает частный случай алгоритма: qsort_int
если его написать именно так на С, то будет всяко не медленнее, чем шаблон
Другое дело, что это часный случай высокоуровневости и писать отдельные
qsort_int, qsort_double, ... — изврат, хотя и возможно.

WH>А полиморфизм с виртуальными функциями используется там где без него никак,

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

WH>Короче не надо расказывать байки про то что С++ тормозит. Это не правда.

Правда.

В сравнении с плоским C — тормозит.
Либо это не С++, а тот же самый С (пусть и с С++ синтаксисом).

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

EXO>Так "сами по себе" они ничего особенного и не дают.
EXO>Просто "плоские" классы с невиртуальными методами не так уж сильно ушли от C.
EXO>Иными словами "это собствено говоря не C++".
Ты забыл про деструкторы.

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

WH>>Еще ты забыл про шаблоны. Они позволяют писать на С++ код который легко уделывает С как по читабельности так и по скорости.
EXO>В смысле скорости, они просто позволяют избежать накладных расходов "виртуализации".
EXO>Не более того. С на одинаковых алгоримах они не уделают (я надеюсь, ты сам понимаешь, что ерунду сказал.)
Мне надобыло сделать оговорку: При сравнимом колличестве кода ибо всем известно что существуют трансляторы С++ -> С.

EXO>некорректное сравнение.
Очень даже корректное. Мы же языки сравниваем

Вот и давай сравнивать языки и те возможности что они нам дают для минимизации наших усилий.
EXO>из-за того, что шаблон делает частный случай алгоритма: qsort_int
EXO>если его написать именно так на С, то будет всяко не медленнее, чем шаблон
EXO>Другое дело, что это часный случай высокоуровневости и писать отдельные
EXO>qsort_int, qsort_double, ... — изврат, хотя и возможно.
И я о томже. При сравнимом колличестве кода во многих случаях С проигрывает.

EXO>если бы...
EXO>в библиотеках они используются куда чаще "необходимого", просто из соображений архитектуры.
EXO>Но за это приходится платить.
Ну библиотеки разные бывают. Например найди хоть один лишний virtual в http://antigrain.com

EXO>Правда.

В сравнении с плоским C — тормозит.
EXO>Либо это не С++, а тот же самый С (пусть и с С++ синтаксисом).
Попробуй переписать http://antigrain.com на чистом С посмотрим что у тебя получится...

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

Первое и последнее предупреждение за избыточное цитирование.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>Понятно, что для такого простого кода с элементарной логикой выигрыш будет НЕ на стороне Ерланга. А вот если что-то намного более сложное, то результат тебя удивит

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>> Там нет JIT.
A>Определятся с требованиями и железом — и подумают, решат, что нужно — сделают. Пока может в любую стороны изменться.

Нехочу спорить с тем кто ничего не читал по обсуждаемому вопросу. Или просто поверь, что это приципиальное решение, или прочти описание доступное по приведенной мной ссылке.

VD>> И возможно ОС станет доступна открыто.
A>Это, типа, евангелизм? Зачем?

Это типа информация к сведению.

A>Ну хорошо, станет доступна открыто — будет еще больше похожа на уже открытый Erlang :D

Не будет. Так как это полноценная ОС поддерживающая любой язык способный компилироваться в МСИЛ, и так как там полноценный компилятор получающий на вход полностью типизированный МСИЛ.

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

A>Ну изхвини, так можно скзаат mxnj между языками разницы вообще нет, в конце концов рано или поздно исполняется машинный код

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

A>>>А уж библиотеки у них точно разные.
VD>>И что? Это не позволяет писать рантайм на Эрлэнге?

A>Нет, это к вопросу о разнице в языках. Согласись, что стандартные библиотеки сильно определяют стиль.

Вопрос был почему рантайм Эрлэн нельзя написать на нем самом же.

A>Что до рантайма — не знаю, на Яве вроде писали soft-realtime мини-OS.

Чисто Ява ОС есть вроде только одна. Ну, да то все же Ява.

A>Вдруг что интересное пропустишь? Так нет у Эрлангеров ресурсов Microsoft Research.

Эриксон контора тоже не маленькая.

Мне кажется тупиковым в Эрланге является именно его "не типизированность". И это не даст стать этому языку языком общего назначения в полном смысле этого слова.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

EXO>А никто и не рассказывает.

Цифры с реальных проектов...

Скорее треп в форумах.

EXO>Ты похоже допускаешь одну и ту же ошибку (в разных темах на разных форумах):
EXO>например сравниваешь с "идеальным" кодом на C/С++... И скорее даже надо говорить "на С", поскольку как только в куске кода вылазят классы/полиморфизм/виртуальные функции, так производительность сразу плывет сам знаешь куда.

Еще одна сказка.

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

EXO>Но вот только я уже давно не встречал в прикладных алгоритмах этого самого "идеального кода". Это нонче совершенно реликтовый зверь.

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

Мне вот интересно, для Эрлэнга есть профайлер? И кто-нибудь из исползовавших этот язык хоть раз пробовал профайлить свои приложения?

EXO> Реально же тот же C++ это часто например STL (а реализация map-ов в нем "мама не горюй...").

И? Хорошая реализация STL в хороших руках дает возможность писать код близкий к оптимальному. Эрланг даже с компилятором рядом за версту не подползет.

EXO> Или офигеннейшее "дерево классов" или еще что в том же духе. Тот же dynamic cast например (порой зарытый в библиотеки).

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

EXO>Или посмотри асемблерник дельфийского приложения, там местами вообще шитый код с динамической типизацией вылазит.

Ну, ну. Только Дельфи порвет любой Эрланг как Тузик грелку.

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

Бывает. Кто же спорит. Но на С++ можно писать медленный и быстрый код. Если бы разница между Эрлагом и лучшими С++-компиляторами измерялось бы хотя бы в процентах, то конечно сэкономленное время (за счет более высокого уровня языка) можно было бы пустить на оптимизацию тонких мест. Более того когда пишутся задачи для которых железо превышает потребности в производительности в 10 и более раз, то вообще по фигу. Но бывают задачи которые и так на грани. И Эрлэнг для них попросту окажется не применим.

Между тем высокоуровневость Эрлэнга смотрится столь внушительной тольк на фоне убогости и низкоуровневости С++. Сравни его хотя бы с Шарпом и окажется, что приемущества уже очень туманны. А если вспомнить, что для Эрлэнга нет ни полноценной среды, ни другой инфраструктуры, то получится, что кодировать на Шарпе куда продуктивнее. Ну, а если начать сравнивать Эрлэнг с какими ниубдь Нэмерал или Скалой, то и вовсе неизвесно что удобнее и лучше.

EXO> И правильно делает — time-критичные куски надо выносить в библиотеки на плоском C. И если таких кусков много — то это косяк постановки.

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

EXO>Так что ты просто "не туда копаешь".

Нет, я просто реально смотрю на жизнь. Я фанат удобства и простоты, а не выпендрежа и наворотов.

EXO>Erlang — не самый быстый из декларативных языков (OCaml его уделает на раз), но он есть часть полноценной промышленной платформы. И сравнивать его надо с такими же языками платформ.

Не. Эрланг — это язык общего назначения. И сравнивать его нужно с такими же языками. Возможно в контексте некоторых задач.

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

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

EXO>Бенчмарков с C# .Net я не нашел, но нашлись сравнения с C# Mono.

Моно откровенный тормоз. На втором фрэймворке Шарп дает производительность в пределах от 0% до 20% от компилятора MS VC. Это конечно при условии, что код написан грамотно и со знанием дела.

EXO>Тесты правда "фрагментарные" — на отдельные элементы алгоритмов, что "не выгодно" Erlang-у, в котором оптимизиуется именно сложные алгоритмы в целом.

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

EXO> Ну да пусть.
EXO>Итак:
EXO>1. Аккерман (вычисления): C#, Erlang
EXO>Здесь Erlang серьезно проигрывает по быстродействию — 2,85 раза (хотя выигрывает по памяти в 1,4 раза).

Забудь ссылки на этот бред. "Серьезно проигрывает... в тир раза" ты вряд ли найщешь чесный тест, чтобы Эрлэнг был всего в 3 раза медленее. Эти тесты как ибольшинство подобных просто шарлатанство. Начать с того, что как и во всех пдобных шарлотанствах замеры времени видустя "из командной строки". Любому ребенку извесно, что измеряя время запуска управляемого кода, ты в основном измеряшь время потраченное на иницилизацию VM и на джит-компляцию. Замеры нужно провдить внутри тестов. Причем делать это полсе привентивных прогонов позволяющих скомпилироваться коду.

Далее берем код и смотрим:

public static int Ack(int m, int n) 
{
    if (m == 0) return n + 1;
    if (n == 0) return Ack(m-1, 1);
    else return Ack(m-1, Ack(m, n-1));
}

Что же мы видим? Ух ты! Концевая рекурсия на императивном языке! Зашибись. Чтобы разоблочить этих подтасовшиков достаточно объяснить, что современные компиляторы C# просто не делают оптимизации устранения концевой рекурсии. Ну, и любому школьнику извесно, что для ФЯ это жизненно важна оптимизация, так что если та таком тесте C# выиграл, то реализацее его кокурента можно только посочувствовать.

EXO>Иными словами чистые вычисления C# делает лучше.

Не то слово. А если еще использовать не Моно, а второй фрэймоврк...

EXO>2. Добавляем элементы логики. Хотя бы минимальные — обход двоичного дерева: C#, Erlang
EXO>Здесь проигрыш Erlang-а по производительности составляет уже только 1,45 раза и при этом выигрышь по памяти в 1,63 раза. Если еще учесть 29 строк исходного кода Erlang-а против 42 строк C#, то еще большой вопрос, кто здесь выигрывает.

А, ну, ну. Запустил это дело у себя и измерил по человечески:

stretch tree of depth 17         check: -1
131072   trees of depth 4        check: -131072
32768    trees of depth 6        check: -32768
8192     trees of depth 8        check: -8192
2048     trees of depth 10       check: -2048
512      trees of depth 12       check: -512
128      trees of depth 14       check: -128
32       trees of depth 16       check: -32
long lived tree of depth 16      check: -1
00:00:01.3681160

Уж не знаю что у них там был за компьютер, вряд ли он был в 8 раза медленнее моего.

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

EXO>3. Еще увеличим "логический элемент" теста. Вычисление знаков числа Pi. Алгоритм содержит достаточно много условных конструкций. (По этому показателю приближается к биллинговым задачам, о которых я писал в прошлом сообщении.)
EXO>Вот тесты: C# и Erlang.
EXO>Здесь уже Erlang выигывает у C# в 1,9 раза (проигрывая по памяти в 1,02 — практически на равне).
EXO>Но самое существенное: 34 строки кода Erlang-а против 126 строк на C#.
EXO>Последнее, для прикладных алгоитмов (требующих постоянного сопровождения) — решающий фактор.
EXO>Очень советую зайти по ссылочкам и глазами посмотреть исходники последнего теста...

Этот тест вообще завязан на библиотечные реализации. Причем класса BigInteger просто нет в дотнете. В Моно используется реализация BigInteger из Моно, а в D из D. Дай мне исходники этого лкасса из D и я тебе продемонстрирую, что скорость этого теста будет приблизительно такой же как у D.

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

EXO>То есть одна из основных "родных" областей Erlang-а — анализ ситуаций (в сумме например с некотрым количеством вычислений или управляющих воздействий).

То есть, Эрлинг не годится для вычислительных задач, раз уж столь претенциозные тесты и то показали, что Эрлинг постоянно проигрывает даже самой фиговой реализации C#.

Кстати, очень показательно, что во многих тестах на этом сате просто нет результатов для Intel C++. Знаешь почему? Да потому, что подобные тесты он щелкает как семячки. Многие из функций он или векторизует, или так разворачивает и инлайнит, что "мама не горюй".

EXO>Лет 8 назад занимался я этим классом задачь. Так что знакомо.

Лет 8 назад о таких задачах на ПК и говорить не приходилось.

EXO>Там критичного кода много — на вскидку около 30% (это действительно много). Да только вот доля "физики" в общем коде игрушки (если это не совершенно тупая стрелялка) не столь уж велика. Так что "физику" целиком можно рассматривать как некую "библиотеку". ("Специализированную", как я уже и писал.)

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

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

ЗЫ

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

LCR>Если в C# сложить два int, мы конечно же получим int, но необязательно сумму:
LCR>

LCR>int a = 2147483647;
LCR>int b = a + 1; // b стал отрицательным
LCR>

Для контроля переполнения в C# есть ключевое оператор checker() или ключи компилятора. Ну, и разрабатывая алгоритмы на C# надо учитывать что язык статически типизированный и заточенный на скорость рассчетов, а не на супер простоту. И если уж класс задачи подразумевает рабту с окромными числами, то стоит выбрать оптимальную стратегию. Как то: Выбрать более вемтительный тип данных (long, double). Воспользоваться классом эмулирующим безразмерные числа. Или еще что придумать.

LCR>Эрланговские целые на такое не способны:
LCR>

LCR>A = 2147483647,
LCR>B = A + 1,      %%% 2147483648, как это неудивительно
LCR>

LCR>В последнем случае требуется расширение внутреннего представления.

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>Весь вопрос в человеко-месяцах, которыми обеспечивается должная надежность и устойчивость.

Ага. Золотые слова. И я бьюсь об заклад, что у каждого человека человекомесяц разный.

G>Мне есть с чем сравнивать — первая версия системы была на С++, и в нее вбито 20 чел. месяцев

А вторая была на C# или еще пуще на каком-нить Немерле?

G>на Ерланге, с ноля, я написал БОЛЕЕ устойчивую вещь менее чем за 3 месяца

Ой, с нуля ли? А может в виду, того что был прототип на С++ ты просто знал что писать и не тратил время на эксперементы?

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

Ну, а если мы потом попробуем сравнить быстродействие (после оптимизаций), то я даже не сомневаюсь, что я получу более быстрое решение. И это на отндь не идельно компиляторе. Через пару лет компиляторы Явы и C# сравняются по скорости с С++-ным, а уровень языков будет только рости. Дальше делай выводы сам.

G>А про биллинг на С++/Жабе лучше и не упоминать !

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

G> Я знаю положение дел в 4 более-менее крупных конторах, кои пишут биллинг для сотовых, и везде кучи глюков, падения и прочие радости. А сколько там народа на этом сидит !

Писали бы они код на Эрлинге была бы та же куча глюков что и на Яве. Главное что родинт Эрлинг и Яву — это типобезопасность. Большинство трудноуловимых глюков именно от ошибок связанных с типами. Не даром все ФЯ выпячивают этот аспект так сильно.

Логические же ошибки будут на любом языке.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>>>1. Сложная логика обработки. Вместо 1000 строк с if/switch получится 50 строк case
VD>>Верится с трудом.

G>Тем не менее — это так. Паттерн матчинг рулит !

Это откровенная неправад (мягко выражаясь). В разницу в 2-3 раза над C# я еще поверю. И то если на C# писать с упором на производительность. Ну, если писать в стиле "по короче", то получится вообще очень близко к тексту. Эрланг явно выигрывает только при описании иерархии типов. Но она далеко не основной объем кода занимает. А на алгоритмических задачах или на ОО-задачах выигрыш у Эрлинга будет разве что за счет отсуствия той самой аннотации типов.

В 50 раз — это голимый пиар.

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

G>>>2. параллельность. Тут конкурентов вообще нет
VD>>Есть.
G>Гм. А что еще имеет столь же легковесные процессы и такую же простоту взаимодействия между ними ?

Куча решений. От экзотических активных объектов в Обероне, до банальных библиотек легвовесных потоков и обмена сообщениями. Возмем хотя бы Сингулярит и его Sing#. Общение между процессами обеспечивает ОС, а язык делает его очень простым и понятным (декларотивное описание сообщений и их протоколов и конструкции упрощающие обработку сообщений).

G>>>3. обработка потоков данных, сложных бинарных структур
VD>>Хм. Хотел бы я знать на чем это нельзя делать?

G>А вот я хотел бы знать, на чем это можно ПРОСТО сделать ?

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

G>>>4. системы повышенной надежности, для непрерывной работы на протяжении месяцев и лет. У меня есть несколько приложений, в которых сдохшие по какой-то причине системы перезапускаются себе и работают дальше, никому не вредя.
VD>>Хм. На Яве их тоже делают. Единственная заслуга Эрлэнга в этом плане — это тпобезопасность и относительно безопасная система работы с потоками (за каким-то хреном названная процессами).
G>Я еще понял бы, если б упоминалась Ада, Модула-2/3...Но Ява ! Можно пример таковых систем ?

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

G>И процессы в Ерланге — это именно процессы, ибо они полностью изолированы, и обмениваются лишь сообщениями.

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

G>>>5. когда нужна портабельность — полностью переносим, без каких-либо заморочек. У меня один и тот же код работает под Linux/FreeBSD/Windows
VD>>Боюсь, С в этом лане более выигрышен.
G>Да ? А как с длиной целого, например ? Портабельность С — это легенда. Даже при смене версии ОС может вылезти что-нибудь непотребное...

Отлично! Пара тайпдэфов и вперед с песней. Лучше расскажи как Элринг может быть более портабельным чем С, если сам рантайм Эрленга написан на С?

G>>>6. распределенные системы — опять-таки не с чем сравнивать
VD>>Опять таки на той же Яве их делают тоннами.
G>Не такого размаха, я бы сказал.

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

G>>>Если хоть что-то из этого используется в разрабатываемом приложении — Ерланг в руки !
VD>>Сдается мне ты преукрашиваешь.
G>Да не ! Правда-правда ! 8))

Да, да.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>И это принципиальное ограничение, так как контpоль типов в рантайме и вообще таскание описания типов за собой в рантайме не бесплатны!

A>Ну, ты совсем не веришь в E2K

А что мне в него врить? Бабаян давно пашет на Интел.

A>А если серьезно, вроде нативные Java-процессоры хоть и мало расрпостраненны — но кажется таки существуют.

Ага. И сильно поигрывают универсальным на кторых запущен Джит. А скоро Ява будет мало уступать по скорости С++-ному коду и тогда о таких процессорах вообще можно будет забыть.

A> Могу тсуществовать и нативные процессоры с проверкой типов, будут себе где-нибудь в нише. Хотя, ты скажешь, что все равно проиграют — из-за дополнительной нагрузки на память

Все процессоры Явы, реально просто эмулируют ее. Правда есть процессоры МСИЛ-а. Но и они мало чего достигли.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>Вообще-то, алгоритм не есть самоцель. Некую поставленную задачу я буду решать разными способами, в зависимости от инструмента. Так и реализация алгоритмов на ФЯ и ИЯ будут существенно отличаться. Возможно, будут отличаться и сами алгоритмы.

Цитирую тебя же:

Алгоритмически эквивалентны на столь разных языках ?

Далее могу только повторить свои слова.

Ладно, чтобы не быть голословным давай возмем простой пример. Вот есть алгоритм сортировки в памяти.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CP>В лиспе есть опциональная аннотация типов и она широко используеться в реализации ресурсоёмких алгоритмов.

В Лиспе нет никаких аннотаций. Они есть в расширениях. А то можно поговорить и о том, что в Лиспе есть императивные конструкции.

Лисп с выводм типов — это уже совсем не динамически типизированный язык. Это уже совсем другой язык, я бы сказал.

CP>По этому липс-программы работают быстрее и джавы и С#. что можно видеть из выше приведённых бенчмарков.

Верь в эту сказку дальше.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>Не может. По крайней мере в при равном качестве реализации.
A>Но согласись, что JIT и интерпретатор — тоже сильно разные вещи, а ты их в одно валишь.

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

A>И кроме того, тут вроде никто не предлагает сравнивать в чистом виде C и Erlang ,как компиляторы/интерпретаторы.

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

A>Говорят о том, что на Erlang'e привычно и удобно писать некотороые классы программ,

Ну, и где об этом хоть слово в памфлетах первой подветки этой темы?

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

А вот это уже не понял.

A>Мне этот спор напоминает ASM vs C.

А мне такие сравнения напоминают попытку подменить понятия.

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

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

Но тут вот в чем дело. Эрлинг конечно выше уровнем чем С++. Но не на столько чтобы уж порождать такую катастрофическую разницу как между асмом и С++. Ну, а если вспомнить, то есть языки сильно выше уровнем чем С++ и сравнивать Эрлен с ними, то окажется, что разница по сравнению с ними или минимальна, или вообще отрицательна. К примеру, у языка типа Явы может оказаться куда более обширная библиотека, что невилирует все приемущества Эрленга. Ну, а сравни с другим ФЯ? И где тут вообще разница? Чуть компактнее синтаксис? А хорошо ли это?

A> Также ясно, что случаи где эта оптимизация оправдает гигантское потраченное время сейчас исчезающе редки.

Об этом мы же говорили. Все зависит от задачи.

A> И аньше они были много чаще, но постепенно баланс стал смещаться. И тамкже Erlang vs С++, сегодня один баланс, завтра будет другой и т.д.

А давай Эрлэнг вс. Немерел. Или на худой конец Эрлеэн вс. C#?

A>В конце концов, ты же пишешь на C#, хотя сам говоришь, что JIT должен проигрывать нативному компилятору

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

M>Имеется в виду не только описание, но и сериализация/десериализация описанных структур — все же данные надо будет потом передавать куда-то. В этом отношении Эрланг рулит

Что мешает создать библиотеку/фрэймворк для других языков?

Особенно для тех что поддерживают метапрограммирование?

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Мне вот интересно, для Эрлэнга есть профайлер? И кто-нибудь из исползовавших этот язык хоть раз пробовал профайлить свои приложения?

Есть, а также есть серьёзное специальное руководство (http://www.erlang.se/doc/doc-5.4.12/doc/efficiency_guide/part.html) по созданию эффективных программ. Меня вообще очень радует дока по erlangу

VD>Между тем высокоуровневость Эрлэнга смотрится столь внушительной тольк на фоне убогости и низкоуровневости С++. Сравни его хотя бы с Шарпом и окажется, что приемущества уже очень туманны. А если вспомнить, что для Эрлэнга нет ни полноценной среды, ни другой инфраструктуры, то получится, что кодировать на Шарпе куда продуктивнее. Ну, а если начать сравнивать Эрлэнг с какими ниубдь Нэмерал или Скалой, то и вовсе неизвесно что удобнее и лучше.

Да ну нет. Есть куча тулзов и емакс с хорошей модой + esense. И вообще установите себе базовую систему эрланг и посмотрите сколько там всего есть.

EXO>> И правильно делает — time-критичные куски надо выносить в библиотеки на плоском C. И если таких кусков много — то это косяк постановки.

VD>Ну, а нафига тогда этот Эрланг, если я могу все писать на языке который сопостовим по уровню с ним, но при этом хорошо поддается компиляции и имеет в разу лучшую инфраструктуру? Что я мазахист ислледователь?

Потомучто для тех задач где его используют — он лучший:) А для других действительно нужно что-то другое использовать.

EXO>>Erlang — не самый быстый из декларативных языков (OCaml его уделает на раз), но он есть часть полноценной промышленной платформы. И сравнивать его надо с такими же языками платформ.

VD>Не. Эрланг — это язык общего назначения. И сравнивать его нужно с такими же языками. Возможно в контексте некоторых задач.

Де юре общего назначения. А де факто используют его для определённого круга задач.

VD>Далее берем код и смотрим:
VD>

VD>public static int Ack(int m, int n) 
VD>{
VD>    if (m == 0) return n + 1;
VD>    if (n == 0) return Ack(m-1, 1);
VD>    else return Ack(m-1, Ack(m, n-1));
VD>}
VD>

VD>Что же мы видим? Ух ты! Концевая рекурсия на императивном языке! Зашибись. Чтобы разоблочить этих подтасовшиков достаточно объяснить, что современные компиляторы C# просто не делают оптимизации устранения концевой рекурсии.

Я могу ошибаться, но помойму таки может оптимизировать.

ЗЫ: насчёт тестов. Эти тесты открыты. Вы можете запостить туда менее ресурсоёмкую версию на С#.

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

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

CP>>В лиспе есть опциональная аннотация типов и она широко используеться в реализации ресурсоёмких алгоритмов.

VD>В Лиспе нет никаких аннотаций. Они есть в расширениях. А то можно поговорить и о том, что в Лиспе есть императивные конструкции.

Да ну? В каких таких расширениях. Она есть в стандарте, которому около 20 лет. И которым пользуеться все реализации Common Lisp.

http://www.supelec.fr/docs/cltl/clm/node104.html (искать "(declare (type" ). Так что вы ошиблись. И императивные конструкции все в стандарте. И ООП тоже в стандарте. Это всё есть в Common Lisp. Вообще CL не функциональный язык. Или может быть вы имели ввиду что Common Lisp — это "расширение", относительно некого мифического — труъ функионального лиспа? ;)

VD>Лисп с выводм типов — это уже совсем не динамически типизированный язык. Это уже совсем другой язык, я бы сказал.

Вывода типов нет. А декларация есть. А вообще при желание можно добавить в лисп возможности любого языка с помощью макр.

CP>>По этому липс-программы работают быстрее и джавы и С#. что можно видеть из выше приведённых бенчмарков.

VD>Верь в эту сказку дальше.

Мне вот интерестно вы думаете что люди которые проводят те бэнчмарки (для почти всех языков) такие ярые фанаты лиспа, эрланга, etc. Что они намеренно подрстраивают так чтоб лисп, скажем, рулил а джава наоборот? Им это надо? Тем более лисп компилируеться в нативный код, а джава и C# нет. ТАк что он быстрее — ничего удивительного нет. И это заметим OpenSource реализации. Коммерческие генерят ещё более быстрый код. Другое дело что лисп прожорлив до памати, почти как джава.

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

VD>Мне вот очень понравилось решение Nemerle где просто можно реализовать такой синтаксис как тебе нужен, а потом еще и применить его банальным импоротом модуля.

Да, да — весьма новое, можно сказать революционное решение:))

M>>Имеется в виду не только описание, но и сериализация/десериализация описанных структур — все же данные надо будет потом передавать куда-то. В этом отношении Эрланг рулит

VD>Что мешает создать библиотеку/фрэймворк для других языков?

Руки

И объем работы, который обычно с этим связан. Люблю я, когда все до меня уже сделано и разжевано

VD>Особенно для тех что поддерживают метапрограммирование?

VD>Мне вот очень понравилось решение Nemerle где просто можно реализовать такой синтаксис как тебе нужен, а потом еще и применить его банальным импоротом модуля.

Хм. Лисп?

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

Ну, этого никто на отменял. Например в Эрланге нет библиотеки SOAP (она, правда, никому пока особа и не нужна была — все же там уже есть CORBA, ASN.1, легкая работа с binary да и вообще — он же distributed по определению, так?

). Вот я сейчас тоже думаю — а оно мне надо?

А хочется написать, да

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

M>Руки

И объем работы, который обычно с этим связан. Люблю я, когда все до меня уже сделано и разжевано

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

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

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

Мне всегда казалось, что хороший язык тот который позволяет быстро и просто написать эффективное решение для большинства задач.

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

VD>>Мне вот очень понравилось решение Nemerle где просто можно реализовать такой синтаксис как тебе нужен, а потом еще и применить его банальным импоротом модуля.

M>Хм. Лисп?

Лисп отдыхает по полно. Нумерл позволяет получить поддержку семантического анализатора языка. И вообще Лисп сам по себе не сравннено сложнее в применении чем язык в котором присуствует что-то большее чем AST.

Все восхваления лиспа обычно разбиваются на две части:
1. Ах Лисп позволяет писать в функциональном стиле.
2. Ах какое в Лиспе метапрограммирвание/макросы.

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

В итоге языки вроде Нэмерла и Скалы преращают фанатов Лиспа из борцов со штампами в их ярых защитников.

M>Ну, этого никто на отменял. Например в Эрланге нет библиотеки SOAP (она, правда, никому пока особа и не нужна была — все же там уже есть CORBA, ASN.1, легкая работа с binary да и вообще — он же distributed по определению, так?

). Вот я сейчас тоже думаю — а оно мне надо?

А хочется написать, да

А написав ты поймешь, что она принципиально медленее того что можно было написать на статически типизированном языке. Причем, учитывая слова явно не предвзятого Гапертона, ты еще потрахашся со строками при этом. В итоге твоя реализация будет и хуже, и сложнее. Так стоит ли проливать столько соплей по поводу динамически типизированного языка развиваемого довольно мало значащей в индустрии конторой?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>Мне вот очень понравилось решение Nemerle где просто можно реализовать такой синтаксис как тебе нужен, а потом еще и применить его банальным импоротом модуля.

CP>Да, да — весьма новое, можно сказать революционное решение

Ага. Весма нове. Аналогов нет. Есть конечно прототипы, но похоже Нэмерл их превзошел.

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

Лисп тут тоже ничем не лучше. У него тольо больше тараконов.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CP>Да ну? В каких таких расширениях. Она есть в стандарте, которому около 20 лет. И которым пользуеться все реализации Common Lisp.

А какими расширениями пользуется Схема?

CP>http://www.supelec.fr/docs/cltl/clm/node104.html (искать "(declare (type" ). Так что вы ошиблись. И императивные конструкции все в стандарте.

В стандарте чего? Одно из диалектов?

CP>И ООП тоже в стандарте. Это всё есть в Common Lisp. Вообще CL не функциональный язык. Или может быть вы имели ввиду что Common Lisp — это "расширение", относительно некого мифического — труъ функионального лиспа?

Есть некий мифический Лисп с некой мифической функцией Eval и некими мифическими канонами которые придуманы в хрен знает каком коду. И есть набор языков которые могут подпадать или не подпадать под эти каноны.

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

По оеределению атом в Лиспе есть вещь динамически типизированная и всегда можно найти код который не сможет однозначно вычеслить тип на этапе компиляции.

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

Есть языки кооторые проектировались в рассчете на статическую типизациб и вывод типов. И они в 100% случаев будут давать возможность породить оптимальный код. Лисп же к таковым не относится. Ну, а если вспомнит, что к Лиспам относятся тучи диалектов вообщ не знающие о аннотации типов, то вообще все обобщения по Лиспу являются обманом.

VD>>Лисп с выводм типов — это уже совсем не динамически типизированный язык. Это уже совсем другой язык, я бы сказал.

CP>Вывода типов нет. А декларация есть.

Я плакаль. А какй же тогда смысл в Лиспе если прийдется лепить типы везде? Это же будет монстр с типами, но без синтаксиса.

CP>А вообще при желание можно добавить в лисп возможности любого языка с помощью макр.

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

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

CP>>>По этому липс-программы работают быстрее и джавы и С#. что можно видеть из выше приведённых бенчмарков.

VD>>Верь в эту сказку дальше.

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

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

CP> Что они намеренно подрстраивают так чтоб лисп, скажем, рулил а джава наоборот?

Без разницы намеряно они это сделали или нет. Они это сделали и их работу можно назвать тольк позором.

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

CP> Им это надо?

Видмо надо раз делают.

CP>Тем более лисп компилируеться в нативный код, а джава и C# нет.

Хм. В итоге получается машинный код который исполняется.

CP> ТАк что он быстрее — ничего удивительного нет.

Он не быстрее. Есть случае где Лисп сопоставим. А есть где просто безнадежно медлненее. И это ограничение архитектуры языка.

CP> И это заметим OpenSource реализации. Коммерческие генерят ещё более быстрый код.

Оставим эти высказывания до появления хотя бы певого подтверждения.

CP> Другое дело что лисп прожорлив до памати, почти как джава.

Вы придумали себе Лисп который и любите. Если бы Лисп действительно был так крут, то создаваемые на его основе продукты давно завоевали бы рынок. А рынок заваевали Ява да С/С++. Причем перераспределение рынка идет именно между ними. Ява и дотнет отжирают все больше рынка, а С++ пытается удержать позиции. Даже если сложить долю рынка приходящуюся на все диаликты лиспа вместе взятые, то их результат можно наблюдать разве что в микроскоп.

Теперь можно послушать, что это из-за того, что все вокруг тупые и не понимают где щастье.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>Мне вот интересно, для Эрлэнга есть профайлер? И кто-нибудь из исползовавших этот язык хоть раз пробовал профайлить свои приложения?

CP>Есть,

Можно ссылочку? А то я даже вопросов по этому поводу не слышал.

CP> а также есть серьёзное специальное руководство (http://www.erlang.se/doc/doc-5.4.12/doc/efficiency_guide/part.html) по созданию эффективных программ. Меня вообще очень радует дока по erlangу

Возможно такя есть и по Руби.

VD>>Между тем высокоуровневость Эрлэнга смотрится столь внушительной тольк на фоне убогости и низкоуровневости С++. Сравни его хотя бы с Шарпом и окажется, что приемущества уже очень туманны. А если вспомнить, что для Эрлэнга нет ни полноценной среды, ни другой инфраструктуры, то получится, что кодировать на Шарпе куда продуктивнее. Ну, а если начать сравнивать Эрлэнг с какими ниубдь Нэмерал или Скалой, то и вовсе неизвесно что удобнее и лучше.

CP>Да ну нет. Есть куча тулзов и емакс с хорошей модой + esense. И вообще установите себе базовую систему эрланг и посмотрите сколько там всего есть.

Хм. 1. Я сказал в первую очередь о уровне языка. 2. Емаксом пусть пользуются те кто пиарит кайф жизни в командной строке. 3. Что-то не веристя, что возможности Эрлэнговских сред сопоставимы с IDEA или VS 2005 применительно к Яве и Шарпу. А без них у меня нет желания использовать даже куда более интересные языки типа Скалы.

VD>>Ну, а нафига тогда этот Эрланг, если я могу все писать на языке который сопостовим по уровню с ним, но при этом хорошо поддается компиляции и имеет в разу лучшую инфраструктуру? Что я мазахист ислледователь?

CP>Потомучто для тех задач где его используют — он лучший

А для других действительно нужно что-то другое использовать.

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

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

CP>Де юре общего назначения. А де факто используют его для определённого круга задач.

Дык, и где в этих сообщениях:
Re: преимущества erlang-а?
Re: преимущества erlang-а?
Re: преимущества erlang-а?
то есть почти во всех сообщениях близких к корню темы, хоть одно упоминание о том, что Эрлэнг выгоден только в опеделенном круге задачь? Где вообще хоть одно слово про его проблемы?

CP>Я могу ошибаться, но помойму таки может оптимизировать.

Можашь и ошибашся. Возможно кгна-нибудь будет, так как на фрэймворке куча ФЯ теперь стали работать, но не факт.

CP>ЗЫ: насчёт тестов. Эти тесты открыты. Вы можете запостить туда менее ресурсоёмкую версию на С#.

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

В противном случае верхние ступеньки там были бы просто в тупую забиты соревнованием Intel C++ с Intel Fortran. Ну, переодически между ними вклинивались бы ЖЦЦ и т.п.

Особой годостью этих тестов должны служить тесты где выводятся тонны данных в консоль. Это просто шедевр! Я плакал глядя на них.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

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

ANS>Хочется именно удобный язык.

Мне тоже. Но, лично я, языки которые не рассматривают вопрос производительности сразу отметаю.

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

Я требую от языка следующее:
1. Легкость в понимании.
2. Легкость в использовании.
3. Гибкость.
4. Производительность получаемого кода и возможность оптимизировать код.
5. Степерь в которой язык позволяет избегать ошибко.
6. Качество инфраструктуры (компиляторы, отладчики, средства редктирования и рефакторинга).
7. Количество и качество библиотек.
8. Поддержку языком и его рантаймом компонентных подходов и вообще динамические всойсатва языка и то не ухудшают ли они другие аспекты языка.
9. Обладать хорошей поддержкой (документацией, форумами, экспертами, программами обучения и самим обучением).

Ну, а исходя из этих предпосылок получается, что нужен язык:
1. Хоршо поддерживающий максимум парадикм программирования.
2. Позволяющего изменять синтаксис.
3. Оберегающим от ошибок, статически типизированным, типобезопасным.
5. Компонентноориентированным.
6. Обладающий простым и понятным базовым синтаксисом. Лисп, например, вообще синтакисом не обладает

.

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Ага. Весма нове. Аналогов нет. Есть конечно прототипы, но похоже Нэмерл их превзошел.

VD>Тут вот недавно задавался вопрос С++-ником по поводу метапрограммирования. Он как раз сказал, что ему не нравится, что препроцессор того же ОКамла не интегрируется с компилятором так же хорошо как С++. Он в общем-то не совсем прав, так как в С++ тоже хреново с этим делом. Но вот то что ОКамл не позволяет задействовать семантический анализ — это явный минус. Ведь без этого полученные в результате макросы будут куда примитивнее и порой будет очень не просто понять что за ошибка произошла. AST-то изменено, и компилятор будет орать на невидимое человеку его редставление, а не на исходное. А вот в Нэмерле можно легко реализовать дополнительные проверки.

Я весьма поверхостно знаком с Нэмерле. Можно пример макроса, делаюищего то о чём вы говорите.

VD>Лисп тут тоже ничем не лучше. У него тольо больше тараконов.

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

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

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

CP>>Да ну? В каких таких расширениях. Она есть в стандарте, которому около 20 лет. И которым пользуеться все реализации Common Lisp.

VD>А какими расширениями пользуется Схема?

Не занаю, может что и есть... В основном сейчас юзаються 4 диалекта лиспа, два из них встроенных в приложения (AutoLisp и Elisp). И 2 общего — схема и CL. Остальные практически отмерли. И когда говорят "лисп" обчно имеёт ввиду именно CL, а про схему так и говорят "схема". Так что я виду разговор о CL.

VD>В стандарте чего? Одно из диалектов?

Основного диалекта. см. выше.

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

А ну да я ещё забыл Dylan — так как раз обязательная декаларация типов. Но это уже не совем лисп.

VD>По оеределению атом в Лиспе есть вещь динамически типизированная и всегда можно найти код который не сможет однозначно вычеслить тип на этапе компиляции.

Как же не может. Берём функцию. Определям типы всех используемых в ней переменных. Компилируем. И вуаля код оптимизирован. Тем более не нужно оптимизировать всё. Берём профайлер (который кстати замечательно интегрирован с IDE:) и оптимизируем самые прожорливые функции.

VD>Есть языки кооторые проектировались в рассчете на статическую типизациб и вывод типов. И они в 100% случаев будут давать возможность породить оптимальный код. Лисп же к таковым не относится. Ну, а если вспомнит, что к Лиспам относятся тучи диалектов вообщ не знающие о аннотации типов, то вообще все обобщения по Лиспу являются обманом.

Да нету почти диалктов. померли все.

CP>>Вывода типов нет. А декларация есть.

VD>:))

VD>Я плакаль. А какй же тогда смысл в Лиспе если прийдется лепить типы везде? Это же будет монстр с типами, но без синтаксиса.

ЗАЧЕМ? Только там где это влияет на производительность.

CP>>А вообще при желание можно добавить в лисп возможности любого языка с помощью макр.

VD>Да, ну, добавь мне, плиз возможности того же Немерла. И так чтобы диагностика ошибок не пострадала.

VD>А я уж лучше предпочту пользоваться гтовым компилятором, а не писать его сам на совершенно сумашедем языке. :)

Так компилятор писать не нужно будет. Компилятор уже есть в CL.

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

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

Ну так по теории вероятности. В одном месте они должны были лучше сдеать в лисповой программе в другом в джавовой в третьем в эрланговом. Наверняка накосячили везде, а не только в C#. Так что средняя оценка должна быть близкой к правде. (Хотя если брать среднюю квалификацию прогарммистов на разных языках....:) )

CP>> Им это надо?

VD>Видмо надо раз делают.

Да нет же. вообще разные тесты писали разные люди. И любой может прислать программу проходящую тесты, но работающую бытрее и её поставят вместо старой.

CP>> ТАк что он быстрее — ничего удивительного нет.

VD>Он не быстрее. Есть случае где Лисп сопоставим. А есть где просто безнадежно медлненее. И это ограничение архитектуры языка.

В более больших случаях чем те тесты (где лисп таки уделывает джаву http://shootout.alioth.debian.org/benchmark.php?test=all&lang=cmucl&lang2=java, нету таких мест где бы она сильно была впереди почти всё на равне но лисп впереди). А в более больших случаях, за счёт макр, мы получам более эффективные абстакции. Сами подумайте что будет быстрее работать 20-строчный макр генерирующий 500 строк линейного кода, или тот же алгоритм на джаве со множеством вызовов методов.

CP>> И это заметим OpenSource реализации. Коммерческие генерят ещё более быстрый код.

VD>Оставим эти высказывания до появления хотя бы певого подтверждения.

Сам сравнивал ACL7 с CMUCL. ACL — быстрее :))

VD>Вы придумали себе Лисп который и любите. Если бы Лисп действительно был так крут, то создаваемые на его основе продукты давно завоевали бы рынок. А рынок заваевали Ява да С/С++. Причем перераспределение рынка идет именно между ними. Ява и дотнет отжирают все больше рынка, а С++ пытается удержать позиции. Даже если сложить долю рынка приходящуюся на все диаликты лиспа вместе взятые, то их результат можно наблюдать разве что в микроскоп.

VD>Теперь можно послушать, что это из-за того, что все вокруг тупые и не понимают где щастье. :)

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

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

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

VD>>>Мне вот интересно, для Эрлэнга есть профайлер? И кто-нибудь из исползовавших этот язык хоть раз пробовал профайлить свои приложения?

CP>>Есть,

VD>Можно ссылочку? А то я даже вопросов по этому поводу не слышал.

Как же, в том руководстве по эффективности — глава 8 profiling.

CP>>Да ну нет. Есть куча тулзов и емакс с хорошей модой + esense. И вообще установите себе базовую систему эрланг и посмотрите сколько там всего есть.

VD>Хм. 1. Я сказал в первую очередь о уровне языка. 2. Емаксом пусть пользуются те кто пиарит кайф жизни в командной строке. 3. Что-то не веристя, что возможности Эрлэнговских сред сопоставимы с IDEA или VS 2005 применительно к Яве и Шарпу. А без них у меня нет желания использовать даже куда более интересные языки типа Скалы.

1. Ну дык посмотрите на моду эрланговскую к емаксу, посмотрите на скриншоты http://esense.sourceforge.net/, чем не поддержка.
2. Это миф. Емакс самая настраиваемая и расширяема среда. Он поддерживает сотни языков. Интеграцию всех необходимых тулзов для огромного количества языков — профайлеры, дебагеры, автодополнения, поиск документации, навигация по коду, шаблоны, автоматический рефакторинг и.т.д и.т.п. Плюс кучу общих тулз — визуальная интеграция с текстовыми утилитам grep/find/diff. Работа почти со всеми ситемами контроля версий. Плюс работа с БД, файлами на удалённых компьютерах, работа с множеством интерактивных программ (например gnuplot, maxima). Плюс куча не относящихся к обраотке текстов тулз — Mail, IRC, Window Managers etc.. Вообщем монстр. Я перечислил едвали 10-20% возможностей. Никаким VS или IDEA не снилось.

CP>>Потомучто для тех задач где его используют — он лучший:) А для других действительно нужно что-то другое использовать.

VD>Ну, там может сказать, что он лучший только в области многопоточных вычислений? А то со стороны, по вашим словам, он просто лучший. Никто бы и возражать не стал бы. :xz:

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

CP>>Де юре общего назначения. А де факто используют его для определённого круга задач.

VD>Дык, и где в этих сообщениях:
VD>Re: преимущества erlang-а?
VD>Re: преимущества erlang-а?
VD>Re: преимущества erlang-а?
VD>то есть почти во всех сообщениях близких к корню темы, хоть одно упоминание о том, что Эрлэнг выгоден только в опеделенном круге задачь? Где вообще хоть одно слово про его проблемы?

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

CP>>Я могу ошибаться, но помойму таки может оптимизировать.

VD>Можашь и ошибашся. Возможно кгна-нибудь будет, так как на фрэймворке куча ФЯ теперь стали работать, но не факт.

Даже gcc умеет tail-recursion оптимизировать...

CP>>ЗЫ: насчёт тестов. Эти тесты открыты. Вы можете запостить туда менее ресурсоёмкую версию на С#.

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

Ну почему. Покажите что C# или Java лучше. Вы это сможите.

VD>В противном случае верхние ступеньки там были бы просто в тупую забиты соревнованием Intel C++ с Intel Fortran. Ну, переодически между ними вклинивались бы ЖЦЦ и т.п.

Ну дык так и есть. Fortran, C — на первых местах в общем случае.

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

CP>Как же, в том руководстве по эффективности — глава 8 profiling.

Зачем мне глава? Ты мне ссылку на профалер дай, плиз.

CP>1. Ну дык посмотрите на моду эрланговскую к емаксу, посмотрите на скриншоты http://esense.sourceforge.net/, чем не поддержка.

Я на Емакс сотреть не хочу. Я предпочитаю редактор которые не нужно перед использованием изучать пол жизни.

CP>2. Это миф. Емакс самая...

Мне плевать что там в Емакс самого. Настраивать его на Лиспе я не буду. Я его даже открвать не буду. Мне уже хватало опыта работы с ним.

CP>...Никаким VS или IDEA не снилось.

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

CP>Я этого не говорил. Лично я не собираюсь его использовать везде, а только там где он силён.

Ты, может и не говорил. Но и замечания не сделал тем кто говорил.

CP>Не ко мне вопрос. Я вообще не считаю эрланг каким-то супер языком, но в параленьных вычисления действительно силён, сволочь

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

CP>Даже gcc умеет tail-recursion оптимизировать...

Он и еще вроде бы Интел. Причем тут они и дотнет?

CP>Ну почему. Покажите что C# или Java лучше. Вы это сможите.

Мне не надо показывать, что что-то лучше. Я делал тесты и знаю что в них получается. А даказывать что-то этим уродам я не собираюсь. Как в прочем и серьезно смотреть на результаты их естов.

VD>>В противном случае верхние ступеньки там были бы просто в тупую забиты соревнованием Intel C++ с Intel Fortran. Ну, переодически между ними вклинивались бы ЖЦЦ и т.п.

CP>Ну дык так и есть. Fortran, C — на первых местах в общем случае.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CP>Не занаю, может что и есть... В основном сейчас юзаються 4 диалекта лиспа, два из них встроенных в приложения (AutoLisp и Elisp). И 2 общего — схема и CL. Остальные практически отмерли. И когда говорят "лисп" обчно имеёт ввиду именно CL, а про схему так и говорят "схема". Так что я виду разговор о CL.

А я вообще-то не говорил о CL. А говорил о Лиспе вообще. Между прочим когда его на этоам форуме рекомендуют, то в первую очередь тыкают на Схему. И это разумно. Дейсвтиельно чистно функциональный язык, да еще и простой. А когда о производительности разговор заходит, то бурем значит самый узасный CL и используем в нем то, за что ругаем другие языки. Здорово!

К тому же еще раз повторю, что даже будучи скомпилированным многие Лисповые прогрммы останутся по сути интерпретирвемыми, так как в самом Лиспе заложено слишком много вольнотей. Да и типы то ведь опять таки только простые. Структуры не опишеш. А как тот же кортэж представить?

Ну, и возвращаясь к Эрэнгу... ОК, при анатации типов даже CL можно заставить порождать отличный код во многих случаях. Но разве у Эрлэгна вообще есть синтаксис декларации типов? Или где-то описан механизм их вывода?

CP>Ну так по теории вероятности. В одном месте они должны были лучше сдеать в лисповой программе в другом в джавовой в третьем в эрланговом. Наверняка накосячили везде, а не только в C#. Так что средняя оценка должна быть близкой к правде. (Хотя если брать среднюю квалификацию прогарммистов на разных языках....

)

Понимашь ли в чем дело. Если люди исходно применяют в тестах некорректные способы измерения, не следят за идентичностью алгоритмов и даже допускают такие вещи как включение в тесты вывода на консоль отнимающего большую часть тестов, то говорить с такими людьми смысла нет. Задолбашся убеждать. Я вон тебе то обяснить, на русском это никак не могу. А как объяснить это этим долболомам?

Мне проще сдалеть свои тесы. Что я и сделал. Правда там небыло ФЯ, так как тогда эта тема вообще была мало интересна.

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

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

CP>>> Им это надо?

VD>>Видмо надо раз делают.

CP>Да нет же. вообще разные тесты писали разные люди. И любой может прислать программу проходящую тесты, но работающую бытрее и её поставят вместо старой.

Я вижу результат. Он является полнейшей халтурой. Ну, может специальной подтасовкой. Называй как хочешь.

Да и мало интересны результаты на Линукс. Я дотнет там использовать не стану.

CP>В более больших случаях чем те тесты (где лисп таки уделывает джаву http://shootout.alioth.debian.org/benchmark.php?test=all&lang=cmucl&lang2=java, нету таких мест где бы она сильно была впереди почти всё на равне но лисп впереди). А в более больших случаях, за счёт макр, мы получам более эффективные абстакции. Сами подумайте что будет быстрее работать 20-строчный макр генерирующий 500 строк линейного кода, или тот же алгоритм на джаве со множеством вызовов методов.

Понимашь ли, я делая даже их тесты, при корректном измерении времени налюдаю что C# показывает результаты в основном на уровне VC 8.0.

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

VD>>Теперь можно послушать, что это из-за того, что все вокруг тупые и не понимают где щастье.

CP>Да причём здесь тупые. Так сложилось исторически,

А почему так сложилось исторически и не перекладывается сейчас?

CP>также как например с виндой. Рынок никогда не завоёвывают самые лучшие решения

Как раз рынок заваевываеют всегда исключительно самые лучше. Рынок можно обмануть на короткий период. Но нельзя обмануть в перспективе.

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

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

CP> Тем более лисп всё-таки используеться во многих местах, и его популярность не собираеться снижаться.

Ее в общем-то и нет. Языки намного моложе захатили рынок. И если один из ФЯ прийдет в массы, то это точно не будет Лисп. Уж больно он нечеловеколюбив

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CP>Я весьма поверхостно знаком с Нэмерле. Можно пример макроса, делаюищего то о чём вы говорите.

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

Вот здесь можно скачать исходники Немерла и его компилятор:
http://nemerle.org/download/snapshots/?C=M;O=D

Макросы можно поглядеть в следующих местах:
nemerle-0.9.2.99.6088\macros\ — Код стандартных макросов.
nemerle-0.9.2.99.6088\doc\html\metaprogramming.pdf — водная статья описывающая то как они утроены и как их использовать.

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

mattc (что сопостоавляем)
    | паттерн => вывод/действие
    | другой паттерн => вывод/действие

так вот приводится пример того как на базе сопоставления с образцом делается тот самый if-else. В общем, проще процетировать:

8 Typing during execution of macro
Some more advanced techniques are also possible. They involve a closer interaction with the compiler, using its methods and data structures or even interweaving with internal compilation stages.
For example, we can ask the compiler to type some of object programs, which are passed to the macro, retrieve and compare their types, etc. This means that we can plug between many important actions performed by the compiler, adding our own code there. It might be just a nicer bug reporting (especially for macros defining complex syntax extensions), making code generation dependent on input program types or improving code analysis with additional information.

8.1 Example
Let us consider the following translation of the if condition to the standard ML
matching:
macro @if (cond, e1, e2)
syntax ("if", "(", cond, ")", e1, "else", e1)
{
    <[
        match ($cond)
        {    | true => $e1
            | false => $e2
        }
    ]>
}
When if ("bar") true else false was written, the compiler would complain that type of matched expression is not bool. Such an error message could be very confusing, because the programmer may not know, that his if statement is being transformed to the match statement. Thus, we would like to check such errors during the execution of the macro, so we can generate a more verbose message.

8.2 Usage
Instead of directly passing object expressions to the result of the macro, we can
first make the compiler type them and then find out if they have the proper
type. The body of the above if macro should be
def tcond = TypedExpr (cond);
def te1 = TypedExpr (e1);
def te2 = TypedExpr (e2);
if (tcond.Type == <[ ttype: bool ]> )
{
    <[
        match ($(tcond : typed))
        { | true => $(te1 : typed)
            | false => $(te2 : typed)
        }
    ]>
}
else
    FailWith("`if' condition must have type bool, "
        + "while it has " + tcond.Type.ToString())
Note that typed expressions are used again in the quotation, but with a
special splicing tag \typed". This means that the compiler does not have to
perform the typing (in fact, it cannot do this from now on) on the provided
syntax trees. Such a notation introduces some kind of laziness in typing, which
is guided directly by a programmer of the macro.

VD>>Лисп тут тоже ничем не лучше. У него тольо больше тараконов.

CP>Но и больше возможностей.

С чего бы это? Возможностей скорее меньше. Вернее не возможностей, а удобства.

CP> В немерле макросы "гигиенические" — т.е. можно реализовать далеко не всё что можно на лиспе. Но правда и гемороя поменьше, это да. Но факт остаёться фактом — макросы у немерле не полноценные.

Я не спец в Немерл. Но похоже, что все что нужно на них реализовать можно. Это коечно не чисто АСТ, но и писать предлагается не в АСТ, а на нормальном языке.

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

Ну, а главное, что когда я вижу макрос Лиспа мне становится не посебе. Это нагрмождение бреда! А когда я вижу макрос Нэмерла я его понимаю практически без обяснений. А зачем мне геморрой?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Зачем мне глава? Ты мне ссылку на профалер дай, плиз.

Ну ё мое:
http://www.erlang.se/doc/doc-5.4.12/doc/efficiency_guide/profiling.html там описаны профайлеры.

CP>>1. Ну дык посмотрите на моду эрланговскую к емаксу, посмотрите на скриншоты http://esense.sourceforge.net/, чем не поддержка.

VD>Я на Емакс сотреть не хочу. Я предпочитаю редактор которые не нужно перед использованием изучать пол жизни.

Зато изучив работать можно работать намного эффективнее.

CP>>...Никаким VS или IDEA не снилось.

VD>Да уж им вообще ничего не снится. Они работают и на них работать удобно. Все что нужно настраивается визуально и сохраняется в отдельный файл настроек который куда угодно перетащить можно.
VD>К томже хотелось бы еще и рефакторинг. Привык я к нему. :xz:

Рефакторинг есть. Например http://xref-tech.com/xrefactory/main.html, Ну дык в емаксе всё что нужно настраиваеться визуально (customize) А то что нельзя (вообще нельзя нигде) пишеться на лиспе. И перетаскиваеться тоже свободно. Вообще некоторые емаксовские расширения-приложения могут автоматически скачивать свои настройки с единого сервера.

CP>>Я этого не говорил. Лично я не собираюсь его использовать везде, а только там где он силён.

VD>Ты, может и не говорил. Но и замечания не сделал тем кто говорил.

Я эрланг изучаю неделю. А те люди с ним работали долгое время, не мне пока судить.

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

Видимо это сложно сдлеать не криво, раз никто ещё не сделал.

CP>>Даже gcc умеет tail-recursion оптимизировать...

VD>Он и еще вроде бы Интел. Причем тут они и дотнет?

Ну типа виртуальная машина дотнета поддерживает хвостовую рекурсию, в F# или Nemerle это работает. Почему бы не сделать это для C# — основного .net языка....

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

VD>А я вообще-то не говорил о CL. А говорил о Лиспе вообще. Между прочим когда его на этоам форуме рекомендуют, то в первую очередь тыкают на Схему. И это разумно. Дейсвтиельно чистно функциональный язык, да еще и простой. А когда о производительности разговор заходит, то бурем значит самый узасный CL и используем в нем то, за что ругаем другие языки. Здорово! :)

Да-да:) Вообще исходники самого CMUCL посмотреть — сполшная императившина. А схему советуют т.к. она проще, а CL более приспособлен к рельной жизни.

VD>К тому же еще раз повторю, что даже будучи скомпилированным многие Лисповые прогрммы останутся по сути интерпретирвемыми,
Почему-же это они будут интерпретируемы?

> так как в самом Лиспе заложено слишком много вольнотей. Да и типы то ведь опять таки только простые. Структуры не опишеш. А как тот же кортэж представить?

Есть и структуры и типизированные массивы и классы есть и хэши.

VD>Ну, и возвращаясь к Эрэнгу... ОК, при анатации типов даже CL можно заставить порождать отличный код во многих случаях. Но разве у Эрлэгна вообще есть синтаксис декларации типов? Или где-то описан механизм их вывода?

вроде нет.

VD>Можно сделать еще одну попытку учтя ошибки прошлой и расширив список тестируемых функциональными языками. Но при этом нужно решить некоторые проблемы. Самой большой из них будет то кто будет проверять соотвествие реализаций условиям?

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

Хорошая идея:))

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

Ну дык можно же использовать...

CP>>Да причём здесь тупые. Так сложилось исторически,

VD>А почему так сложилось исторически и не перекладывается сейчас?

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

VD>Просто у рынка другие критерии нежели от отдельных личностей. То что ты считашь важным, не важно для большинтсва и надоборот.

VD>Ты вот считашь Емакс нормальным редактором, а большинство его на дух не переносит.

Большинтво ведёться на рекламу.

CP>> Тем более лисп всё-таки используеться во многих местах, и его популярность не собираеться снижаться.

VD>Ее в общем-то и нет. Языки намного моложе захатили рынок. И если один из ФЯ прийдет в массы, то это точно не будет Лисп. Уж больно он нечеловеколюбив :).

Да да я знаю. Когда нибудь через десятки лет изобретут идеальный язык. Он будет называться по другому но по сути это будет лисп:)

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

CP>Ну ё мое:
CP>http://www.erlang.se/doc/doc-5.4.12/doc/efficiency_guide/profiling.html там описаны профайлеры.

К сожалению страничка не открылась.

CP>Зато изучив работать можно работать намного эффективнее.

Я и так работают намного эффективнее. А потеря пол жизни вряд ли улушит это.

В общем, Емакс идет в лес. Это на любителя головоломок. Я не из их числа. Да и большинство людей тоже.

CP>Рефакторинг есть. Например http://xref-tech.com/xrefactory/main.html, Ну дык в емаксе всё что нужно настраиваеться визуально (customize) А то что нельзя (вообще нельзя нигде) пишеться на лиспе. И перетаскиваеться тоже свободно. Вообще некоторые емаксовские расширения-приложения могут автоматически скачивать свои настройки с единого сервера.

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

Мы же вроде про Эрлэнг говорим. Есть для него рефакторинг? Мне вот с трудом веристя. Ведь рефакторинг тоже любит аннотацию типов. Ему ведь за что-то цепляться нужно. Ну, да хоть что-то можно сделать.

CP>Я эрланг изучаю неделю. А те люди с ним работали долгое время, не мне пока судить.

Ну, то есть я знаю, но кто я такой чтобы вывдавать тайну...

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

CP>Видимо это сложно сдлеать не криво, раз никто ещё не сделал.

Вот в том же Нэмерле вроде как есть макросы по этому поводу. Незнаю уж насколько оно удобно. Но все же есть. К С++ вроде тоже самое пытаются сейчас прикрутить. К Шарпу.

Думаю что до сих пор нет норальных реализаций только потому, что до недавнего времени вопрос был не актуален. Большинство потребителей имели однопроцессорные машины. А серверны пишутся штучно и скорее всего у их разработчиков свои фрэймворки есть.
VD>>Он и еще вроде бы Интел. Причем тут они и дотнет?

CP>Ну типа виртуальная машина дотнета поддерживает хвостовую рекурсию, в F# или Nemerle это работает. Почему бы не сделать это для C# — основного .net языка....

F# и Nemerle сами преобразуют все как надо. О расширении машины под ФЯ были разговоры, но пока ничено не сделано.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>

VD>def tcond = TypedExpr (cond);
VD>def te1 = TypedExpr (e1);
VD>def te2 = TypedExpr (e2);
VD>if (tcond.Type == <[ ttype: bool ]> )
VD>{
VD>    <[
VD>        match ($(tcond : typed))
VD>        { | true => $(te1 : typed)
VD>            | false => $(te2 : typed)
VD>        }
VD>    ]>
VD>}
VD>else
VD>    FailWith("`if' condition must have type bool, "
VD>        + "while it has " + tcond.Type.ToString())
VD>

VD>Note that typed expressions are used again in the quotation, but with a
VD>special splicing tag \typed". This means that the compiler does not have to
VD>perform the typing (in fact, it cannot do this from now on) on the provided
VD>syntax trees. Such a notation introduces some kind of laziness in typing, which
VD>is guided directly by a programmer of the macro.
VD>[/q]

Т.е. если в макр поступает выражение X > Y то всё ок. А если "asd" + "asa", то облом. Конечно в 6 утра я плохо соображаю, но здесь видимо нужне вывод типов из выражений. В лиспе его нет... А если нужно просто проверить на тип входной параметр то это легко.

VD>>>Лисп тут тоже ничем не лучше. У него тольо больше тараконов.

CP>>Но и больше возможностей.

VD>С чего бы это? Возможностей скорее меньше. Вернее не возможностей, а удобства.

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

(awhen (compr x y)
   (blah it))

раскрывается в

(let (it (compr x y))
  (when it
   (blah it))

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

VD>К сожалению страничка не открылась.

http://www.erlang-fr.org/erlang.org/doc/efficiency_guide/profiling.html

VD>Это рефакторинг для С++. По словам людей совершенно бездарный. Согласен, что лучше наверно для С++ нет, но от этого не легче. Но на С++ меня не тянет писать вообще. :))

Там и для джавы и для С.

VD>Мы же вроде про Эрлэнг говорим. Есть для него рефакторинг? Мне вот с трудом веристя. Ведь рефакторинг тоже любит аннотацию типов. Ему ведь за что-то цепляться нужно. Ну, да хоть что-то можно сделать.

Незнаю. Один небольшой авто-рефакторин:) я заметил. Если сохарнять модуль обазначенный одним именем в файл с дургим именем, емакс спрашивает, "а не поменять ли нам, дружок, имя модуля?" :)))

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

А в эрланге уже есть и уже работает и уже готова инфраструктура с кучей документов "как-правильно-реализовать-многопроцессное-приложениие-на-эрланге"

CP>>Ну типа виртуальная машина дотнета поддерживает хвостовую рекурсию, в F# или Nemerle это работает. Почему бы не сделать это для C# — основного .net языка....

VD>F# и Nemerle сами преобразуют все как надо. О расширении машины под ФЯ были разговоры, но пока ничено не сделано.

Я конкретно про хвостовую рекурсию. Она точно есть в виртуальной машине. http://www.google.ru/search?q=.net+vm+tail+recursion&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox&rls=org.mozilla:en-US:unofficial

Так, замечание небольшое. С какой это радости Схема стала вдруг чисто функциональной? В ней же одна из специальных форм — присваивание:

(set! <name> <new-value>) -- присваивание

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

CP>Там и для джавы и для С.

Еще раз, мы вроде о Эрлинге...

CP>Незнаю. Один небольшой авто-рефакторин

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

CP>А в эрланге уже есть и уже работает и уже готова инфраструктура с кучей документов "как-правильно-реализовать-многопроцессное-приложениие-на-эрланге"

Дык я и не спорю, что это достоинство. Вопрос перевыешивает ли он недостатки Эрлэнга и достоинсво других языков.

CP>Я конкретно про хвостовую рекурсию. Она точно есть в виртуальной машине. http://www.google.ru/search?q=.net+vm+tail+recursion&sourceid=mozilla-search&start=0&start=0&ie=utf-8&oe=utf-8&client=firefox&rls=org.mozilla:en-US:unofficial

Хм. Забавно. Я об этом не знал. Значит все таки ввели.
Вот только все же две проблемы остаются.
1. Моно != дотент и темболее != дотнет 2.0. А этот префикс введен во втором фрэймворке.
2. К сожалению даже компилятор C# 2.0 не использует эту инструкцию. А, как я понимаю, сам джит определением конечной рекурсии не занимается (хотя что ему стоит?).

Я провел простенький эксперемент. Вот такой код:

using System;

class Program
{
    static void Main()
    {
        Console.WriteLine(Sum(10, 300));
    }

    static int Sum(int val, int count)
    {
        if (count <= 1)
            return val;

        return val + Sum(val, count - 1);
    }
}

Порождает вот такой мсил

.method private hidebysig static int32  Sum(int32 val,
                                            int32 count) cil managed
{
  // Code size       18 (0x12)
  .maxstack  8
  IL_0000:  ldarg.1
  IL_0001:  ldc.i4.1
  IL_0002:  bgt.s      IL_0006
  IL_0004:  ldarg.0
  IL_0005:  ret
  IL_0006:  ldarg.0
  IL_0007:  ldarg.0
  IL_0008:  ldarg.1
  IL_0009:  ldc.i4.1
  IL_000a:  sub
  IL_000b:  call       int32 Program::Sum(int32,
                                          int32)
  IL_0010:  add
  IL_0011:  ret
} // end of method Program::Sum

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

...
VD>Я провел простенький эксперемент. Вот такой код:
VD>

VD>using System;

VD>class Program
VD>{
VD>    static void Main()
VD>    {
VD>        Console.WriteLine(Sum(10, 300));
VD>    }

VD>    static int Sum(int val, int count)
VD>    {
VD>        if (count <= 1)
VD>            return val;

VD>        return val + Sum(val, count - 1);
VD>    }
VD>}
VD>

А где тут хвостовая рекурсия?

Может вот так все таки:

using System;

class Program
{
    static void Main()
    {
        Console.WriteLine(Sum(10, 300, 0));
    }

    static int Sum(int val, int count, int acc)
    {
        if (count <= 0)
            return acc;

          return Sum(val, count - 1, acc + val);
    }
}

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

CP>Т.е. если в макр поступает выражение X > Y то всё ок. А если "asd" + "asa", то облом.

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

CP> Конечно в 6 утра я плохо соображаю, но здесь видимо нужне вывод типов из выражений. В лиспе его нет...

Естественно, так как его макросы — это всего лишь преобразование над АСТ. К компилятору из них не обратишся.

CP> А если нужно просто проверить на тип входной параметр то это легко.

Интересно как? В конце концов параметр может быть функцией возвращающей булево значение при выполнении. К тому же большинство кода не типизированно так что с него вообще до выполнения ничего не получишь. Ну, и опять возвращаемся к вопросу что называть Лиспом. В Схеме макросы отличные, а средств работы с типами нема.

CP>AST намного удобнее управлять програмно, чем кодом, как в немерле.

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

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

CP> А некоторые вещи вообще не возможны, типа анофорических макр.

Что означает "анофорических"?

CP>

CP>(awhen (compr x y)
CP>   (blah it))
CP>

CP>раскрывается в

CP>

CP>(let (it (compr x y))
CP>  (when it
CP>   (blah it))
CP>

Не въехал, а что тут необычного?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

MK>Может вот так все таки:

MK>

MK>using System;

MK>class Program
MK>{
MK>    static void Main()
MK>    {
MK>        Console.WriteLine(Sum(10, 300, 0));
MK>    }

MK>    static int Sum(int val, int count, int acc)
MK>    {
MK>        if (count <= 0)
MK>            return acc;

MK>          return Sum(val, count - 1, acc + val);
MK>    }
MK>}
MK>

Все равно бестолку:

.method private hidebysig static int32  Sum(int32 val,
                                            int32 count,
                                            int32 acc) cil managed
{
  // Code size       19 (0x13)
  .maxstack  8
  IL_0000:  ldarg.1
  IL_0001:  ldc.i4.0
  IL_0002:  bgt.s      IL_0006
  IL_0004:  ldarg.2
  IL_0005:  ret
  IL_0006:  ldarg.0
  IL_0007:  ldarg.1
  IL_0008:  ldc.i4.1
  IL_0009:  sub
  IL_000a:  ldarg.2
  IL_000b:  ldarg.0
  IL_000c:  add
  IL_000d:  call       int32 Program::Sum(int32,
                                          int32,
                                          int32)
  IL_0012:  ret
} // end of method Program::Sum

Провел еще один эксперемент. Сконвертировал код в Нэмерл и скормил его компилятору.
Вот конвертированный код:

using System;

class Program
{
    static Main() :  void
    {
        Console.WriteLine(Sum(10, 300, 0));
    }

    static Sum(mutable  val : int, mutable  count :  int, mutable  acc :  int) :  int
    {
        if (count <= 0)
             acc;
        else
         Sum(val, count - 1, acc + val);
    }
}

С виду почти идентичный.

А вот что получилось в результате в мсиле:

.method private hidebysig static int32  Sum(int32 val,
                                            int32 count,
                                            int32 acc) cil managed
{
  // Code size       32 (0x20)
  .maxstack  6
  IL_0000:  ldarg.1
  IL_0001:  ldc.i4.0
  IL_0002:  bgt        IL_000d
  IL_0007:  ldarg.2
  IL_0008:  br         IL_001f
  IL_000d:  ldarg.0
  IL_000e:  ldarg.1
  IL_000f:  ldc.i4.1
  IL_0010:  sub.ovf
  IL_0011:  ldarg.2
  IL_0012:  ldarg.0
  IL_0013:  add.ovf
  IL_0014:  starg.s    acc
  IL_0016:  starg.s    count
  IL_0018:  starg.s    val
  IL_001a:  br         IL_0000
  IL_001f:  ret
} // end of method Program::Sum

Не вооруженным взглядом видно, что рекурсивный вызов устранен на проч.

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

Возмем в качесте упомянутый тест Ackermann.

Вот его код модифицированный мной с целью измерения чистого времени выполнения функции Ack():

using System;
using System.Diagnostics;

class Ackermann
{
    public static int Ack(int m, int n)
    {
        if (m == 0)
            return n + 1;
        if (n == 0)
            return Ack(m - 1, 1);
        else
            return Ack(m - 1, Ack(m, n - 1));
    }

    static void Main(string[] args)
    {
        int n = 11;

        if (args.Length > 0)
            n = Int32.Parse(args[0]);

        Stopwatch timer = Stopwatch.StartNew();

        int res = Ack(3, n);

        Console.WriteLine("Ack(3,{0}): {1}   {2}", n, res, timer.Elapsed);
    }
}

А вот анлог этой функции на Нэмерл полученный мной путем конвертации шарповского кода и немного подчищенный (удалены лишние скобки и сделано верное выравнивание):

using System;
using System.Diagnostics;

class Ackermann
{
    public static Ack(mutable  m : int,mutable  n :  int) :  int
    {
        if (m == 0)
             n + 1;
        else     if (n == 0)
             Ack(m - 1, 1);
        else
             Ack(m - 1, Ack(m, n - 1));
    }

    static Main(mutable  args :  array [string]) :  void
    {
        mutable  n = 11;

        when (args.Length > 0)
            n = Int32.Parse(args[0]);

        mutable  timer = Stopwatch.StartNew();

        mutable  res = Ack(3, n);

        Console.WriteLine("Ack(3,{0}): {1}   {2}", n, res, timer.Elapsed);
    }
}

Результат при выолнении на Pentium M 1.7 MGhz:

C:\VS\Nemerle>Ackermann-n.exe
Ack(3,11): 16381   00:00:00.8386434

C:\VS\Nemerle>Ackermann-cs.exe
Ack(3,11): 16381   00:00:01.5771912

Результат на AMD 64 3500+:

c:\Temp\007>Ackermann-n.exe
Ack(3,11): 16381   00:00:00.6920116

c:\Temp\007>Ackermann-cs.exe
Ack(3,11): 16381   00:00:01.3395087

Неплохо! Да? Разница в два раза! А ведь исполняющая система одна и та же — .Net Framework 2.0!
Может по этому поводу запатентовать способ оптимизации C#-приложений? Ну, конвертируем их в Нэмерл... компилируем... получаем в два раза более быстрое приложение!

Для сравнения, вот мсил обоих вариантов.
C#:

.method public hidebysig static int32  Ack(int32 m,
                                           int32 n) cil managed
{
  // Code size       38 (0x26)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  brtrue.s   IL_0007
  IL_0003:  ldarg.1
  IL_0004:  ldc.i4.1
  IL_0005:  add
  IL_0006:  ret
  IL_0007:  ldarg.1
  IL_0008:  brtrue.s   IL_0014
  IL_000a:  ldarg.0
  IL_000b:  ldc.i4.1
  IL_000c:  sub
  IL_000d:  ldc.i4.1
  IL_000e:  call       int32 Ackermann::Ack(int32,
                                            int32)
  IL_0013:  ret
  IL_0014:  ldarg.0
  IL_0015:  ldc.i4.1
  IL_0016:  sub
  IL_0017:  ldarg.0
  IL_0018:  ldarg.1
  IL_0019:  ldc.i4.1
  IL_001a:  sub
  IL_001b:  call       int32 Ackermann::Ack(int32,
                                            int32)
  IL_0020:  call       int32 Ackermann::Ack(int32,
                                            int32)
  IL_0025:  ret
} // end of method Ackermann::Ack

А вот код Нэмерла:

.method public hidebysig static int32  Ack(int32 m,
                                           int32 n) cil managed
{
  // Code size       57 (0x39)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  ldc.i4.0
  IL_0002:  bne.un     IL_000f
  IL_0007:  ldarg.1
  IL_0008:  ldc.i4.1
  IL_0009:  add.ovf
  IL_000a:  br         IL_0038
  IL_000f:  ldarg.1
  IL_0010:  ldc.i4.0
  IL_0011:  bne.un     IL_0023
  IL_0016:  ldarg.0
  IL_0017:  ldc.i4.1
  IL_0018:  sub.ovf
  IL_0019:  ldc.i4.1
  IL_001a:  starg.s    n
  IL_001c:  starg.s    m
  IL_001e:  br         IL_0000
  IL_0023:  ldarg.0
  IL_0024:  ldc.i4.1
  IL_0025:  sub.ovf
  IL_0026:  ldarg.0
  IL_0027:  ldarg.1
  IL_0028:  ldc.i4.1
  IL_0029:  sub.ovf
  IL_002a:  call       int32 Ackermann::Ack(int32,
                                            int32)
  IL_002f:  starg.s    n
  IL_0031:  starg.s    m
  IL_0033:  br         IL_0000
  IL_0038:  ret
} // end of method Ackermann::Ack

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Ради любопытства провел следственный эксперемент. Декомпилировал код созданный компилятором C# в MSIL, добавил префикс tail. к концевым рекурсиям, перекомпилировал ехе-шник с IL-а и запустил. Результат получился такой:

C:\VS\Nemerle>Ackermann.exe
IL with tail. Ack(3,11): 16381   00:00:03.8472174

C:\VS\Nemerle>Ackermann-cs.exe
Ack(3,11): 16381   00:00:01.5490720

C:\VS\Nemerle>Ackermann-n.exe
Ack(3,11): 16381   00:00:00.9073141

То есть джит умудряется в два раза замедлить код если встречает хинт оптимизации.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Сдела еще один эксперемент. Скомпилировал код на VC 8.0:

#include "stdafx.h"
#include "TIME.H"

int Ack(int m, int n)
{
    if (m == 0)
        return n + 1;
    if (n == 0)
        return Ack(m - 1, 1);
    else
        return Ack(m - 1, Ack(m, n - 1));
}

int _tmain(int argc, _TCHAR* argv[])
{
  int n = 11;

  clock_t time1 = clock();

  int res = Ack(3, n);

  printf("Ack(3,%d): %d   %f\n", n, res, 
    (double(clock() - time1) / double(CLOCKS_PER_SEC)));

    return 0;
}

Резульата получился:

C:\VS\Nemerle>AckermannCpp.exe
Ack(3,11): 16381   0.871000

то есть очень близкий к Нэмерловскому.

Из чего можно сделать вывод, что VC похож тоже избавляется от концевой рекурсии. Ну, и что скорость дотнетного кода очень близка к скорость порождаемой C++-ными компиляторами.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Да, и еще одно замечаение. Судя по МСИЛ-у немерла он генерирует код с контрлем переполения. Так что не факт, что если сделать налогичный код на С++, то он не стаент проигрывать дотнетому.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Думаю, что и большинству программистов нужен комплекс. Вопрос тольк в приоритетах.

Угу. Только у тебя в списке нет понятия "мощности языка" (в смысле определения Пола Грейхема):

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

PG> Все языки одинаково мощные, если рассматривать их с точки зрения эквивалентности машине Тьюринга, но это не та мощь, которая важна программисту. (Никто ведь не хотел бы программировать машину Тьюринга). Мощь языка, в которой заинтересован программист, возможно, трудно определить формальными методами, однако одно из объяснений этого понятия заключается в свойствах, которые в менее мощном языке можно получить, только написав на нем интерпретатор для более мощного языка. Если в языке A есть оператор для удаления пробелов из строк, а в языке B его нет, это не делает A более мощным, чем B, так как в B можно написать процедуру, которая делала бы это.

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

В этом плане F# оказался еще сильнее урезан, чем C#... (Механизм "анонимных классов" C# на мой взгляд достаточно заморочен и не тянет на полноценный механизм метапрограммирования. Это IMHO, разумеется...)

Здравствуйте, WolfHound, Вы писали:
WH>И я о томже. При сравнимом колличестве кода во многих случаях С проигрывает.

Вот с этим согласен.

( Кажется мы таки поймали за хвост кота Консенсуса...

)

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

VD>Скорее треп в форумах.

Флейм — пропускаю...

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

Ну и? Тебе кто-то предлагал писать движок игры на erlang-е?
Не передергивай — небыло таких предложений.
И писать SQL-сервер на erlang-е тоже никто не предлагал... Зато несколькими участниками обсуждения (например мной) подчекивалось, что речь идет о прикладном коде.
И SQL, и движок игры — это код системного уровня. К нему совершенно другие требования и другие критерии оптимизации...

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

VD>Мне вот интересно, для Эрлэнга есть профайлер?

Да. В составе дистрибутива.

VD>И кто-нибудь из исползовавших этот язык хоть раз пробовал профайлить свои приложения?

Да.

VD>Между тем высокоуровневость Эрлэнга смотрится столь внушительной тольк на фоне убогости и низкоуровневости С++. Сравни его хотя бы с Шарпом и окажется, что приемущества уже очень туманны.

Как раз сравнивал.

VD> А если вспомнить, что для Эрлэнга нет ни полноценной среды, ни другой инфраструктуры, то получится, что кодировать на Шарпе куда продуктивнее.

По этому поводу писал уже вот
здесь.

EXO>>Erlang — не самый быстый из декларативных языков (OCaml его уделает на раз), но он есть часть полноценной промышленной платформы. И сравнивать его надо с такими же языками платформ.

VD>Не. Эрланг — это язык общего назначения. И сравнивать его нужно с такими же языками. Возможно в контексте некоторых задач.

Нет. Поболе будет.
В состав дистрибутива входят:
— оптимизированный под работу с erlang-ом сервер БД (поддерживающий кластерную архитектуру, систему зеркалирования и механизмы распределенной работы на ненадежных каналах).
— средства для создания надежного многопоточного сервера приложений (или даже точнее "сети взаимосвязанных серверов", когда некоторые из них могут стоять "в цехах", а некоторые "в головном офисе", но выглядеть во вне как единое целое).
— хорошо интегрирующийся с сервером приложений мощный web-сервер. С поддержкой полного комплекта средств для создания web-сервисов.

До комплектации .Net он недотягивает по двум пунктам.
— Средства создания клиентского интерфейса. (Есть, но слабее, чем WinForms.)
— Интегрировання среда разработки. (О ней уже писал. И писал, что не считаю этот момент очень критичным.)

И кое в чем обходит...
— Например, в наличие средств создания компиляторов DSL-языков ("языков предметной области"). Что для современных систем на трехзвенной архитектуре, достаточно существенный момент.

Так что мы имеем дело именно что с прикладной платформой, а вовсе не просто с "языком общего назначения".

VD>Я, например, согласен, что если передо мной стоит задача в которой производительность кода на Эрланге достаточна (например, имеется многопроцессорное железо, а сами рассчеты довольно просты, но их много), и при этом мне нужно написать нечто хорошо масштабируемое, то язык типа Эрланга может оаказаться очень даже подхдящим выбором. Но вы то тут его пиарите как просто каое-то волшебное средсво.

Мне кажется "у страха глаза велики"

Загляни в околодотнетовские эхи, там тоже во многих сообщениях .Net "пиарится как просто каое-то волшебное средсво". Не буду утверждать, что специально...

Будем считать, что пишущим так про .Net он просто нравится. Так вот и erlang пишущим про него просто нравится...

VD>Забудь ссылки на этот бред. "Серьезно проигрывает... в тир раза" ты вряд ли найщешь чесный тест, чтобы Эрлэнг был всего в 3 раза медленее. Эти тесты как ибольшинство подобных просто шарлатанство.

Предположим я здесь с тобой даже и согласился бы... ну и что?
Собственно а что остается, если мы не будем обращать внимания на тесты? Толко реальные продукты.
Так что тогда мы возвращаемся к сообщениям gandalfgrey о разработанной им системе, которая пришла на смену C++ версии. И заказчикам, которые (на сколько мне известно) успешно покупают обновления.

Не, ну можно еще громко кричать "Пиар!!!" "Не верю!!!"...
Тут уж как говорится "вольному — воля, блаженному — рай".

VD>Далее берем код и смотрим:
VD>

VD>public static int Ack(int m, int n) 
VD>{
VD>    if (m == 0) return n + 1;
VD>    if (n == 0) return Ack(m-1, 1);
VD>    else return Ack(m-1, Ack(m, n-1));
VD>}
VD>

VD>Что же мы видим? Ух ты! Концевая рекурсия на императивном языке! Зашибись. Чтобы разоблочить этих подтасовшиков достаточно объяснить, что современные компиляторы C# просто не делают оптимизации устранения концевой рекурсии.

Здесь расходящееся дерево. Оно и erlang-ом полностью не разверуто.
Что и видно из результатов теста. Для полноценной хвостовой рекурсии стоило бы написать алгоритм с парой "накопителей". Так что похоже erlang-овцы как раз старались "играть честно".

Ну а в остальном, я уже сказал.
Предположим, уберем тесты. Что останется?
— Рекламные заявления от того же MS? А почему я им должен верить больше?
— Реальные проекты? Ну дак они дают достаточно хорошую для erlang-а картину.
— Твои заявления о том, что "не может быть, потому, что не может быть никогда"? Для меня тоже звучат неубедительно, поскольку от "теретических умозаключений" до реальности "дистанция огромного размера".

EXO>>То есть одна из основных "родных" областей Erlang-а — анализ ситуаций (в сумме например с некотрым количеством вычислений или управляющих воздействий).

VD>То есть, Эрлинг не годится для вычислительных задач, раз уж столь претенциозные тесты и то показали, что Эрлинг постоянно проигрывает даже самой фиговой реализации C#.

Правильно. Для этого есть Fortran, С... Или например OCaml.
Прочитай квотинг. Я где-нибудь предлагал использовать erlang "для вычислительных задач"?

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

Есть. OCaml, например...
Но. Это пока именно языки, а не "платформы". Когда "обрастут жирком", могут оказаться очень даже хорошим вариантом.

VD>В общем, я не против Эрлинга или любой другой экзотики. Просто описывая его приемущества неплохо было бы так же упомянуть и о недостатках,

Пока не начался флейм, в половине сообщений назывались и недостатки.
Вот здесь, например.
Тебе показалось, что недостатков названо недостаточно?

Ну дак "перца и соли — по вкусу..."

VD> а так же оратить внимание на то, что язык применим и эффективен в оределенном классе задачь.

Для этого достаточно внимательно читать...
Даже в квотинге этого сообщения:
EXO>>То есть одна из основных "родных" областей Erlang-а — анализ ситуаций (в сумме например с некотрым количеством вычислений или управляющих воздействий).

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

VD>Не удивит, не удивит. Не может никакая машина создать код более умный чем специалист на более низкоуровневом языке. В принципе не может.
Это верно. Но есть одна проблема — время и усилия, потребные на написание шустрого кода на низкоуровневом языке. Вот уж на что я люблю ассемблер, но писать на нем ( что-то практическое ) за последние 8 лет довелось только один раз : функцию для чтения процессорного таймера через RDTSC

VD>Приемущество Эрленга не в том, что он код более крутой генерирует, а в том, что он более выскоуровневый и позволяет проще описать задачу. Но вот в области быстродействия Эрлэнг полная задца, так как рассчитан на отсуствие типизации.
а это как-то слабо влияет на РЕАЛЬНОЕ быстродействие. я его выбрал как основной инструмент еще и по причине предсказуемости быстродействия, в отличие от С++, где с этим проблемы при смене масштабов нагрузок/потоков/обьемов...

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

VD>Ага. Золотые слова. И я бьюсь об заклад, что у каждого человека человекомесяц разный.
Есть некое среднее значение

VD>Ой, с нуля ли? А может в виду, того что был прототип на С++ ты просто знал что писать и не тратил время на эксперементы?
Ну, не без того, конечно — но все ж очень много изменилось

VD>Ну, а если мы потом попробуем сравнить быстродействие (после оптимизаций), то я даже не сомневаюсь, что я получу более быстрое решение. И это на отндь не идельно компиляторе. Через пару лет компиляторы Явы и C# сравняются по скорости с С++-ным, а уровень языков будет только рости. Дальше делай выводы сам.
Это вопрос тонкий...Быстродействие в данном случае — далеко не все. Устойчивость и надежность гораздо важнее

G>>А про биллинг на С++/Жабе лучше и не упоминать !
VD>Упоминай не упоминай, но в нашей стране он на них и как видишь миллионов 50 пользуются результатом и более чем довольны.
Вот только почему-то те из моих знакомых, кто занимаются эксплуатацией этих систем, матюкаются на них со страшной силой.

VD>Логические же ошибки будут на любом языке.
Оно конечно — поэтому, чем выразительней язык, тем проще их найти

VladD2 wrote:
> Здравствуйте, CrazyPit, Вы писали:
> CP> А если нужно просто проверить на тип входной параметр то это легко.
>
> Интересно как? В конце концов параметр может быть функцией возвращающей
> булево значение при выполнении. К тому же большинство кода не
> типизированно так что с него вообще до выполнения ничего не получишь.
> Ну, и опять возвращаемся к вопросу что называть Лиспом. В Схеме макросы
> отличные, а средств работы с типами нема.
Новые средства синтаксиса, как здесь — это, вроде, дословно syntax-rules
Схемы (в простейших случаях, дальше, вероятно, небольшие отличия),
только на языке с нормальным синтаксисом. Я на своём препроцессоре
Паскаль такой функциональности добивался (правда, в узких случаях — но
мне они очень помогли). В Лиспе (вероятно, в любом, даже в Схеме
реализуются негигиеничные макросы) это что-то типа

    (defmacro if (c x y)
      `(cond
        (,c ,x)
        (t ,y)
        )
      )

— макрос просто представляет из себя не генератор кода, а сам код,
который получится (с некоторыми поправками).
> CP> А некоторые вещи вообще не возможны, типа анофорических макр.
>
> Что означает "анофорических"?
>
> CP>
>
> CP>(awhen (compr x y)
> CP> (blah it))
> CP>
>
>
>
> CP>раскрывается в
>
> CP>
>
> CP>(let (it (compr x y))
> CP> (when it
> CP> (blah it))
> CP>
>
>
>
> Не въехал, а что тут необычного?
В исходном вызове it не упоминается. Им становится первый параметр на
время вычисления второго. Некоторый способ сэкономить на печати let и —
самое главное — на их синхронной модификации. Ещё один шаг на пути к
исчезновению copy-paste в программировании.

Posted via RSDN NNTP Server 2.0

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

M>Ну, этого никто на отменял. Например в Эрланге нет библиотеки SOAP (она, правда, никому пока особа и не нужна была — все же там уже есть CORBA, ASN.1, легкая работа с binary да и вообще — он же distributed по определению, так?

). Вот я сейчас тоже думаю — а оно мне надо?

А хочется написать, да

А вот уже есть такой ErlSOAP, в сетях болтается. Люди используют и вроде бы довольны

VladD2 wrote:
>
> Все восхваления лиспа обычно разбиваются на две части:
> 1. Ах Лисп позволяет писать в функциональном стиле.
> 2. Ах какое в Лиспе метапрограммирвание/макросы.
>
Вопросы: Немерле отделим от дотнета? Имеет интерепретатор? Позволяет
использовать весь язык без ограничений в описаниях макросов?
Хотелось бы нет-да-да. И поставить на наладонник вместо схемы.. И
бросить писать свою обёртку над Си с целью иметь синтаксис Паскаль,
компилятор от Си и макросы от Лисп.

Posted via RSDN NNTP Server 2.0

M>>Руки

И объем работы, который обычно с этим связан. Люблю я, когда все до меня уже сделано и разжевано

VD>Ну, извини, тут советуют Эрлэнг как некую манну небесну.

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

Что считать низкоуровневым?

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

+1

VD>Так что весма странно, что приемуществом языка является заточенность его под один довольно узкий круг задач.

Весьма неплохой круг задач, однако — Making reliable distributed systems in the presence of hardware errors

VD>Мне всегда казалось, что хороший язык тот который позволяет быстро и просто написать эффективное решение для большинства задач.

"Нельзя объять необъятное" (с) Козьма Прутков

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

Кстати, в моем случае интерес к Эрлангу вызван имено возможностью легко написать многпоточную систему клиент-сервер, не заморачиваясь с деталями реализации протоколов передачи по сети, самими потоками, и так далее.

Согласен, все это можно сделать и в C# и в Яве

Но я не ищу легких путей (или все же ищу?

)

VD>Если уж выбирать по библиотекам и закладкам, то кроме как на дотнет и на Яву вообще можно ни на что не смотреть. У них библиотеки самые обширные.

Возможно. Но какая часть из этих библиотек используется? 10%? Еще меньше?
Все, что мне надо, пока есть

А если понадобится что-нибудь "странно", то его и в .NET'e и Яве будет сложновато найти, ИМХО.

VD>Вот Нэмерл как раз и привосходит Лисп, или хотя бы не уступает Лиспу, в этих показателях, при этом являюсь куда более привычным и поддерживая (исходно, а не как расширение) статическую типизацию.

VD>В итоге языки вроде Нэмерла и Скалы преращают фанатов Лиспа из борцов со штампами в их ярых защитников.

Надо будет пощупать за вымя

M>>Ну, этого никто на отменял. Например в Эрланге нет библиотеки SOAP (она, правда, никому пока особа и не нужна была — все же там уже есть CORBA, ASN.1, легкая работа с binary да и вообще — он же distributed по определению, так?

). Вот я сейчас тоже думаю — а оно мне надо?

А хочется написать, да

VD>А написав ты поймешь, что она принципиально медленее того что можно было написать на статически типизированном языке.

Ну, для SOAP'a это некритично

VD>Причем, учитывая слова явно не предвзятого Гапертона, ты еще потрахашся со строками при этом.

Увы

VD>В итоге твоя реализация будет и хуже, и сложнее.

Возможно

VD>Так стоит ли проливать столько соплей по поводу динамически типизированного языка развиваемого довольно мало значащей в индустрии конторой?

здесь

Telecom Trends International (TTI) has ranked Ericsson as the top supplier of next-generation mobile infrastructure in terms of revenue. In a 2003 report, “3G Mobile Networks: Vendor Positioning and Deployment Strategies,” the research firm estimates that Ericsson’s share of the 2.5/3G mobile infrastructure market to be 20.9 percent. The next vendor in terms of market position is Nortel Networks with a share of 19.0 percent. The other two companies with market shares in double digits are Nokia and Lucent Technologies. The Siemens/NEC alliance ranks the next followed by Motorola. The other significant players in the market are Samsung and Alcatel.

Nortel сейчас тоже использует Эрланг в своих системах...

Правда, если изменить фразу на "довольно мало значащей в IT индустрии конторой", то да — увы

... << RSDN@Home 1.2.0 alpha rev. 619>>

). Вот я сейчас тоже думаю — а оно мне надо?

А хочется написать, да

G>А вот уже есть такой ErlSOAP, в сетях болтается. Люди используют и вроде бы довольны

Он незадокументирован, использует старую версию xmerl и не развивается

Я, правда, все еще не дотянулся пощупать его руками

... << RSDN@Home 1.2.0 alpha rev. 619>>

Здравствуйте, Mamut, Вы писали:
M>Он незадокументирован, использует старую версию xmerl и не развивается

Это да. Правильно они сделали, что не стали включать его основной в дстрибутив.

Вообще говоря, если задумывать разаботку соответсвующей библиотеки, то прежде всего стоит разобраться, что делать с "зоопарком SOAP-ов". Коий только "выглядит как стандарт" (ну типа "совсем как живой"). А посмотреть реальную совместимость Java и .Net версии, и вылазит вагон подводных камней.
Я вот ушел на XML-RPC, просто потому, что надоело натыкаться на "непонимание" то одних, то других клинтских библиотек.
Так что может стоит дождаться, пока SOAP несколько устоится...

EXO>Вообще говоря, если задумывать разаботку соответсвующей библиотеки, то прежде всего стоит разобраться, что делать с "зоопарком SOAP-ов". Коий только "выглядит как стандарт" (ну типа "совсем как живой"). А посмотреть реальную совместимость Java и .Net версии, и вылазит вагон подводных камней.

Если честно, мне SOAP вообще не нужен

Для внутренних нужд я планирую Erlang как на сервере, так и на клиенте. Мне просто хочется синхронизатор с РСДНом написать не Эрланге

Но это — чур, только между нами

EXO>Я вот ушел на XML-RPC, просто потому, что надоело натыкаться на "непонимание" то одних, то других клинтских библиотек.
EXO>Так что может стоит дождаться, пока SOAP несколько устоится...

А он устоится? "Не верю" (с)

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

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

VD>А почему так сложилось исторически и не перекладывается сейчас?

CP>>также как например с виндой. Рынок никогда не завоёвывают самые лучшие решения

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

VD>Просто у рынка другие критерии нежели от отдельных личностей. То что ты считашь важным, не важно для большинтсва и надоборот.

[Небольшой офтоп, сорри]

Хорош, винду оставим в стороне, возьмём более радикальный пример: CISC vs. RISC процессоры. Причём возьмём явного лидера — интел, есть линейка X86 и выход из проблемности цискового направления развития процессоров — Itanium. Далеко не секрет, что последний даёт далеко не слабые преимущества по оптимизации кода, т.е. реальный выигрыш в скорости приложений, но вот рынок его не так просто "ест", потому Интел с ХулитПаккардом вот недавно приняли решение, кажись, 10 милиардов вложить в, по сути, пропагандирование итаниума. Т.е. ты считашеь что для большинства критерий скорости неважен? Хотя тут несколько сложнее, т.к. это далеко не единственный критерий (самый сильный противодействующий — преемственность решений)

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

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

EXO>Ну и? Тебе кто-то предлагал писать движок игры на erlang-е?
EXO>Не передергивай — небыло таких предложений.

Кстати, были такие проекты

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

EXO>И писать SQL-сервер на erlang-е тоже никто не предлагал... Зато несколькими участниками обсуждения (например мной) подчекивалось, что речь идет о прикладном коде.
EXO>И SQL, и движок игры — это код системного уровня. К нему совершенно другие требования и другие критерии оптимизации...

Кстати, были такие проекты

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

К>[Небольшой офтоп, сорри]

Если тема разовьется, снесу ее в Философию.

К>Хорош, винду оставим в стороне, возьмём более радикальный пример: CISC vs. RISC процессоры. Причём возьмём явного лидера — интел, есть линейка X86 и выход из проблемности цискового направления развития процессоров — Itanium. Далеко не секрет, что последний даёт далеко не слабые преимущества по оптимизации кода, т.е. реальный выигрыш в скорости приложений, но вот рынок его не так просто "ест", потому Интел с ХулитПаккардом вот недавно приняли решение, кажись, 10 милиардов вложить в, по сути, пропагандирование итаниума. Т.е. ты считашеь что для большинства критерий скорости неважен? Хотя тут несколько сложнее, т.к. это далеко не единственный критерий (самый сильный противодействующий — преемственность решений)

Дык Итаниум откровенно проигрывает Оптеронам в рельных приложениях. И не важно почему. При этом он неудобен, дорог и непривычен. Так что рынок его не даром не принимает. На лицо банальное несоотвествие заявленных приемуществ и реальности.

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

А что до РИСК... На сегодня почти все процессоры РИСК. Только внутри. Фанаты РИСК-архитектуры не учли того, что внешний интерфейс важен для пользователя и не важен для реализации.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, Gaperton, Вы писали:
G>Кстати, были такие проекты

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

Можно разделить логику движка, вычленив оттуда поведеньческий элемент (и может быть анализ стокновений).
И это сделать на эрланге. Но основное ядро скорее всего придется оставить С-шным.
Да и вообще для игр с серьезной динамикой я бы такой вариант использовать не стал.
Так что это скорее эксперименты и попытки нащупать "границы применимости"...

G>Кстати, были такие проекты

. Mnesia, входящая стандартную поставку — вполне себе движок базы данных, и довольно неплохой. Особенно, если к нему BerkleyDB backend подключить. Это, кстати, вполне нормально — все равно в диск затыкается...

Здесь два возражения:
1. Мнезия все-таки не SQL, и не ставит своей задачей всенеприменно шустро выполнять даже кривые запросы. И соответсвенно "тупое быстродействие" у хороших SQL все-таки повыше будет. (Мнезия сорее может существенно выиграть по пыстродействию, за счет использования других алгоримов и структур данных.)
2. BerkleyDB — таки C-шная тулзовина. Так что это как раз получается правильное "разделение обязанностей".

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

Если я все правильно понял, то на Нэмерле можно все тоже самое и намного болше. А главное роще, предсказуемее и удобнее.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

R>Вопросы: Немерле отделим от дотнета?

Приципиально — конечно. Язык есть язык. Лисп тоже под дотнетом чувствует себя отлично.
Рельно — нет. Он под него создавался.

R> Имеет интерепретатор?

Да — http://nemerle.org/Nemerlish. Но не вижу в этом смысла.

R> Позволяет
R>использовать весь язык без ограничений в описаниях макросов?

Они на нем и пишутся.

R>Хотелось бы нет-да-да. И поставить на наладонник вместо схемы..

Почему бы и нет. Незнаю нафиг прада нужны средства разработки на КПК, но

R> И бросить писать свою обёртку над Си с целью иметь синтаксис Паскаль,
R>компилятор от Си и макросы от Лисп.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

M>Что считать низкоуровневым?

Ну, хотя бы вычислительные и другие требовательные к процессору и памяти алгоритмы.

VD>>Мне всегда казалось, что хороший язык тот который позволяет быстро и просто написать эффективное решение для большинства задач.

M>"Нельзя объять необъятное" (с) Козьма Прутков

А почему необъятное? Конкретная задача очень даже "объятна". И для нее всегда можно создать эффективное и красивое решение.

M>Если есть возможность эффективно решить отдельный класс задач специально заточенным для этого дела инструментом, то поему бы и нет?

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

M>Возможно. Но какая часть из этих библиотек используется? 10%? Еще меньше?

Используется все. Просто разными людьми и в разное время. Когда я пишу редактор мне не нужен ремоутинг. А когда сервер, то мне не нужны многие вещи кторые я испльзовал для создания редактора.

M>Все, что мне надо, пока есть

А если понадобится что-нибудь "странно", то его и в .NET'e и Яве будет сложновато найти, ИМХО.

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

M>Надо будет пощупать за вымя

Пощупай. Если ближе Ява, то щупай Скалу. Если дотнет и любишь эффектиность, то Нэмерел. По крайней мере на меня эти языки произвели самое приятное впечатление. Лучшего сочетания самых продвинутых парадигм я еще не видел. 100%-ная поддержка ООП, ФП, ПП, МП. Осталось только пролог в них включить.

VD>>А написав ты поймешь, что она принципиально медленее того что можно было написать на статически типизированном языке.

M>Ну, для SOAP'a это некритично

Ой как критично. Объемы передачи данных бывают большими и если у тебя при слабом трафике все камни кепят — это не очень хорошо.

VD>>В итоге твоя реализация будет и хуже, и сложнее.

M>Возможно

Дык, значит не все спокойно в королевстве датском?

M>Nortel сейчас тоже использует Эрланг в своих системах...

M>)

Ты работаешь в области телекомуникаций? И вообще что тебе до Nortel?
Вон куча разных бирж работают на дотнете и Яве. И что с того?

M>Правда, если изменить фразу на "довольно мало значащей в IT индустрии конторой", то да — увы

Я об IT и говорил. Рынок железячников и их часных решений мне не интересен. Тот же Эрланг интересен именно как язык общего назначения.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>Это верно. Но есть одна проблема — время и усилия, потребные на написание шустрого кода на низкоуровневом языке. Вот уж на что я люблю ассемблер, но писать на нем ( что-то практическое ) за последние 8 лет довелось только один раз : функцию для чтения процессорного таймера через RDTSC

Совершенно согласен. Но почему народ забросил ассемблер? Да потому, что цена/производительность никакая. Код на С/С++ будет на больших объемах на 10-100 процентов медленее, а затраты на переписывании его на ассемблере и особенно на отладку его после этого будут в сотри раз больше! Другими словами С/С++ дает созмеримый результат при намного большей производительности программиста.

В общем, разница между уровнями языков огромна, а между получаемым результатом мизерна. К тому же чтобы получить выигрышь нужно еще быть очень некислым специолистом в конкретном процессоре (модели)! А процессоров то море. И то что будет летать на AMD64 не факт что будет так же быстро работать на P4.

Ну, а с языками более высокого уровня все совсем не так. Разница между тем же Эрлэнгом и C# в уровне очень спорна. Не уверен, что Эрлэнг вообще имеет какие-то глобальные приемущества. Если они и есть, то в сугубо специализированных случаях и не столь радикальны как в случае между С и ассемблером.

Темвременем разница между С/С++ и типобезопасными языками с поддержкой сборки мусора очень велика, а разница в производительности очень мала. Причем первая растет, а вторая сокращаетс. В общем, мы имеем ту же ситуацию что с С и ассемблером много лет назад.

VD>>Приемущество Эрленга не в том, что он код более крутой генерирует, а в том, что он более выскоуровневый и позволяет проще описать задачу. Но вот в области быстродействия Эрлэнг полная задца, так как рассчитан на отсуствие типизации.
G>а это как-то слабо влияет на РЕАЛЬНОЕ быстродействие.

Я бы сказал что отсуствие типизации (вывода типов, деларации типов или их сочетания) — это приговор производительности для высокоуровневого языка.

G> я его выбрал как основной инструмент еще и по причине предсказуемости быстродействия, в отличие от С++, где с этим проблемы при смене масштабов нагрузок/потоков/обьемов...

Хм. А чем же это его быстродействие предсказуемо? В смысле предсказуемо низкое?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

EXO>И вот "мощность языка" в этом смысле мне важна.
EXO>Год назад я основательно пробовал микрософтовский F#, в надежде, что ребята сделают реальные средства для "метопрограммиования" (напрмер, нормальные лямбды, с которыми удобно работать). И обломился

EXO>В этом плане F# оказался еще сильнее урезан, чем C#... (Механизм "анонимных классов" C# на мой взгляд достаточно заморочен и не тянет на полноценный механизм метапрограммирования. Это IMHO, разумеется...)

В C# нет никаких анонимных классов. В 3.0 ожидается появление анонимных типов, но они к метапрограммированию отношения не имеют.

Если тебе нужен язык со встроенными возможностями метапрограммирования, то круче Немерла и возможно Скалы я еще ничего не видел.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Ну, а с языками более высокого уровня все совсем не так. Разница между тем же Эрлэнгом и C# в уровне очень спорна. Не уверен, что Эрлэнг вообще имеет какие-то глобальные приемущества. Если они и есть, то в сугубо специализированных случаях и не столь радикальны как в случае между С и ассемблером.
Ежели говорить о реальном применении языков, то свое место находит и Тикль. Казалось бы, уж на что тормознутый язык, а все ж весьма часто писать на нем — вполне оправдано. Уровнем он все ж повыше, чем С++, и вполне сравним с Сшарпом ( как мне кажется )

VD>Я бы сказал что отсуствие типизации (вывода типов, деларации типов или их сочетания) — это приговор производительности для высокоуровневого языка.
Опять-таки говорить изволите о сырой производительности, она же row performance ? В этом случае соглашусь, но только в этом случае. При любом осмысленном действии, а не сложении чисел в цикле, динамическая типизация становится чрезвычайно полезной.

VD>Хм. А чем же это его быстродействие предсказуемо? В смысле предсказуемо низкое?

Я как-то не жалуюсь на его быстродействие. Конечно, float points могли бы и побыстрее обрабатываться...А предсказуемость его заключается в том, что после некоторого ( небольшого ) опыта работы с Ерлангом становится очевидным производительность тех или иных участков кода.

VD>Может Инаниму и крут,

но, говорят, Илланипи еще круче

Без обид, просто опечатка великолепная

... << RSDN@Home 1.2.0 alpha rev. 619>>

M>>Что считать низкоуровневым?
VD>Ну, хотя бы вычислительные и другие требовательные к процессору и памяти алгоритмы.

Ааа, ну это да. Тут все равно от С никуда не деться

VD>>>Мне всегда казалось, что хороший язык тот который позволяет быстро и просто написать эффективное решение для большинства задач.

M>>"Нельзя объять необъятное" (с) Козьма Прутков

VD>А почему необъятное? Конкретная задача очень даже "объятна". И для нее всегда можно создать эффективное и красивое решение.

M>>Если есть возможность эффективно решить отдельный класс задач специально заточенным для этого дела инструментом, то поему бы и нет?

VD>Потому что всегда найдется другой с которым будут проблемы. Лучше иметь единый универсальный инструмент.

Все равно где-то универсальный инструмент будет хуже, чем специально заточенный. Ну, это уже в область Философии и СВ.

M>>Возможно. Но какая часть из этих библиотек используется? 10%? Еще меньше?
VD>Используется все. Просто разными людьми и в разное время. Когда я пишу редактор мне не нужен ремоутинг. А когда сервер, то мне не нужны многие вещи кторые я испльзовал для создания редактора.

Возможно-возможно. Все равно его (дотнета), по-моему, слишком много

Правда, потом, возможно, открываются чакры на все многообразие. Но когда я его, помнится, щупал, меня жутко раздражало наличие такое количества всего сразу

Правда, я не говорю, что это плохо.

M>>Все, что мне надо, пока есть

А если понадобится что-нибудь "странно", то его и в .NET'e и Яве будет сложновато найти, ИМХО.
VD>В них ты можешь написать это "странноу" и оно будет работать достаточно эффективно. А вот на Эрланге тебе прийдется использовать еще один язык. Это само по себе геморрой, а учитывая, что реально Эрлэнг интегрируется (как я понял) с С/С++, это в двойне геморройно.

Есть еще интерфейс к Яве (jinterface). В jungerl порт jinterface на C#/ Не знаю, правда, насколько он хорош.

Но, да, количество готовых библиотек для Дотнета и Явы впечатляет

VD>Пощупай. Если ближе Ява, то щупай Скалу. Если дотнет и любишь эффектиность, то Нэмерел. По крайней мере на меня эти языки произвели самое приятное впечатление. Лучшего сочетания самых продвинутых парадигм я еще не видел. 100%-ная поддержка ООП, ФП, ПП, МП. Осталось только пролог в них включить.

Ну так нечестно

Столько языков хороших и разных

Я и так уже себя не Мамонтом чуствую, а в лучшем случае лягушкой

— столько прыжков: Лисп, Хаскель, Эрланг...

VD>>>А написав ты поймешь, что она принципиально медленее того что можно было написать на статически типизированном языке.
M>>Ну, для SOAP'a это некритично

VD>Ой как критично. Объемы передачи данных бывают большими и если у тебя при слабом трафике все камни кепят — это не очень хорошо.

Ну, если они большие (RSDN например? или еще больше?) — тогда ну его нафиг

Тогда уж лучше дествительно C# или Яву взять.

VD>>>В итоге твоя реализация будет и хуже, и сложнее.
M>>Возможно

VD>Дык, значит не все спокойно в королевстве датском?

А я и не отрицал

Я, правда, и не соглашался

В моем конкретном случае меня пока настораживает поддержка/неподдержка Юникода в Эрланге. Это может стать критичным вопросом. Хотя многие тулзы/приложения с Юникодом справляются — xmerl, ejabberd, yaws... В общем, это надо смотреть.

M>>Правда, если изменить фразу на "довольно мало значащей в IT индустрии конторой", то да — увы
VD>Я об IT и говорил. Рынок железячников и их часных решений мне не интересен. Тот же Эрланг интересен именно как язык общего назначения.

Тут раскрою страшную тайну

По мотивам рассылок и надписей в интернете. Новые фичи в язык вносятся с большим скрипом, так как он используется в Эрикссоне и 100% обратная совместимость им нужна, как воздух. Так, records были добавлены в язык без проблем, так как они реализуются через кортежи (хоть и были они туда добавлены, насколько я понимаю, довольно поздно). А вот более "продвинутые" фичи туда хрен добавишь — слишком дорого обойдется возможность накрыть http://www.ericsson.com/ericsson/corpinfo/ publications/review/1998_01/files/1998012.pdf медным тазиком.

Эххх... Пойти, что ли, Немерл почитать....

... << RSDN@Home 1.2.0 alpha rev. 619>>

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

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

VD>>Ага. Золотые слова. И я бьюсь об заклад, что у каждого человека человекомесяц разный.
G>Есть некое среднее значение

Ага. Средняя температура по больнице всегда 36.6.

G>Это вопрос тонкий...Быстродействие в данном случае — далеко не все. Устойчивость и надежность гораздо важнее

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

G>Вот только почему-то те из моих знакомых, кто занимаются эксплуатацией этих систем, матюкаются на них со страшной силой.

А много у тебя знакомых кто занимается эксплуатацией систем на Эрленге? Глядишь было бы много и они матюкались. А я вот клиент МТС и меня более чем устраивает их работа. А как там матюкаются их админы не мое дело.

VD>>Логические же ошибки будут на любом языке.
G>Оно конечно — поэтому, чем выразительней язык, тем проще их найти

А в чем выражается выразительность? Не уж то в минимализации количества закорючек на экране?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

EXO>Как раз сравнивал.

Ну, вот бы и поделился бы тем что и как сравнивал.
За одно расскзал бы что сравнивал. Нибусь опять с С++.

VD>> А если вспомнить, что для Эрлэнга нет ни полноценной среды, ни другой инфраструктуры, то получится, что кодировать на Шарпе куда продуктивнее.

EXO>По этому поводу писал уже вот
EXO>здесь.

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

VD>>Не. Эрланг — это язык общего назначения. И сравнивать его нужно с такими же языками. Возможно в контексте некоторых задач.

EXO>Нет. Поболе будет.
EXO>В состав дистрибутива входят:
EXO>- оптимизированный под работу с erlang-ом сервер БД (поддерживающий кластерную архитектуру, систему зеркалирования и механизмы распределенной работы на ненадежных каналах).

Смешно. Пересометрия в чистом виде. Иди сравни это БД-сервер с поставляемым в составе студии MS SQL Server 2005. Боюсь без полного отрешения от жизни серьезным такое сравнение назвать будет сложно.

EXO>- средства для создания надежного многопоточного сервера приложений (или даже точнее "сети взаимосвязанных серверов", когда некоторые из них могут стоять "в цехах", а некоторые "в головном офисе", но выглядеть во вне как единое целое).

Это конечно здорово. Но это и есть единственный аргумент стоящий упоминания во всех словах защитников Эрлэнга. В остальном это похоже на фанатизм с притягиванием за уши.

EXO>- хорошо интегрирующийся с сервером приложений мощный web-сервер. С поддержкой полного комплекта средств для создания web-сервисов.

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

EXO>До комплектации .Net он недотягивает по двум пунктам.
EXO>- Средства создания клиентского интерфейса. (Есть, но слабее, чем WinForms.)
EXO>- Интегрировання среда разработки. (О ней уже писал. И писал, что не считаю этот момент очень критичным.)

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

EXO>И кое в чем обходит...
EXO>- Например, в наличие средств создания компиляторов DSL-языков ("языков предметной области"). Что для современных систем на трехзвенной архитектуре, достаточно существенный момент.

Да уж. Куда там таким вещам как метапрограммирование в Скале и Немерле, или построителям парсеров вроде АНТЛР или КокаР.

EXO>Так что мы имеем дело именно что с прикладной платформой, а вовсе не просто с "языком общего назначения".

Я бы сказал больше. С платформой заточеной под конкретные задачи.

EXO>Мне кажется "у страха глаза велики"

EXO>Загляни в околодотнетовские эхи, там тоже во многих сообщениях .Net "пиарится как просто каое-то волшебное средсво". Не буду утверждать, что специально...

Будем считать, что пишущим так про .Net он просто нравится. Так вот и erlang пишущим про него просто нравится...

Хм. Дотнет по мне так сильно универсальнее. Это именно что платформа.

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

Да думать нужно своей головой. А тесты можно и самому сделать.

EXO>Так что тогда мы возвращаемся к сообщениям gandalfgrey о разработанной им системе, которая пришла на смену C++ версии. И заказчикам, которые (на сколько мне известно) успешно покупают обновления.

Он явно применял С++ там где не следовало.

EXO>Здесь расходящееся дерево. Оно и erlang-ом полностью не разверуто.

И не нужно. Вопрос в том, что хотя бы устранить проблемы от рекурсивного вызва можно. Вот погляди на то насколкько этот тес быстрее если его выолнить на том же дотнете но скомпилировать на языке устраняющем концевую рекурсию:
Re[20]: преимущества erlang-а?

EXO>Что и видно из результатов теста. Для полноценной хвостовой рекурсии стоило бы написать алгоритм с парой "накопителей". Так что похоже erlang-овцы как раз старались "играть честно".

Ничесно, или не компетентно пытались играть создатели теста.

EXO>Ну а в остальном, я уже сказал.
EXO>Предположим, уберем тесты. Что останется?

Ненадо их убирать. Но и на конкретно эти смотреть не стоит. Это явная подтасовка.

EXO>- Твои заявления о том, что "не может быть, потому, что не может быть никогда"? Для меня тоже звучат неубедительно, поскольку от "теретических умозаключений" до реальности "дистанция огромного размера".

Мои заявления так не звучат. Мои заявления звучат очень просто и доходчиво и не понимает их сути только тот кто пытается специально это не понять или те кто не компетентен в данном вопросе. Суть их проста. Чтобы сгенерировать действительно эффективный код язвк должен быть компилируемым, минимизировать рантайм проверки и не делать ничего универсально. Это требование не выполнимо если язык динамически типизированный. Язык должен позволять декларировать типы и/или производить вывод типов. Насколько я понимаю Эрленг ни ктого, ни другог не поддерживает. А раз так никогда в жизни он не подойдет к скорости обеспечиваемой компилируемыми языками.

EXO>Правильно. Для этого есть Fortran, С... Или например OCaml.

Можно сказать проще. Статически типизированные, компилируемые языки.

EXO>Прочитай квотинг. Я где-нибудь предлагал использовать erlang "для вычислительных задач"?

Я почитал восхищения в ответ на тематический вопрос. И не увидил там ни одного упоминания того, что Эрлэн не предназначен для серьезных вычислений.

EXO>Есть. OCaml, например...

Есть много чего.

EXO>Но. Это пока именно языки, а не "платформы". Когда "обрастут жирком", могут оказаться очень даже хорошим вариантом.

Забавный потребительский подход. Вот для Явы взяли и реализовали нужные фрэймворки. Да еще и во множестве разных версий и подходов.

EXO>Пока не начался флейм, в половине сообщений назывались и недостатки.
EXO>Вот здесь, например.
EXO>Тебе показалось, что недостатков названо недостаточно?

Хм. Читаем:

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

А потом идем даже в приведенные тесты и видим, что это не плохо колеблится между 50 и 10 разами по сравнению со статически типизированными языками. Это из серии критики "И никакой вы не вилики! Вы просто выдающийся Король!".

EXO>Ну дак "перца и соли — по вкусу..."

Я не хочу соли и перца. Я хочу трезвости взглядов.

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

EXO>Для этого достаточно внимательно читать...

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

EXO>Даже в квотинге этого сообщения:
EXO>>>То есть одна из основных "родных" областей Erlang-а — анализ ситуаций (в сумме например с некотрым количеством вычислений или управляющих воздействий).

Хм. Скрипты?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>Ежели говорить о реальном применении языков, то свое место находит и Тикль. Казалось бы, уж на что тормознутый язык, а все ж весьма часто писать на нем — вполне оправдано. Уровнем он все ж повыше, чем С++, и вполне сравним с Сшарпом ( как мне кажется )

Кто такой Тикль?

VD>>Я бы сказал что отсуствие типизации (вывода типов, деларации типов или их сочетания) — это приговор производительности для высокоуровневого языка.
G>Опять-таки говорить изволите о сырой производительности, она же row performance ? В этом случае соглашусь, но только в этом случае. При любом осмысленном действии, а не сложении чисел в цикле, динамическая типизация становится чрезвычайно полезной.

Полезной? Не сказал бы. Но мы говорим о скорости. Общая производительность в конце концов завист от той что ты называшь "сырой".

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

VD>>Хм. А чем же это его быстродействие предсказуемо? В смысле предсказуемо низкое?

G>Я как-то не жалуюсь на его быстродействие.

"Нежалуюсь" это не предсказание. Это просто твои задачи не стольк требовательны к процессору. Или пакетные и тебе пофигу сколько они выполняются.

G> Конечно, float points могли бы и побыстрее обрабатываться...

И int, и обработку объектов, и вообще все. Но для этого пришлось бы всерьез задуматься над тем о чем я говорю — о декларации типов и о выводе типов. И самое смешное, что такие языки есть. Кроме скорости они еще обеспечивают большую однозначсть, что дает выигрышь и в других местах.

G>А предсказуемость его заключается в том, что после некоторого ( небольшого ) опыта работы с Ерлангом становится очевидным производительность тех или иных участков кода.

Хм. А я прекрасно могу оценить производительность кода на С, С++, C#, Дельфи... если конечно там нет незвесных мне функций. И что?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

M>Ааа, ну это да. Тут все равно от С никуда не деться

Вообще-то С тут уже давно не в одиночестве. Большинство компилируемых языков обеспечивают сравнимую производительность. Тут все уже зависит от качества компилятора. Что совсем не так в случае с динамически типизированными языками.

M>Все равно где-то универсальный инструмент будет хуже, чем специально заточенный.

Мне кажется завист от инстумента и тех кто его развивает.

M>Ну, это уже в область Философии и СВ.

Ага.

M>Возможно-возможно. Все равно его (дотнета), по-моему, слишком много

Правда, я не говорю, что это плохо.

Дык это компонентная среда. Нужные возможности просто подключаются по мере необходимости. Именно это мне и нравится в дотнете.

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

M>Есть еще интерфейс к Яве (jinterface). В jungerl порт jinterface на C#/ Не знаю, правда, насколько он хорош.

Я тоже. И не знаю нужен ли реально Эрлэнг если речь заходит о Яве.

M>Ну так нечестно

Столько языков хороших и разных

Языков много. Хороших, почти нет.

M> Я и так уже себя не Мамонтом чуствую, а в лучшем случае лягушкой

— столько прыжков: Лисп, Хаскель, Эрланг...

По-моему, это все эксперементы ушедшие не в ту степь. Степь которая мне нравится я уже описал.

M>Эххх... Пойти, что ли, Немерл почитать....

... << RSDN@Home 1.2.0 alpha rev. 637>>

On Sat, 28 Jan 2006 04:25:23 +0300, VladD2 <73@users.rsdn.ru> wrote:

> A>используя алгоритмы, которые обгонят алгоритмы, которые (для этих
> классов задач) привычно и
> удобно писать на C++.
> А вот это уже не понял.

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

Наверное можно будет найти дл С++ библиотеку, чтобы релизовала
какой-нибудь интерпретатор ФЯ. Кто из Сишников будет это делать ? И не
факт, что к ней будут легко приложимы другие библиотеки, привычные
разработчику и уж точно не функциональные

--
Отправлено M2, революционной почтовой программой Opera:
http://www.opera.com/mail/

Posted via RSDN NNTP Server 2.0

> VD>> Там нет JIT.
> компилироваться в МСИЛ, и так как там полноценный компилятор получающий
> на вход полностью типизированный МСИЛ.

Да, надо будет почитать, что же за компилятор, и почему он не JIT

> Вопрос был почему рантайм Эрлэн нельзя написать на нем самом же.

А зачем ?
В диссере по Эрлангу сказано, что он не использует ОС-специфичные потоки
(а где-то их нет, наверное) и многие другие вещи, а реализует их сам в
рамках своей VM.
Поэтому в частности VM легче портируется, поскольку меньше зависит от
окружения.

Значит, напишем VM на Эрланге — нужно будет на чем-то писать
ОС-независимые потоки и т.д. Т.е. заново писать большую чатсь VM. И зачем?
чтобы показать "мы тоже могём" ?
Ты же не овзмущаешься, что в Эрланге нет своего TCP-стека, например?

> A>Вдруг что интересное пропустишь? Так нет у Эрлангеров ресурсов
> Microsoft Research.
>
> Эриксон контора тоже не маленькая.

1) Какое отношение Эриксон имеет к Эрлангу ?
2) В другом профиле. Сравнивать Эриксон и МС в части софтостроения...
Примерно так же как в части создания АТС и раутеров, только с обратным
знаком

Не считаю я МС крупной фирмой ф области network hardware, хотя
вообще, в вакууме — крупная, не возразишь. И наверное могла бы лечь
костьми и потеснить Эрикссон. Но только это, вежливо скажем, не
рационально.
3) Просто ради интереса, сколько человек работает в MS Research ?

Posted via RSDN NNTP Server 2.0

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

A>1) Какое отношение Эриксон имеет к Эрлангу ?

Вы таки удивитесь.

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

A>Да, надо будет почитать, что же за компилятор, и почему он не JIT

Кодовое название компилятора Барток. Родился во времена ранней Явы как проект компилятора Ява в исполняемое приложение виндовс.

A>Ты же не овзмущаешься, что в Эрланге нет своего TCP-стека, например?

Вообще-то если мы говорим о процессах, то подразумеваем ОС. А если подразумеваем ОС, то логично было бы ожидать и TCP-стека. В Сингулярити TCP-стек написан как раз на C#. Кстати, говорят по скорости рвет аналог из Винды и Линукса.

A>1) Какое отношение Эриксон имеет к Эрлангу ?

Мне казалось, что одни создал другого.

A>2) В другом профиле. Сравнивать Эриксон и МС в части софтостроения...
A>Примерно так же как в части создания АТС и раутеров, только с обратным
A>знаком

Не считаю я МС крупной фирмой ф области network hardware, хотя
A>вообще, в вакууме — крупная, не возразишь. И наверное могла бы лечь
A>костьми и потеснить Эрикссон. Но только это, вежливо скажем, не
A>рационально.

Хм. Это не мои слова.

A>3) Просто ради интереса, сколько человек работает в MS Research ?

MS Research — это не контора. Это проект МС в который МС вбухивает бабки которые идут на гранты разным институтам и на зарплаты сотрудников работающих над исследовательскими проектами. Так что говорить тут можно толко о количестве проектов (которое извесно) и количестве вбуханых денег.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CP>> Конечно в 6 утра я плохо соображаю, но здесь видимо нужне вывод типов из выражений. В лиспе его нет...

VD>Естественно, так как его макросы — это всего лишь преобразование над АСТ. К компилятору из них не обратишся.

Это как так не обратишься? Весь коммон лисп доступен внутри определения макроса.

VD>Интересно как?

Проверить тип соответсвующей функцией.

(defmacro a (x)
  (if (atom x)
       `(...)
      (error "blah")))

CP>>AST намного удобнее управлять програмно, чем кодом, как в немерле.

VD>Как видишь, особых проблем нет. Более того получается в сто раз понятнее. Причем без специальной дрисеровки пользователя.

Мне понятнее в лиспе:))

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

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

CP>> А некоторые вещи вообще не возможны, типа анофорических макр.

VD>Что означает "анофорических"?

Типа местоимение. Мы обозначаем it как местоимение (задавая ему некое значание из выражения например) и можем использовать его в теле. В других языках это вообще нет. Но это только пример.

CP>>

CP>>(awhen (compr x y)
CP>>   (blah it))
CP>>

CP>>раскрывается в

CP>>

CP>>(let (it (compr x y))
CP>>  (when it
CP>>   (blah it))
CP>>

VD>Не въехал, а что тут необычного?

На немерле такого не сделаешь. Гигиеничность макр не позволяет.

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

EXO>>Ну и? Тебе кто-то предлагал писать движок игры на erlang-е?
EXO>>Не передергивай — небыло таких предложений.

G>Кстати, были такие проекты :))). Движок сервера RPG, и движок игровой трехмерной графики (через OpenGL). Можно поискать в гугле. Но эрланговское сообщество относится к подобным экспериментам (трехмерная графика) скорее как к экстравагантным трюкам.

Мне тут посоветовали в качестве самообучения написать движок MUD-a на erlange. Кстати может ещё тут кто что посоветует написать на эрланге в 3-4 KLOC для самообучения?

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

R>> Имеет интерепретатор?

VD>Да — http://nemerle.org/Nemerlish. Но не вижу в этом смысла.

Смысл ООЧЕНЬ большой — REPL тестирование. Без него уже часто процесс разработки становиться мукой.

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

VD> 100%-ная поддержка ООП, ФП, ПП, МП. Осталось только пролог в них включить. :)

А в лиспе и пролог встроенный есть:)) (В коммерческих out-of-box)

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

A>1) Какое отношение Эриксон имеет к Эрлангу ?

Жжошь!!!

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

CP>Это как так не обратишься? Весь коммон лисп доступен внутри определения макроса.

Можно пример того как обратиться именно к подсистеме семантического анализа из макроса? Ну, хотя бы как узнать фактический тип парамерта?

CP>Проверить тип соответсвующей функцией.

CP>

CP>(defmacro a (x)
CP>  (if (atom x)
CP>       `(...)
CP>      (error "blah")))
CP>

И где здесь проверка типа? Причем тут атом не атом? Это операция над АСТ. А я говорю об операции над АСТ аннотированном типами. Наример, твоей атом может быть числом. Или х может быть функцией возвращающей целое. Как это проверить? Я думаю, что это не возможно хотя бы потому, что язык не обязывает указывать типы и функция до применения вообще не знает что ей прийдет в качестве параметра. Тут мог бы помочь вывод типов. Например, если параметр функции испльзуют как функцию и результат складывают с целым, то можно сделать предположение о том, что х — это функция "() -> int". Но ты сам сказал, что вывод типов не поддерживается.

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

Как я понимаю Лиспу это в принципе не грозит. Его макросы — это преобразование S-выражений. Для него программа — это данные, т.е. AST без аннотации типов.

VD>>Как видишь, особых проблем нет. Более того получается в сто раз понятнее. Причем без специальной дрисеровки пользователя.

CP>Мне понятнее в лиспе

Рад за тебя. Вернее за вас... за всех... пятерых.

CP>Дело привычки. Расширить язык это одно. Но более важная задача макросов — эффективные высокие абстракции. А вот здесь манипуляция с кодом может быть намного сложнее.

На фиг такие привычки. Наа фиг!

Я не хочу привыкать бриться топором даже если очень универсально. И не хочу привыкать спать в холодной комнате даже если это сэкономит мне 50 баксов в месяц. Я предпочитаю вычислять выражения так как это делал в школе, а не в польской натации. Я не хочу видать море скобок. Я не хочу представлять себе структуры данных в голове. Я хочу видеть эти стркутуры описанными и иметь у них осязаемые поля. В общем, я не хочу убогсти. Я хочу удобства. А Лисп это убогость приносящая удобство в жертву универсальности.

VD>>Что означает "анофорических"?

CP>Типа местоимение. Мы обозначаем it как местоимение (задавая ему некое значание из выражения например) и можем использовать его в теле. В других языках это вообще нет.

Хм. Ты уверен, что нет? И уверен, что если нет, то оно нужно?
Например Рбивские и Смолтоковские декларации параметров для анонимных блоков — это не одно и то же? Например:

list.each { x | x * c }

И какая разница тут с разными def-ами или let-ами?

CP> Но это только пример.

А зачем оно?

CP>>>

CP>>>(awhen (compr x y)
CP>>>   (blah it))
CP>>>

CP>>>раскрывается в

CP>>>

CP>>>(let (it (compr x y))
CP>>>  (when it
CP>>>   (blah it))
CP>>>

VD>>Не въехал, а что тут необычного?

CP>На немерле такого не сделаешь. Гигиеничность макр не позволяет.

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

Что это дает? Какие задачи позволяет решать?

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CP>Смысл ООЧЕНЬ большой — REPL тестирование. Без него уже часто процесс разработки становиться мукой.

Ты меня конечно извени, но ты IDE порядошную видел? Нахрена мне мне вообще интерпретатор если я могу прямо во время выполнения программы править ее код? Или во время разработки протестировать функцию.

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

Погляди для разнообразия как можно работать в VS 2005 или в IDEA. Думаю, что когда въедешь во все возможности, то поймешь о чем я говорю.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CP>А в лиспе и пролог встроенный есть

(В коммерческих out-of-box)

Ага. Жаль только что сам он кхэ-кхэ... Ну, в общем ты понял.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CP>Жжошь!!!

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, VladD2, Вы писали:
VD>А, ну, да. Нам среда не нужна мы и так крутые. В таком случае и говорим перед рекламой, что так вот и так. Я фанат консоли и всего приметивного.

Опять передергиваешь.

Внимательно читая сообщения, мог бы заметить, что человек начинавший пограммировать с "интегрированных сред", 12 лет программировавший только в интегрированных средах (и из них лет 6 в MS VS) не может быть фанатом консоли.
А если уж склоняется к уходу в эту сторону, то видать имеет для этого весьма основательные причины.

( Отчасти ты напоминаешь мне меня самого, лет десять назад... )

VD>Смешно. Пересометрия в чистом виде. Иди сравни это БД-сервер с поставляемым в составе студии MS SQL Server 2005. Боюсь без полного отрешения от жизни серьезным такое сравнение назвать будет сложно.

Гм... сейчас как раз перевожу под мнезию один проект, который в первой версии был под MS SQL Server 2000.
Продукт пока в работе, но поскольку данные конвертнули из старой базы (то есть база заполнена) о поведении мнезии уже можно судить.
Во-первых, число таблиц сократилось примерно в 3 раза. За счет более гибких типов данных мнезии. Соответсвенно упростились многие алгоритмы.
Во-вторых, быстродействие увеличилось в среднем в 1,5 раза. И это при том, что мнезия сейчас работает не над BerkleyDB backend (это у нас резерв быстродействия на всякий случай).
Во-третьих, быстродействие наиболее критичных алгоритмов повысилось примерно в 2,5 раза. Правда, для этого они были переведены с языка запросов QLC на прямые вызовы мнезии, так что для сравнения СУБД их рассматривать не стоит.

В целом могу сказать, что я достаточно хорошо отношусь к MS SQL. Даже к 2000 (Могу поверить, что 2005 еще круче).
Кстати, доступ из erlang-а к MS SQL существует и достаточно удобен. Однако использование его не рассмаривается по коммерческим причинам (требуется выйти на низкую стоимость тиражной лицензии).

EXO>>- хорошо интегрирующийся с сервером приложений мощный web-сервер. С поддержкой полного комплекта средств для создания web-сервисов.

VD>Видимо у остальных языков интеграция плохая.

У .Net языков хорошая интеграция с IIS. Они тоже части одной платформы.
А вот у не-дотнетовских perl и python интеграция с IIS уже куда хуже. Уже одно то, что IIS не может связывать подгруженные интерпретаторы этих языков с логическим сеансом пользователя резко снижает качество интеграции.
Так что эта самая "интеграция" далего не одинакова для разных сочетаний язык Х веб-сервер.
Так вот, у ерланга и идущего с ним веб-сервера она на том же уровне, что и у .Net языков с IIS.

VD> В общем, песня старая. Жаль не доказанная и опровергаемая кучей реальных решений.

Микорософт умеет хорошо рекламировать свои средства разработки. Это умение за ними безусловно следует признать.
А потому проектов на .Net естественно больше. Но вот по моим наблюдениям, процент качественных среди них — заметно ниже.

VD>Да уж. Куда там таким вещам как метапрограммирование в Скале и Немерле,

Просто метапрограммирование — вне рассмотрения, оно и в базовом ерланге есть.
Интересна именно мощность средств лексера и парсера. А так же их "интллектуальность" (то есть на сколько они готовы брать стандартный BNF, без "доработки напильником").

VD> или построителям парсеров вроде АНТЛР или КокаР.

За "наводку" — спасибо. На досуге посмотрю подробнее.

EXO>>Так что мы имеем дело именно что с прикладной платформой, а вовсе не просто с "языком общего назначения".
VD>Я бы сказал больше. С платформой заточеной под конкретные задачи.

Можно сказать и так. Только круг задачь похоже даже шире, чем изначально задумывался Эриксончиками.
Что в него входит, а что нет — надо смотреть.

VD>Хм. Дотнет по мне так сильно универсальнее.

Это пока несколько спорный вопрос, поскольку круг задачь эланг-платформы быстро расширяется.
Скорее всего, эти круги будут накладываться лишь частично.
Возможно даже у .Net-а поширше будет. Ну и что? Хорошо, что есть из чего выбирать.

VD> Это именно что платформа.

Разумеется. Одна из. Пусть даже весьма распространенная.

EXO>>Предположим я здесь с тобой даже и согласился бы... ну и что?
EXO>>Собственно а что остается, если мы не будем обращать внимания на тесты? Толко реальные продукты.
VD>Да думать нужно своей головой. А тесты можно и самому сделать.

Именно.
А самый лучший тест — реальные продукты.

EXO>>Так что тогда мы возвращаемся к сообщениям gandalfgrey о разработанной им системе, которая пришла на смену C++ версии. И заказчикам, которые (на сколько мне известно) успешно покупают обновления.
VD>Он явно применял С++ там где не следовало.

На сколько я понял из его слов — C++ применял не он.
А что бы ты ему предложил? Перевести проект с C++ на .Net? На сколько я слышал, там часть узлов это микроPC на I486 с 64 Мб оператива, а часть моторолловские микрокомпы. Каково там будет .Net-у? Или ты предложил бы ему писать 2 (3) разных варианта одного и того же приложения?

Кстати — вот тебе сразу несовпадение нишь...
То, что я выше писал про коммерческую неприемлимость использования MS SQL — другое несовпадение...
Так что не стоит говорить, будто .Net такая уж универсальная, что закывает все пространство задачь.

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

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

Впрочем, если хочешь, можешь продолжать в том же духе.

VladD2 wrote:
> Если я все правильно понял, то на Нэмерле можно все тоже самое и намного
> болше. А главное роще, предсказуемее и удобнее.
В больше — позвольте не поверить, если пользоваться макросами в полную
мощность, то, вероятно столько же — макрос может делать любое вычислимое
преобразование. Предсказуемость зависит при этом от того, насколько в
этот момент ближе один язык, чем другой. Про удобнее поверю легко.

Posted via RSDN NNTP Server 2.0

VladD2 wrote:
> Здравствуйте, CrazyPit, Вы писали:
>
> CP>Смысл ООЧЕНЬ большой — REPL тестирование. Без него уже часто процесс
> разработки становиться мукой.
>
> Ты меня конечно извени, но ты IDE порядошную видел? Нахрена мне мне
> вообще интерпретатор если я могу прямо во время выполнения программы
> править ее код? Или во время разработки протестировать функцию.
>
Тогда IDE можно использовать как интерпретатор. Для тех языков, для
которых это поддерживается. И как REPL.
> В общем, ты привык к "псевдо Юникс-лайк" стилю. Он возник от убогости. И
> то что в его рамках кажется очень важным и необходимым, на самом деле,
> при некоторых условиях, на фиг не унжно.
>
> Погляди для разнообразия как можно работать в VS 2005 или в IDEA. Думаю,
> что когда въедешь во все возможности, то поймешь о чем я говорю.

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

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

Posted via RSDN NNTP Server 2.0

VladD2 wrote:
> Здравствуйте, raskin, Вы писали:
>
> R>Вопросы: Немерле отделим от дотнета?
>
> Приципиально — конечно. Язык есть язык. Лисп тоже под дотнетом чувствует
> себя отлично.
> Рельно — нет. Он под него создавался.
Жаль. Вот будет отделим... А то ставить dotGNU или Mono совсем неохота.
Хотя должен работать под Mono, можно посмотреть.
>
> R> Имеет интерепретатор?
>
> Да — http://nemerle.org/Nemerlish. Но не вижу в этом смысла.
"Пусть это сделают другие" — то, что я не собираюсь сохранять, пусть
компилируется без моих активных действий (кроме ввода этого).
>
> R> Позволяет
> R>использовать весь язык без ограничений в описаниях макросов?
>
> Они на нем и пишутся.
Без ограничений? Это радует, хотя и естественно.
>
> R>Хотелось бы нет-да-да. И поставить на наладонник вместо схемы..
>
> Почему бы и нет. Незнаю нафиг прада нужны средства разработки на КПК
А зачем он нужен, если на нём даже посчитать ничего нельзя? IDE мне не
нужна, интерпретатор хоть какой-нибудь. Без этой возможности
неинтересно. Но тогда ему CompactFramework нужен, если его (CFw) вообще
хватит. Интересно, не захочет ли он установленную консоль.. Судя по
сайту, если я этим займусь — все шишки мои.
>
> R> И бросить писать свою обёртку над Си с целью иметь синтаксис Паскаль,
> R>компилятор от Си и макросы от Лисп.
>
> Незнаю нафиг нужен синтаксис от Паскаля, но можешь попробывать.
В Паскаль все односимвольные опечатки не в именах переменных, которые я
когда-либо делал, мешают компиляции. В Си одну такую я искал очень
долго. Больше я на этом (надеюсь) так не попадусь, но осадок... Ну и
выглядит Паскаль на мой вкус лучше.

Posted via RSDN NNTP Server 2.0

Здравствуйте, VladD2, Вы писали:
VD>Ты не суди о том что не изучил. Ты обясни суть, и вместе разберемся можно ли, нельзя ли. И если нельзя, то чего мы лешаемся. Я пока что вижу гордость хнен знает чем.

VD>Что это дает? Какие задачи позволяет решать?

Код 
  myif(long_experssion)
     {
           do_something1(it);
           do_something2(it);
     }
преобразуется во что-то вроде
  {
        int it=long_expression;
        if(it!=0)
        {
           do_something1(it);
           do_something2(it);       
        }
  }
long_expression,do_somthing1,do_somthing2 - произвольные выражения.
Переменная it фиксирована.

Это можно кратко сформулировать — если что-то не 0 то сделай с ним (it)то-то и то-то....
Такое можно сделать?

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

VD>Ага. Жаль только что сам он кхэ-кхэ... Ну, в общем ты понял.

Интересно откуда такое отношение

Что-нибудь писал на Common Lisp?
Какие недостатки языка так задевают?

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

VD>И где здесь проверка типа? Причем тут атом не атом? Это операция над АСТ.

Атом это пример, можно проверить любой тип входного выражения.

VD>А я говорю об операции над АСТ аннотированном типами. Наример, твоей атом может быть числом.

(defmacro a (x)
  (if (typep x 'fixnum)
        ...)

Или ещё лучше:

(defmacro a (x)
 (check-type x fixnum)
 `(....))

VD> Или х может быть функцией возвращающей целое.
Ну да по без расширений никак.

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

Дык в лиспе тоже, только в компиляторе лиспа нету понятия тип функции.

VD>Как я понимаю Лиспу это в принципе не грозит. Его макросы — это преобразование S-выражений. Для него программа — это данные, т.е. AST без аннотации типов. Но он может проверить структуру этого T и типы отдельных вершин этого Т,

CP>>Дело привычки. Расширить язык это одно. Но более важная задача макросов — эффективные высокие абстракции. А вот здесь манипуляция с кодом может быть намного сложнее.

VD>На фиг такие привычки. Наа фиг! :)
VD>Я не хочу привыкать бриться топором даже если очень универсально. И не хочу привыкать спать в холодной комнате даже если это сэкономит мне 50 баксов в месяц. Я предпочитаю вычислять выражения так как это делал в школе, а не в польской натации. Я не хочу видать море скобок. Я не хочу представлять себе структуры данных в голове. Я хочу видеть эти стркутуры описанными и иметь у них осязаемые поля. В общем, я не хочу убогсти. Я хочу удобства. А Лисп это убогость приносящая удобство в жертву универсальности.

Как раз удобство очень большое. Оно в возможности создания произвольных абстракций. Не обязательнонужно привязывать себя к каким-то "низкоуровневым" понятиям типа "класс", "объект". Можно бытро создать свой язык для конкретной задачи и выражатьсы уже на нём. Вот пару примеров:

Задание правил лексического анализатора:

(def-matchers 
  (regex    (nil "\\s+" :ending ""))
  (simple   (:comparation ("==" "!="  ">=" "<=" "<" ">"))
            (:minus "-")
        (:plus "+")
        (:binary-operation-p-1 ("*" "/"))
        (:right-bracket ")")
        (:left-bracket "(")
        (:set "=")
        (:comma ",")
        (:dot ".")
        (:semicolon ";")
        (:end-block "}")
        (:begin-block "{"))
  (keyword  (:define "define")
        (:to "to")
        (:for "for")
        (:while "while")
        (:else "else")
        (:if "if")
        (:return "return")
        (:default "default")
        (:case "case")
        (:print "print")
        (:switch "switch"))
  (regex    (:integer-const "\\d+" :ending "\\b")
                (:identifier "[a-zA-Z]\\w*")))

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

VD>>>Что означает "анофорических"?

CP>>Типа местоимение. Мы обозначаем it как местоимение (задавая ему некое значание из выражения например) и можем использовать его в теле. В других языках это вообще нет.

VD>Хм. Ты уверен, что нет? И уверен, что если нет, то оно нужно?
VD>Например Рбивские и Смолтоковские декларации параметров для анонимных блоков — это не одно и то же? Например:
VD>

VD>list.each { x | x * c }
VD>

Не не то. В мы же здесь объявлям x внутри блока. А там it не объявляеться -> более выскокая абстракция.
Здесь http://gzip.rsdn.ru/Forum/Message.aspx?mid=1646876&only=1 товарищ raskin хорошо написал об этом.

VD>Ты не суди о том что не изучил. Ты обясни суть, и вместе разберемся можно ли, нельзя ли. И если нельзя, то чего мы лешаемся. Я пока что вижу гордость хнен знает чем.

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

VD>Что это дает? Какие задачи позволяет решать?

Строить более выскокие абстракции.

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

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

CP>>Смысл ООЧЕНЬ большой — REPL тестирование. Без него уже часто процесс разработки становиться мукой.

VD>Ты меня конечно извени, но ты IDE порядошную видел? Нахрена мне мне вообще интерпретатор если я могу прямо во время выполнения программы править ее код? Или во время разработки протестировать функцию.

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

VD> во время выполнения программы править ее код
в CL так разработка ведёться всегда.

VD>В общем, ты привык к "псевдо Юникс-лайк" стилю. Он возник от убогости. И то что в его рамках кажется очень важным и необходимым, на самом деле, при некоторых условиях, на фиг не унжно.

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

VD>Погляди для разнообразия как можно работать в VS 2005 или в IDEA. Думаю, что когда въедешь во все возможности, то поймешь о чем я говорю.

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

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

CP> Вот пару примеров:

забыл второй.

(defmodule-import photo "Фотопродукция"
  (:source "photo.txt" :main-category-id 19)
  (:category :if (and (non-free (column 1))
                       (non-free (column 2)))
         :level-map ((:compute (parse-integer (column 1))))
         :mapping ((:name 2)))
  (:goods :if (and (free (column  1))
                   (non-free (column 2))
                   (non-free (column 3)))
      :prep ((counter (make-counter)))
      :mapping ((:code (funcall counter))
                   (:name 2)
                   (:in-cost 3 :transform #'rus-cost)))))

DSL для описания импорта из текстового прайст в БД. по определённым правилам.

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

VD>Ага. Средняя температура по больнице всегда 36.6.

Именно так. Незачем ориентироваться на тормозов или гениев.

VD>Дык вот и хотелось бы увидить обоснование того, что реальная система на Шарпе (к примеру) не может быть усойчивой и надежной.
Запросто ! Пример хоть одной системы повышенной надежности, с временем простоя порядка единиц секунд в год

VD>А в чем выражается выразительность? Не уж то в минимализации количества закорючек на экране?
И в этом тоже. Производительност программера выражается в количестве строк в день, и слабо зависит от языка, на котором он ваяет продукт. Сие медицинский факт, подтвержденный многочисленной статистикой. Поэтому — чем выразительнее язык, тем более компактный код он позволяет создавать, и тем больше смысловых единиц ( не LOC ) получается в единицу времени

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

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

VD>>И где здесь проверка типа? Причем тут атом не атом? Это операция над АСТ.

CP>Атом это пример, можно проверить любой тип входного выражения.

Нет речь о том чтобы проверять тип аргумента макроса. Не куска кода ( это конечно же будет список или символ )a какому типу этот кусок кода будет соответствовать в лексическом окружение в котором вызван макрос.
Другими словами как по объекту &environment и коду — определить тип

  (typep* '(+ 1 2)) => fixnum

  (let ((x))
     (declare (type fixnum x))
     (typep* 'x)) => fixnum

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

VD>Кто такой Тикль?
это TCL, скриптовый такой язык, лишенный даже намека на синтаксис

VD>Полезной? Не сказал бы. Но мы говорим о скорости. Общая производительность в конце концов завист от той что ты называшь "сырой".
Очень слабо зависит. Есть гораздо более весомые факторы

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

А где это такой язык ? Пальцем, пожалуйста, покажите ! То, что это не Сшарп и не Ява, понятно...

VD>"Нежалуюсь" это не предсказание. Это просто твои задачи не стольк требовательны к процессору. Или пакетные и тебе пофигу сколько они выполняются.
Вообще-то мягкий реалтайм в большинстве случаев

VD>И int, и обработку объектов, и вообще все. Но для этого пришлось бы всерьез задуматься над тем о чем я говорю — о декларации типов и о выводе типов. И самое смешное, что такие языки есть. Кроме скорости они еще обеспечивают большую однозначсть, что дает выигрышь и в других местах.
У них другого не хватает, к сожалению

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

CP>Мне тут посоветовали в качестве самообучения написать движок MUD-a на erlange. Кстати может ещё тут кто что посоветует написать на эрланге в 3-4 KLOC для самообучения?
Хорошей идеей было бы написать компилятор маленького скриптового языка. Или биндинг к какому-нибудь симпатичному гую. Для GTK+, wxwindows и TCL уже есть...

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

VD>Из чего можно сделать вывод, что VC похож тоже избавляется от концевой рекурсии. Ну, и что скорость дотнетного кода очень близка к скорость порождаемой C++-ными компиляторами.

VC может еще лучше оптимизировать, достаточно добавить строчку #pragma inline_recursion(on) и у меня вместо 0.703000 становится 0.343000

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

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

CP>>Мне тут посоветовали в качестве самообучения написать движок MUD-a на erlange. Кстати может ещё тут кто что посоветует написать на эрланге в 3-4 KLOC для самообучения?
G>Хорошей идеей было бы написать компилятор маленького скриптового языка. Или биндинг к какому-нибудь симпатичному гую. Для GTK+, wxwindows и TCL уже есть...

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

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

CP>В этих задачах сложно раскрыть главное приемущество эрланга. Хотелось бы написать какую-нибудь распределённую систему.
Тогда действительно — распределенную игрищу. Можно даже шашки на 8-угольной доске.
Можно и рисовалку сетевую. Но это очень уж просто, конечно.

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

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

F1=fun()->3 end.
F2=fun()->5 end.
F3=fun(X,Y,Op)->Op(X(),Y()) end.
Val=F3(F1,F2,{erlang,'+'}).
> 8

Это все можно делать в динамике. Весь исходный код компилится в одну толстую лямбду, которая, собственно, и есть полученный выполнимый код. Ее можно положить в файл...

A>Я, скажем вежливо, не спец в C++, я его синтаксис очень ен люблю.
A>Но именно в битовых полях, как мне показалось, Эрланг и плюсы одинаковы.
A>Т.е. я возражаю против фразы "нет равных в описании бинарных данных "

Битовые поля без pattern matching не дают особых преимуществ в реализации протоколов.
Потенциальный конкурент тут скорее NJ Matchine-code Toolkit. По описанию бинарной структуры он генерит препроцессор для C, который реализует pattern matching. Но, на сколько мне известно, его в этой области ни кто не пробовал применять...

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

CP>>>Дело привычки. Расширить язык это одно. Но более важная задача макросов — эффективные высокие абстракции. А вот здесь манипуляция с кодом может быть намного сложнее.

Все так. И Nemerle позволяет производить очень сложные манипуляции с кодом. При этом сам код которым пытается манипулировать Nemerle на порядок сложнее s-expressions Лиспа, так как есть там и синтаксис, и типы, и классы, и вся специфика .NET(например атрибуты).

CP>Как раз удобство очень большое. Оно в возможности создания произвольных абстракций. Не обязательнонужно привязывать себя к каким-то "низкоуровневым" понятиям типа "класс", "объект". Можно бытро создать свой язык для конкретной задачи и выражатьсы уже на нём.

Nemerle эти концепции совмещает. Он оперирует всеми "уровнями". Он позволяет создавать языки для конкретной задачи и он включает уже готовый набор понятий, который можно надстраивать. К тому же эти "низкоуровневые" понятия в Nemerle не совсем "низкоуровневые". Реализован ряд концепций из современных ФЯ — полноценные функции(и все что из этого вытекает), алгебраические типы, паттерн-мэтчинг, кортежи, автоматическое выведение типов(afaik без ряда ограничений свойственных современным ФЯ), при этом полностью поддерживается среда и объектная модель .NET 2.0 включая дженерики(imho с более человеческим синтаксисом и что важно выведением типов).

Nemerle в каком-то смысле мультипарадигмальный язык(не в том же смысле что и C++

). В частности он позволяет писать в чисто функциональном стиле(при особом желании конечно

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

CP>Задание правил лексического анализатора:

CP>

CP>(def-matchers
CP> ... code skipped ...
CP> )
CP>

Ну если бы я что-то подобное писал на Nemerle, то это могло бы выглядеть например так:

[BuildScanner
([
  nil = regex("\\s+", ending = ""),
  comp_ops = ["==", "!=", ">=", "<=", "<", ">"],
  plus = "+",
  minus = "-",
  binary_ops_p1 = ["*", "-"],
  left_bracket = "(",
  right_bracket = ")",
  assign = "=",
  comma = ",",
  dot = ".",
  semicolon = ";",
  begin-block = "{",
  end-block = "}",
  keyword("define","to","for","while","else","if","return","default","case","print","switch"),
  integer_const = regex("\\d+", ending = "\\b"),
  identifier = regex("[a-zA-Z]\\w*")
])]
class Scanner
{
// код будет сгенерирован макросом BuildScan
}

// использование
module Main
{
   public Main() : void
   {
       def scanner = Scanner(StringReader("test 123"));
       def tokenList = scanner.ScanToEnd();
       // примерно такие структуры данных могут быть сгенерированны внутри класса Scanner
       // в данном случае Scanner.Token это variant(немерловский аналог алгебраических типов)
       assert(tokenList matches [Scanner.Token.identifier("test"), Scanner.Token.integer_const(123)]);
   }
}

CP>Пользуясь языком без такой системы макропрограммирования, пришлось бы писать описание например на XML, а потом писать обработчик. Здесь же этот код во время компиляции преобразуеться в функции функции лексического анализа.

Абсолютно то же самое можно сделать и на Nemerle. Даже больше — подключить кусочек существующего генератора лексических и/или синтаксических анализаторов к макросу плевое дело(например Coco/R, можно даже не конвертировать его в Nemerle, просто видоизменить и подключить как внешнюю библиотеку). Вплоть до возможности вызова внешней программы(но это уже изврат и должно быть/может быть запрещенно через Code Access Security).

CP>>>Типа местоимение. Мы обозначаем it как местоимение (задавая ему некое значание из выражения например) и можем использовать его в теле. В других языках это вообще нет.

Если я правильно понял, то в Nemerle это можно сделать, если сильно нужно.

Я делал. Не скрою — это сложнее, чем в Lisp, по крайней мере далеко не так кратко. Но особой необходимости в таких трюках в Nemerle не существует, все таки специфика языка совсем иная, есть например другие возможности сделать примерно то же самое и проще(например можно модифицировать класс, гигиена на top-level объявления вроде не действует), все зависит от задачи. Imho негигиеничные макросы как в Лисп это не всегда хорошо. Не зря же появился Scheme.

VD>>Ты не суди о том что не изучил. Ты обясни суть, и вместе разберемся можно ли, нельзя ли. И если нельзя, то чего мы лешаемся. Я пока что вижу гордость хнен знает чем.

CP>Там гигиенические макры, я почитал. Так что нельзя как угодно код преобразовать. Т.е. например чтобы символ введёный в теле макра, не может быть внутри кода переданного в макр.

"Там" очень гибкая макро-система. "Гигиена" легко ломается штатными механизмами. Кроме того макросы в Nemerle работают не только с выражениями как в Lisp и практически всесильны, так как имеют доступ ко всему API компилятора и .NET Framework. Большая часть базовых конструкций и операторов языка реализованна макросами, например такие как if else, for, while, using, foreach. Макросы повторюсь можно использовать не только над выражениями, но и над определениями классов(через расширение грамматики или как аттрибут), членов класса, модулей, пространств имен. Кроме того макросы могут работать с полуразобранным(иерархия различных скобок кажется строится) потоком лексем, таким образом позволяя внедрять конструкции с практически произвольным синтаксисом(более произвольным чем это можно сделать в лиспе).

Скажем xml(пример из набора тестов компилятора):

// использование
foo () : void {
  // никаких кавычек
  def doc = xml (<node name="foo">My name is foo</node>);
  // macro produced some XmlNode for us, we can use it
  print (doc.InnerXml); 
}

// сам макрос, очень примитивная реализация, просто чтобы был полностью рабочий пример
// реальная реализация будет естественно гораздо сложнее, но скажем валидацию в compile-time добавить элементарно
macro tokenizer (tok : Token) 
syntax ("xml", tok) 
{
  def buf = Text.StringBuilder ();
  foreach (t in tok)
    ignore (buf.Append (t.ToString ()));
  // будет сгенерирован следующий код
  // так как макросы гигиенические document и frag не попадут в текущее пространство имен
  <[ 
     def document = XmlDocument ();
     def frag = document.CreateDocumentFragment ();
     frag.InnerXml = $(buf.ToString () : string);
     _ = document.AppendChild (frag);
     document
  ]>
}

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

On Tue, 31 Jan 2006 16:42:11 +0300, CrazyPit <43603@users.rsdn.ru> wrote:

> В этих задачах сложно раскрыть главное приемущество эрланга. Хотелось бы
> написать какую-нибудь
> распределённую систему.

DDos gotdotnet.com ? :D

--
Отправлено M2, революционной почтовой программой Opera:
http://www.opera.com/mail/

Posted via RSDN NNTP Server 2.0

On Tue, 31 Jan 2006 11:48:44 +0300, raskin <40778@users.rsdn.ru> wrote:

> интерпретатор хоть какой-нибудь. Без этой возможности
> неинтересно. Но тогда ему CompactFramework нужен, если его (CFw) вообще
> хватит

....а вот тут м.б. как раз и попробовтаь dotGNU ?
Хотя верю, что интерпретатор, на КПК, да еще под dotGNU будет ползать.

--
Отправлено M2, революционной почтовой программой Opera:
http://www.opera.com/mail/

Posted via RSDN NNTP Server 2.0

On Tue, 31 Jan 2006 01:01:14 +0300, VladD2 <73@users.rsdn.ru> wrote:
> A>1) Какое отношение Эриксон имеет к Эрлангу ?
> Мне казалось, что одuн создал другого.

Cоздал.
Какое имеет сейчас ?

> A>3) Просто ради интереса, сколько человек работает в MS Research ?
> на зарплаты сотрудников работающих над исследовательскими проектами.

И сколько таких сотрудников примерно ?

И действительно, подключены институты. Думаю разница огромная, по сравнению
с тем, что было в Ericsson CSLabs

> Здравствуйте, Arioch, Вы писали:
>
> A>Да, надо будет почитать, что же за компилятор, и почему он не JIT

>
> Кодовое название компилятора Барток. Родился во времена ранней Явы как
> проект компилятора Ява в исполняемое приложение виндовс.
>
> A>Ты же не овзмущаешься, что в Эрланге нет своего TCP-стека, например?
>
> Вообще-то если мы говорим о процессах, то подразумеваем ОС. А если
> подразумеваем ОС, то логично было бы ожидать и TCP-стека. В Сингулярити
> TCP-стек написан как раз на C#. Кстати, говорят по скорости рвет аналог
> из Винды и Линукса.

>
> A>1) Какое отношение Эриксон имеет к Эрлангу ?
>
> Мне казалось, что одни создал другого.

>
> A>2) В другом профиле. Сравнивать Эриксон и МС в части софтостроения...
> A>Примерно так же как в части создания АТС и раутеров, только с обратным
> A>знаком

Не считаю я МС крупной фирмой ф области network hardware,
> хотя
> A>вообще, в вакууме — крупная, не возразишь. И наверное могла бы лечь
> A>костьми и потеснить Эрикссон. Но только это, вежливо скажем, не
> A>рационально.
>
> Хм. Это не мои слова.

>
> A>3) Просто ради интереса, сколько человек работает в MS Research ?
>
> MS Research — это не контора. Это проект МС в который МС вбухивает бабки
> которые идут на гранты разным институтам и на зарплаты сотрудников
> работающих над исследовательскими проектами. Так что говорить тут можно
> толко о количестве проектов (которое извесно) и количестве вбуханых
> денег.

--
Отправлено M2, революционной почтовой программой Opera:
http://www.opera.com/mail/

Posted via RSDN NNTP Server 2.0

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

_>Это можно кратко сформулировать — если что-то не 0 то сделай с ним (it)то-то и то-то....
_>Такое можно сделать?

По крайней мере не вижу никаких причин не позволяющих это сделать. В прочем как и объяснения зачем это нужно.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

...

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

ЗЫ

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

В VS 2005 есть такая настройка "Не сохранять проект". Новый проект создается как бы в воздухе и если ты попыташся создать новый или закрыть IDE тебе предложат записать его или потерять изменения. Я этим делом постоянно пользуюсь. Веверн, что создать мелкий тест у меня получится как иминимум не медленее чем у любого любителя консольных интерпретаторов.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Хм. Может все же прще глянуть на то о чем речь идет? В студии почти как ты говоришь и сделано. Есть специальное окно "Immediate". Вводишь в него строку, жмешь Ввод и получашь результат. Консоль чистой воды. Только переключаться никуда не надо. Окно можно закрепить где удобно.

И с тестами так же. Юнит-тесты встроены в среду. Выделяшь нужные и жмешь кнопку. Только я не любитель ни юнит-тестов, ни запуска по доной функции. Мне проще точку основа влепить и F5 нажать.

Просто когда есть выбор, то выбирашь то что действительно удобно, а не то что есть.

VD>> во время выполнения программы править ее код
CP>в CL так разработка ведёться всегда.

Есть все же некоторая разница между Лиспом и языками с синтаксисом. К тому же попробуй "так" отлаживать нечто требовательное к производительности. При отладке дотнетного прилоежения замедление получается раза в 2-6 по сравненю с релизом без отладчика. А вот интерпретация да еще и интерактивная — это от 10 и выше. Не все так можно отлаживать.

CP>Ты прав я привык к юникс стилю разработки и нахожу его весьма удобным.

Тогда остается просто поверить на слово, что почти все что у него было лучшего взято в современные интерактивные среды. Разница очень небольшая, но она есть. В этих средах кроме описанного есть еще куча всего и все это интегрированно. Ну, и по консолям шариться не нужно. А если охота, то тоже не проблема. Открой 5 консолей и любуйся. Комплит в них тоже есть. Если нужен особо извращенный, тоже надыбать можно.

CP>VS05 и IDEA не видел. Возможно они чем-то радикально отличаються от других подобных IDE, но другие меня как-то не впечатлили.

Хорошее слово "радикально". Именно что.. Другие и меня не впечатляют. Хотя, думаю, имея некоторые привячки и к VS 2005 с решарпером прийдется привыкать.

Кстати VS 2005 неплоха и без решарпера, но с решарпером она будте вообще улет. Ну, а то о чем я говорю можно поглядеть здесь:
http://www.jetbrains.com/idea/features/newfeatures.html
http://www.jetbrains.com/resharper/
http://rsdn.ru/article/devtools/newinwhitbey.xml (и это еще только о бэтах)
http://rsdn.ru/article/devtools/newinwhitbey2.xml

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

R>Жаль. Вот будет отделим... А то ставить dotGNU или Mono совсем неохота.

А качать какие-нить 100 метров ЦигВина это нормально? Да и что там ставить то? Он ставится за пять минут без единого вопроса. А скоро дотнет будет на любой винде.

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

Для этого созданы IDE. Нажал "Создать проект", выбрал тип, написал что надо, нажал F5. Лишних действий == 0.

R>А зачем он нужен, если на нём даже посчитать ничего нельзя?

Почему нельзя? Но писать код на КПК — формернное издевательство. Уж лучше написать и скинуть на КПК. Мы тут были недавно на Кубе и у нас погорел крадридер. Но был КПК который читает КомпактФлэш и может писать на SD. Вот только одна беда, софтина идущая в поставке с ВыньЦЕ так тормозила, что была практически не пригодна для использования. Ну, и что? Сели и за 10 минут написали утилитку на С№ 2.0. Даже с ГУИ повыпендирвались.

Никаких особых проблем.

R> IDE мне не
R>нужна, интерпретатор хоть какой-нибудь. Без этой возможности
R>неинтересно.

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

R> Но тогда ему CompactFramework нужен, если его (CFw) вообще
R>хватит. Интересно, не захочет ли он установленную консоль.. Судя по
R>сайту, если я этим займусь — все шишки мои.

Думаю захочет. Я вообще не понял почему в ВыньЦЕ ее по умолчанию не ставят.

R>В Паскаль все односимвольные опечатки не в именах переменных, которые я
R>когда-либо делал, мешают компиляции.

Хм. Паскаль тут не причем. Просто Паскаль — это один из типобзопасных языков.

R> В Си одну такую я искал очень
R>долго.

Потому как С не типобезопасный. Уверяю тебя, что синтаксис тут не причем. Ты точно так же не будешь часами искать ошибки ни в C#, ни в Нэмерле, потому как это еще более строгие языки чем Паскаль. И в отличии от него поддеживающие кучу парадигм. В общем, не хлам доисторический, а современные языки.

R> Больше я на этом (надеюсь) так не попадусь, но осадок... Ну и
R>выглядит Паскаль на мой вкус лучше.

Незнаю. По мне так это любовь к рющечкам. Сила языка не в том как у него выглядят коснтрукции блока или отделяются операторы. Кстати, во многих ФЯ вообще нет ни блоков, ни операторов (в смысле statmonts).

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

_>Интересно откуда такое отношение

_>Что-нибудь писал на Common Lisp?

Хывтмло его изучать и писать примеры. Больше не тянет.

_>Какие недостатки языка так задевают?

Хреновая читабельность. Птичий язык.

... << RSDN@Home 1.2.0 alpha rev. 637>>

Не оверквоть, плиз.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

FR>VC может еще лучше оптимизировать, достаточно добавить строчку #pragma inline_recursion(on) и у меня вместо 0.703000 становится 0.343000

Это уже гонки оптимизаций конкретных компиляторов. К языкам это отношения не имеет. Я о другом говорил.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>Дык вот и хотелось бы увидить обоснование того, что реальная система на Шарпе (к примеру) не может быть усойчивой и надежной.
G>Запросто ! Пример хоть одной системы повышенной надежности, с временем простоя порядка единиц секунд в год

Ща я тебе ее при тебе же и напишу:

using System;
using System.Threading;

class Program
{
    static void Main()
    {
        while (true)
        {
            Console.WriteLine("На " + DateTime.Now + " я еще была жива.");
            Thread.Sleep(2000);
        }
    }
}

Запусти на хорошем компе с UPS-ом и обещаю тебе, что через год все будет ОК.

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

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

VD>>А в чем выражается выразительность? Не уж то в минимализации количества закорючек на экране?
G>И в этом тоже.

Тогдя я знаю идеальных язык. Это Брэйнфак. У него самый минимальный язык. И говорят, что на нем можно написать все что угодно.

G> Производительност программера выражается в количестве строк в день,

Эту сказку я слышал не раз. Вот толко не часто видишь людей которые могли бы надолбить хотя бы сколько я. А я далеко не уникум.

G> и слабо зависит от языка,

Ага. И от среды тоже? Это сказки.

G> на котором он ваяет продукт. Сие медицинский факт,

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

ЯП такой же язык как и другие. Например, русский. Достаточно зайти в наш топ:
http://rsdn.ru/Forum/Topa.aspx
Чтобы понять, что люди разные. И если один может между делом нафигачить 20 постов среди кторых окажется 3 интересных, то другой напишет одно в два дня и то интересным оно будет вряд ли.

Та же фигня и в программировании. Один думает быстрее и долбит десятью-пальцевым методом. А другой только из института и бездумно жмет кнопки одним пальцем.
Оди использует соверменную IDE со средствами рефакторинга, а другой половину рабочего времени убивает на переключение между конослями.

G> подтвержденный многочисленной статистикой.

Скорее они подтверждают старую хохму, что есть маленька лож, есть большая, а есть статистики.

G> Поэтому — чем выразительнее язык, тем более компактный код он позволяет создавать, и тем больше смысловых единиц ( не LOC ) получается в единицу времени

Понимаш ли. Компактность понятие очень обманчивое. Код может быть кратким, но не информативным. Вот Эрлэнг, Хаскель и Лисп лично мне очень тяжело читать. Очень многое седит на соглашениях, неявных предполжениях и т.п. Если сравнить код то может оказаться, что в более пушистом записано в общем-то столько же. Но вот только записано это дело более подробно. Ну, там переменные имеют смысл, а не любимые в сообществе фэнов ФЯ h, a, b, g, f... Фнукии названы так чтобы это было понятно, а не чтобы было кртако. Операторы более традиционны и понятны, а не представляющие из себя криптографию.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>Кто такой Тикль?
G>это TCL, скриптовый такой язык, лишенный даже намека на синтаксис

Я просто не слышал никогда его произношения.

VD>>Полезной? Не сказал бы. Но мы говорим о скорости. Общая производительность в конце концов завист от той что ты называшь "сырой".
G>Очень слабо зависит. Есть гораздо более весомые факторы

Напрямую зависит. Это слагаемое. Если оно маленькое, то и сумма будет соотвествующая.
Между современными языками (если не брать разные С/С++) не такая уж огромная разница. А вот в скорости она очень даже.

G>А где это такой язык ? Пальцем, пожалуйста, покажите ! То, что это не Сшарп и не Ява, понятно...

Хм, а почему это тебе понятно? Я вот беру одинаковый код и вижу что С++-ный компилятор порождает приблизительно аналогичный. А уровень у этих языков куда как выше. Есть еще D. Но у него тоже есть кое какие проблемы С++.

Для фэнов ФЯ есть ОКамл (и другие клоны МЛ), Нэмерл... Да куча языков.

VD>>"Нежалуюсь" это не предсказание. Это просто твои задачи не стольк требовательны к процессору. Или пакетные и тебе пофигу сколько они выполняются.
G>Вообще-то мягкий реалтайм в большинстве случаев

Классный критерий. То есть так как на С++ пишут и жесткий (т.е. реальный) реалтайм, то на нем стало быть все еще предсказуемее. Но ты то говоришь об обратном. Нестыковочка.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

EXO>Опять передергиваешь.

Нисколько.

EXO>Внимательно читая сообщения, мог бы заметить, что человек начинавший пограммировать с "интегрированных сред", 12 лет программировавший только в интегрированных средах (и из них лет 6 в MS VS) не может быть фанатом консоли.

Это не те среды. Таких сред и под Линуксом пруд пруди.

назвать будет сложно.

EXO>Гм... сейчас как раз перевожу под мнезию один проект, который в первой версии был под MS SQL Server 2000.
EXO>Продукт пока в работе, но поскольку данные конвертнули из старой базы (то есть база заполнена) о поведении мнезии уже можно судить.
EXO>Во-первых, число таблиц сократилось примерно в 3 раза. За счет более гибких типов данных мнезии. Соответсвенно упростились многие алгоритмы.
EXO>Во-вторых, быстродействие увеличилось в среднем в 1,5 раза. И это при том, что мнезия сейчас работает не над BerkleyDB backend (это у нас резерв быстродействия на всякий случай).
EXO>Во-третьих, быстродействие наиболее критичных алгоритмов повысилось примерно в 2,5 раза. Правда, для этого они были переведены с языка запросов QLC на прямые вызовы мнезии, так что для сравнения СУБД их рассматривать не стоит.

Ну, ну. Я лучше бы послушал ваших потребителей поработавших на той системе, а потом на новой.

EXO>У .Net языков хорошая интеграция с IIS. Они тоже части одной платформы.
EXO>А вот у не-дотнетовских perl и python интеграция с IIS уже куда хуже. Уже одно то, что IIS не может связывать подгруженные интерпретаторы этих языков с логическим сеансом пользователя резко снижает качество интеграции.

Вообще-то нет никаких проблем. Есть реализации и Перла (чур меня), и Питона на дотнете. Так что подключай и пользуйся. Кстати, есть даже куда более приятная вещь есть Boo — это такой забавный типизированный, компилируемый клон Питона.

EXO>Так что эта самая "интеграция" далего не одинакова для разных сочетаний язык Х веб-сервер.
EXO>Так вот, у ерланга и идущего с ним веб-сервера она на том же уровне, что и у .Net языков с IIS.

Хм. Апач и ИИС накрывают почти весь рынок. Для них есть или дотнет- или Ява-машина. А под них есть любые языки.

EXO>Микорософт умеет хорошо рекламировать свои средства разработки. Это умение за ними безусловно следует признать.

Майкрософт прежде всего умеет делать ПО. И несоменно умеет его продвигать. Они, Сан и IBM действительно лидеры индустрии ПО. И не надо все сводить к рекламе. В конце концов Линукс в первую очередь результат рекламы. Не даром IBM в него столько денег вбухал.

EXO>А потому проектов на .Net естественно больше. Но вот по моим наблюдениям, процент качественных среди них — заметно ниже.

Ну, а Ява-проектов почему так много? Зайди н Сорсфодж и гянь кто там лидер. Тот самый гадкий утенок — Ява.

EXO>Интересна именно мощность средств лексера и парсера. А так же их "интллектуальность" (то есть на сколько они готовы брать стандартный BNF, без "доработки напильником").

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

VD>> или построителям парсеров вроде АНТЛР или КокаР.

EXO>За "наводку" — спасибо. На досуге посмотрю подробнее.

http://www.antlr.org, Коку можно взять из R#-а на нашем сайте.
Особо забавно глянут на будущее — ANTLR v3 и его IDE. Это все пока глючит, но уже сейчас видно, что будет очень некислое средство.

EXO>Именно.
EXO>А самый лучший тест — реальные продукты.

К сожалению сравнивать реальные продукты очень не просто.

EXO>На сколько я понял из его слов — C++ применял не он.

Темболее. Тогда это может еще к тому же быть просто злословием так принятом у программистов "Вот уроды?! Кто ж так строит?!!!". Или иными словами в продукте найден фатальный недостаток — его писали не они (с).

EXO>А что бы ты ему предложил? Перевести проект с C++ на .Net? На сколько я слышал, там часть узлов это микроPC на I486 с 64 Мб оператива, а часть моторолловские микрокомпы. Каково там будет .Net-у? Или ты предложил бы ему писать 2 (3) разных варианта одного и того же приложения?

А, ну, да. Самому то не смешно? Значит на компилируемый дотнет перевести нельзя. Памяти мало и процессор дохлый. А на интерпретируемый Эрлэнг без вопросов. Класс!

EXO>Кстати — вот тебе сразу несовпадение нишь...

Не надо про ниши. Уверен, что на этом форуме собрались не какие-то работники эксзотического фронта. Бльшинство из них сидит под Виндой, или на худой конец под Линкус. И помпьюетры у них и их заказчиво без проблем тянут и дотнет, и Яву.

EXO>То, что я выше писал про коммерческую неприемлимость использования MS SQL — другое несовпадение...

Хм. А ты вкурсе, что у МС Сиквела есть безсплатный вариант единственным ограниченимем которго по большому счету является ограничение в 4 гига на БД?

EXO>Так что не стоит говорить, будто .Net такая уж универсальная, что закывает все пространство задачь.

Довольно универсальная. Если она не тянет, то есть еще Ява. Я предпочитаю дотнет, но понимаю, что тут скорее разговор о вкусах.

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

EXO>И что тебя все так тянет переходить на личности? Привык общаться с неуравновешенными субьектами?

Да где же ты личностей увидил. Ну, так чуть экспресси.

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

EXO>Мог бы уже заметить, что я просто использую твою агрессивность, как повод, чтобы рассказать людям про erlang...

Да, я только за рассказы! Я даже за показы и тесты. Я только против розовых соплей в стиле "Гудд... Бхрроун!!! Корочо!!!". Плавли, знаем. На любого брауна всегда свой Панасоник найдется.

EXO>Впрочем, если хочешь, можешь продолжать в том же духе.

Почему бы и нет. Но чеснослово лучше бы показали эту самую прелесть эрланга, чем рассказывать о ней. А то вот когда мне показали макросы Лиспа я их смог оценить. Хотя сам Лисп для меня ценности не представляет. Думаю, что и хорошие стороны эрлэнга я бы с удовольстивием оценил. Программировать я на нем вряд ли стану. Но для общего развития не помешает.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

>> Если я все правильно понял, то на Нэмерле можно все тоже самое и намного
>> болше. А главное роще, предсказуемее и удобнее.
R>В больше — позвольте не поверить,

Больше потому что уровень интеграции другой. В Лиспе макросы — это препроцессор. А в Нэмерле — это плагины к компилятору.

Вот здесь товарищь описал это дело лучше чем я Re[20]: преимущества erlang-а?.

R> если пользоваться макросами в полную
R>мощность, то, вероятно столько же — макрос может делать любое вычислимое
R>преобразование.

Дык в том, то все и дело, что в Нэмерле макрос может делать не только преобразования. Он еще может взаимодействовать с компилятором и использовать внешний, библиотечный код.

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

Здравствуйте, VladD2, Вы писали:
VD>Это не те среды. Таких сред и под Линуксом пруд пруди.

То есть хороших сред только две?

Странно... и почему это я не заметил скачка производительности у знакомых программистов,
когда они перешли от VS6 к VS2005?

VD>Ну, ну. Я лучше бы послушал ваших потребителей поработавших на той системе, а потом на новой.

Мне тоже это будет интересно.

Обязательно послушаю.

VD>Вообще-то нет никаких проблем. Есть реализации и Перла (чур меня), и Питона на дотнете. Так что подключай и пользуйся. Кстати, есть даже куда более приятная вещь есть Boo — это такой забавный типизированный, компилируемый клон Питона.

Ну дак это то о чем я и говорил: .Net (все языки) и IIS — одна платформа.
И Апач с явой — тоже в одну платформу интегрированы.

VD>Ну, а Ява-проектов почему так много? Зайди н Сорсфодж и гянь кто там лидер. Тот самый гадкий утенок — Ява.

Ты разве не помнишь начало "явизации"??? И участие в этом того же микрософта. Да и остальных...

EXO>>Интересна именно мощность средств лексера и парсера. А так же их "интллектуальность" (то есть на сколько они готовы брать стандартный BNF, без "доработки напильником").
VD>Ну, на мой взгляд макросы Лиспа отдыхают в сторонке и нервно курят. А если вспомнить, что это все дело в нехилом языке...

Макросы лиспа (так же как и констукции эрланга) — это сам язык. А речь была о парсерах и лексерах идущих в составе платформы. Это уже немного другое. (А .Net-овскую комплектацию посмотрю.)

VD>К сожалению сравнивать реальные продукты очень не просто.

К сожалению — так.

EXO>>А что бы ты ему предложил? Перевести проект с C++ на .Net? На сколько я слышал, там часть узлов это микроPC на I486 с 64 Мб оператива, а часть моторолловские микрокомпы. Каково там будет .Net-у? Или ты предложил бы ему писать 2 (3) разных варианта одного и того же приложения?

VD>А, ну, да. Самому то не смешно? Значит на компилируемый дотнет перевести нельзя. Памяти мало и процессор дохлый. А на интерпретируемый Эрлэнг без вопросов. Класс!

А что смешного-то? Обычная и достаточно распространенная ситуация.
Я же не случайно спросил "Каково там будет .Net-у?", а не сколь шустро будут работать приложения на нем.
Просто потому, что они никак не будут работать. Потому, что там даже требуемая дотнетом весия виндов нормально не развернется. Не говоря уж про MS SQL (база требуется) и IIS (web-сервисы требуются).
А ерланг развернуть можно (например, под урезанной версией FreeBSD или под кнопиксом). Разрешения на кеши для мнезии конечно придется укрутить до минимума, но однако работать будет.

VD>Хм. А ты вкурсе, что у МС Сиквела есть безсплатный вариант единственным ограниченимем которго по большому счету является ограничение в 4 гига на БД?

В курсе. (Хотя, на сколько я помню, для 2000-ного ограничение было 1 гиг.) Но все равно, при учете того на сколько "неплотная" у него база получается — это недостаточный объем. Требуеся масштабирование от 2 до 100 гиг (если мерять в объеме баз MSSQL). Просто из опыта предидущей версии.

VladD2 wrote:
> Здравствуйте, raskin, Вы писали:
> R> если пользоваться макросами в полную
> R>мощность, то, вероятно столько же — макрос может делать любое вычислимое
> R>преобразование.
>
> Дык в том, то все и дело, что в Нэмерле макрос может делать не только
> преобразования. Он еще может взаимодействовать с компилятором и
> использовать внешний, библиотечный код.
Ну внешний код, как мне казалось, и для Лиспа не вопрос. Взаимодействие
с компилятором за счёт наличия синтаксиса действительно должно давать
какие-то возможности. В Лиспе-то компилятор не намного больше знает, чем
макрос.
>
> R> Предсказуемость зависит при этом от того, насколько в
> R>этот момент ближе один язык, чем другой. Про удобнее поверю легко.
>
> А предсказуемость выше, так как язык статически типизированный. Контроля
> больше. Ну, и наличие реального синтаксиса позволяет больше веще
> контролировать.

Пока я не писал на этом языке и не читал на нём программ, я не могу
сказать где у него может пострадать предсказуемость, например, от
похожести двух конструкций. Но я даже Mono уже поставил и nemerlish
запускается.

Posted via RSDN NNTP Server 2.0

VladD2 wrote:
> В VS 2005 есть такая настройка "Не сохранять проект". Новый проект
> создается как бы в воздухе и если ты попыташся создать новый или закрыть
> IDE тебе предложат записать его или потерять изменения. Я этим делом
> постоянно пользуюсь. Веверн, что создать мелкий тест у меня получится
> как иминимум не медленее чем у любого любителя консольных интерпретаторов.
Гм, для того чтобы вызвать функцию 5 раз — причём параметры 5 вызова
зависят от результата 4-го, я же не уверен в результате тестирования,
ещё надо выбирать при создании тип: консольное, вписывать write/print в
зависимости от языка, и подключать модуль — который в некомпилируемом
состоянии, так как интерфейс написан, а имплементация — нет.
Или — alt-tab и вставить из буфера пару страниц кода (функция же требует
предыдущую, согласен). Зависит от привычек, что лучше.
>
> Кстати, Экспресс-версии студии доступны для свободного скачивания. Так
> что можешь глянуть. Там наворотов по мнее, но все же.
У меня процент времени в Linux весьма велик. Скорее всего, поленюсь.

Posted via RSDN NNTP Server 2.0

VladD2 wrote:
> Здравствуйте, raskin, Вы писали:
>
> R>Жаль. Вот будет отделим... А то ставить dotGNU или Mono совсем неохота.
>
> А качать какие-нить 100 метров ЦигВина это нормально? Да и что там
> ставить то? Он ставится за пять минут без единого вопроса. А скоро
> дотнет будет на любой винде.
Замечу, речь о Linux. Когда увидел, что Mono — родная для nemerle среда
— скачал, скомпилировал.
>
> R>"Пусть это сделают другие" — то, что я не собираюсь сохранять, пусть
> R>компилируется без моих активных действий (кроме ввода этого).
>
> Для этого созданы IDE. Нажал "Создать проект", выбрал тип, написал что
> надо, нажал F5. Лишних действий == 0.
Ну, всё равно writeln набирать. Это — лишнее.
>
> R>А зачем он нужен, если на нём даже посчитать ничего нельзя?
>
> Почему нельзя? Но писать код на КПК — формернное издевательство. Уж
Для меня посчитать чуть-чуть — не всегда про числа.
> лучше написать и скинуть на КПК. Мы тут были недавно на Кубе и у нас
Гм, на КПК иногда хочется написать что-то, когда ноутбук далеко (дома),
а розеток в десяти метрах не было никогда
> погорел крадридер. Но был КПК который читает КомпактФлэш и может писать
> на SD. Вот только одна беда, софтина идущая в поставке с ВыньЦЕ так
> тормозила, что была практически не пригодна для использования. Ну, и
> что? Сели и за 10 минут написали утилитку на С№ 2.0. Даже с ГУИ
> повыпендирвались. Никаких особых проблем.
>
> R> IDE мне не
> R>нужна, интерпретатор хоть какой-нибудь. Без этой возможности
> R>неинтересно.
>
> Могу только порадоваться за тебя. Я довольствоваться интерпретаторами не
> могу. Мог бы давно бы на том же Немерле писал бы.
На КПК ещё и компилировать — слишком, будет тормозить сильнее
интерпретатора.
>
> R> Но тогда ему CompactFramework нужен, если его (CFw) вообще
> R>хватит. Интересно, не захочет ли он установленную консоль.. Судя по
> R>сайту, если я этим займусь — все шишки мои.
>
> Думаю захочет. Я вообще не понял почему в ВыньЦЕ ее по умолчанию не ставят.
Мне просто ни одну ещё поставить без глюков не довелось.
>
> R>В Паскаль все односимвольные опечатки не в именах переменных, которые я
> R>когда-либо делал, мешают компиляции.
>
> Хм. Паскаль тут не причем. Просто Паскаль — это один из типобзопасных
> языков.
>
> R> В Си одну такую я искал очень
> R>долго.
>
> Потому как С не типобезопасный. Уверяю тебя, что синтаксис тут не
> причем. Ты точно так же не будешь часами искать ошибки ни в C#, ни в
> Нэмерле, потому как это еще более строгие языки чем Паскаль. И в отличии
> от него поддеживающие кучу парадигм. В общем, не хлам доисторический, а
> современные языки.
Я никого не хочу расстраивать, но эта опечатка — точка с запятой,
испортившая if. Не помню, был ли это Си или Си++. Даже посмотрев в
отладчике, как if игнорируется, я не понял, что происходит. Почему этот
код был легален??
А про хлам.. Си-шарп даст генерировать generic-ами что угодно? Тогда его
тоже надо докручивать — так же, как Паскаль. Немерле посмотрю.
>
> R> Больше я на этом (надеюсь) так не попадусь, но осадок... Ну и
> R>выглядит Паскаль на мой вкус лучше.
>
> Незнаю. По мне так это любовь к рющечкам. Сила языка не в том как у него
> выглядят коснтрукции блока или отделяются операторы. Кстати, во многих
> ФЯ вообще нет ни блоков, ни операторов (в смысле statmonts).
Паскаль читаем. Схема требует привычки для чтения, Си* тоже.

Posted via RSDN NNTP Server 2.0

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

VD>Другими словами от программыных ошибок уйти никуда нельзя. Но можно создать условия в которых многие ошибки не будут критичны. И сделать это можно не только на Эрлэнге.
Все верно ! Дело только в цене, которой это достигается. И для Ерланга она минимальна ( среди более-менее широко используемых языков )

VD>Тогдя я знаю идеальных язык. Это Брэйнфак. У него самый минимальный язык. И говорят, что на нем можно написать все что угодно.
Первое — с читаемостью не просто проблемы, а просто никакая она. Второго уже не требуется

VD>Эту сказку я слышал не раз. Вот толко не часто видишь людей которые могли бы надолбить хотя бы сколько я. А я далеко не уникум.

Очень хорошо ! А насколько у тебя отличается количество строк в день в зависимости от языка ? То-есть личная статистика ?

G>> и слабо зависит от языка,
VD>Ага. И от среды тоже? Это сказки.
Тем не менее, это так. Влияние среды, безусловно, есть — но оно не слишкос велико...

VD>Оди использует соверменную IDE со средствами рефакторинга, а другой половину рабочего времени убивает на переключение между конослями.
Ну, ежели другая половина рабочего времени дает ему производительность в 4 раза выше, то пусть !

VD>Понимаш ли. Компактность понятие очень обманчивое. Код может быть кратким, но не информативным. Вот Эрлэнг, Хаскель и Лисп лично мне очень тяжело читать. Очень многое седит на соглашениях, неявных предполжениях и т.п. Если сравнить код то может оказаться, что в более пушистом записано в общем-то столько же. Но вот только записано это дело более подробно. Ну, там переменные имеют смысл, а не любимые в сообществе фэнов ФЯ h, a, b, g, f... Фнукии названы так чтобы это было понятно, а не чтобы было кртако. Операторы более традиционны и понятны, а не представляющие из себя криптографию.
Я, к примеру, лисповские сорцы читать просто не могу. Но это особенности моего восприятия и ничего не говорит об самом языке.
А вот соглашений и неявных предположений в функциональных языках — извините, маловато будет.

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

VD>Напрямую зависит. Это слагаемое. Если оно маленькое, то и сумма будет соотвествующая.
VD>Между современными языками (если не брать разные С/С++) не такая уж огромная разница. А вот в скорости она очень даже.
Возможно, у нас разный опыт...Мой опыт говорит мне, что разница между языками колоссальна. А вот как раз в скорости результирующего продукта — не весьма

VD>Классный критерий. То есть так как на С++ пишут и жесткий (т.е. реальный) реалтайм, то на нем стало быть все еще предсказуемее. Но ты то говоришь об обратном. Нестыковочка.
Предсказуемее исключительно в участках, заточенных на реалтайм. Во всех других местах С/С++ довольно-таки неопределен по производительности

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

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

Во-во. И я о том же. Сравнивать, разумеется, надо макросредства языков, имеющих синтаксис. И все станет гораздо интереснее.

А можно "столь неординарную вещь" немного посравнивать с OCaml-ом (полноценная система типов заточенная под автоматический вывод типа + ООП + ML-ные модули) и его препроцессором camlp4, который позволяет делать с грамматикой базового языка вообще все что угодно — удалять, заменять, и добавлять правила?

Я-то во флейме участвоватьне буду, так как для себя с ответом на этот вопрос давно определился, а вот ребятам будет интересно.

Добавляем, например, цикл repeat-until.

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

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

G> Я-то во флейме участвоватьне буду, так как для себя с ответом на этот вопрос давно определился, а вот ребятам будет интересно.

Флейма не будет.

Это последнее мое сообщение в этой ветке. OCaml бесспорно хороший язык, но он активно развиваться уже не будет(возможно это кстати и хорошо для промышленного применения). Лично меня он не устраивает, так как область моих профессиональных интересов это в основном .NET. Есть конечно F#, но по степени интеграции с .NET, да и по другим параметрам он imho проигрывает Nemerle. А вот Nemerle будет активно развиваться и имеет все шансы если не стать полноценным промышленным языком, то по крайней мере повлиять на mainstream языки будущего, так сказать дать пищу для размышлений дизайнерам языков. Кстати сказать Nemerle безусловно создавался под влиянием языков семейства ML вообще и OCaml в частности. Вообще Nemerle изначально позиционируется как гибридный язык. Т.е. большинство возможностей языка не претендует на новизну. На новизну претендует их сочетания, реализация и ряд интересных дизайнерских решений.

G>Добавляем, например, цикл repeat-until.
G>

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

Без проблем:

macro repeat_until(cond, body) 
syntax ("repeat", body, "until", "(", cond, ")") 
{
    <[ $body; while(!($cond)) $body ]>
}

Собственно половину работы за меня сделали разработчики компилятора, добавив в него цикл do-while(из макроса которого это и появилось

). А половину сделал ты.

Если интересно как использование этого макроса выглядит на практике:

mutable i = 0;
repeat { System.Console.WriteLine("Hello There!"); i++; } until (i == 10);
// можно и так
i = 0;
repeat i++ until (i == 10);
assert(i == 10);

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

macro mutable_definition (body) 
syntax ("var", body) 
{
    match(body)
    {
        | <[ $(id : name) = $val ]> => <[ mutable $(id : name) = $val ]>
        | _ =>  Message.Error ($"var: invalid syntax - expected name = expr;, got $body"); <[ ]>
    }
}

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

G>> Я-то во флейме участвоватьне буду, так как для себя с ответом на этот вопрос давно определился, а вот ребятам будет интересно.

VK>Флейма не будет.

Это последнее мое сообщение в этой ветке.

Да лана тебе

. Я ж добрый.

VK>OCaml бесспорно хороший язык, но он активно развиваться уже не будет(возможно это кстати и хорошо для промышленного применения).
С чего бы это INRIA должен бросить свою любимую игрушку?

В ocaml, между прочим, эксперименты над языком упрощены до предела. Благодаря наличию этого самого camlp4.

VK>На новизну претендует их сочетания, реализация и ряд интересных дизайнерских решений.
Да нет тут никакой новизны. Самая большая новизна — взят OCaml, и натянут на синтаксис С#. Какая неординарная штука.

Впрочем, натянут качественно, и с творческим подходом — мне в свое время понравилось, как это сделано.

А вообще — из семейства .NET языков этот — безусловно один из самых приятных, в этом я с тобой согласен. Будь я привязан к .NET — пробовал бы его, конечно.

G>>Добавляем, например, цикл repeat-until.
G>>

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

VK>Без проблем:

VK>

VK>macro repeat_until(cond, body) 
VK>syntax ("repeat", body, "until", "(", cond, ")") 
VK>{
VK>    <[ $body; while(!($cond)) $body ]>
VK>}
VK>

VK>Собственно половину работы за меня сделали разработчики компилятора, добавив в него цикл do-while(из макроса которого это и появилось

). А половину сделал ты.

Что и требовалось доказать — сходство видно невооруженным глазом. Есть правда один нюанс. Я вот, например, расширил грамматику, явно указав правило, которое модифицируется. Как я сказал, можно изменять и удалать выбранные правила из базовой грамматики. Так вот, любопытнейший вопрос, ради которого я и привел тебе свой пример. А что произошло с "базовой грамматикой" у тебя? Куда встроился твой макрос?

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

VK>>На новизну претендует их сочетания, реализация и ряд интересных дизайнерских решений.
G>Да нет тут никакой новизны. Самая большая новизна — взят OCaml, и натянут на синтаксис С#.

А можно я тут влезу посреди битвы титанов и задам вопросик (не флейма ради, а действительно интересно): тут проскакивали фразы, что макросы Немерле имеют доступ к информации о типах, а Камлп4, насколько мне известно, позволяет делать преобразования AST. Учитывая это, не слишком ли сильное утверждение, что Немерле содран с ОКамла (прим.: Немерле не смотрел)?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

VK>>>На новизну претендует их сочетания, реализация и ряд интересных дизайнерских решений.
G>>Да нет тут никакой новизны. Самая большая новизна — взят OCaml, и натянут на синтаксис С#.

PA>А можно я тут влезу посреди битвы титанов и задам вопросик (не флейма ради, а действительно интересно): тут проскакивали фразы, что макросы Немерле имеют доступ к информации о типах, а Камлп4, насколько мне известно, позволяет делать преобразования AST. Учитывая это, не слишком ли сильное утверждение, что Немерле содран с ОКамла (прим.: Немерле не смотрел)?

Битвы, во первых, нет. "Титаны" прекрасно друг друга понимают, и спорить не собираются.

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

Что же касается мета-макро-прочего — здесь у Немерле немного другой подход. По моим ощущениям, Camlp4 мощнее и гибче, и чуть ниже уровнем. В целом — ничего особенного с точки зрения языка этот nemerle собой не представляет. Но писать на нем, безусловно, гораздо приятнее, чем на этих убожествах C# и Java. Специально учить Nemerle смысл есть только в том случае, если есть желание иметь приятный язык для написания свистулек-прототипов под .NET, и от дотнета некуда деваться.

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

R>Замечу, речь о Linux. Когда увидел, что Mono — родная для nemerle среда
R>- скачал, скомпилировал.

Боюсь, что Линукс интересен не многим. Тут же речь не о частном случае, а в общем, как я понимаю?

R>Ну, всё равно writeln набирать. Это — лишнее.

Хм. Мы еще о необходимости интерпретаторов или уже о синтаксисе конретного языка?

R>Для меня посчитать чуть-чуть — не всегда про числа.

Посчитать лучше на калькуляторе. А как считать не про числа, я и представить то боюсь.

R>Гм, на КПК иногда хочется написать что-то, когда ноутбук далеко (дома),
R>а розеток в десяти метрах не было никогда

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

R>На КПК ещё и компилировать — слишком, будет тормозить сильнее
R>интерпретатора.

Современный КПК это обычно не ниже 200 мегагерц. Я копилровал С++- и Дельфи-проекты еще на 90-ом Пне. Так что...

R>Мне просто ни одну ещё поставить без глюков не довелось.

И МС-ную?

R>Я никого не хочу расстраивать, но эта опечатка — точка с запятой,
R>испортившая if. Не помню, был ли это Си или Си++. Даже посмотрев в
R>отладчике, как if игнорируется, я не понял, что происходит. Почему этот
R>код был легален??

Ты про такой случай:

class Program
{
    static void Main()
    {
        bool OK = true;

        if (OK)
            ;
    }
}

Компилятор C# про это дело тебе сразу же заметит:

Program.cs(8,4): warning CS0642: Possible mistaken empty statement

R>А про хлам.. Си-шарп даст генерировать generic-ами что угодно? Тогда его
R>тоже надо докручивать — так же, как Паскаль. Немерле посмотрю.

Дженерики == обобщенное программирование. К метапрограммированию, в отличии от шаблонов С++ они оношения не имеют.

R>Паскаль читаем. Схема требует привычки для чтения, Си* тоже.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

R>Гм, для того чтобы вызвать функцию 5 раз — причём параметры 5 вызова
R>зависят от результата 4-го, я же не уверен в результате тестирования,

Не понял, причем тут это? Нужно вызвать 5 раз — вызови пять раз.

R>ещё надо выбирать при создании тип: консольное, вписывать write/print в
R>зависимости от языка, и подключать модуль — который в некомпилируемом
R>состоянии, так как интерфейс написан, а имплементация — нет.

Это вопросы выбора языка. К вопросу интерпретации vs. компиляции отношения не имеющие. Нет проблем использовать компилируемую версию того же Питона из под VS 2005. Лично я предпочту Шарп, но это дело вкуса.

R>Или — alt-tab и вставить из буфера пару страниц кода (функция же требует
R>предыдущую, согласен). Зависит от привычек, что лучше.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

R>Ну внешний код, как мне казалось, и для Лиспа не вопрос.

Покажи, плиз, как на Лиспе вызвать внешний код из макроса?

R> Взаимодействие
R>с компилятором за счёт наличия синтаксиса действительно должно давать
R>какие-то возможности. В Лиспе-то компилятор не намного больше знает, чем
R>макрос.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

R>>Ну внешний код, как мне казалось, и для Лиспа не вопрос.

VD>Покажи, плиз, как на Лиспе вызвать внешний код из макроса?

Берешь и вызываешь. Макросы ничем в этом смысле от функций не отличаются.
Лисп — это же не компилятор, а среда. Если в ней известны определенные функции на момент вызова макроса, то их можно вызвать.

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

EXO>Странно... и почему это я не заметил скачка производительности у знакомых программистов,
EXO>когда они перешли от VS6 к VS2005?

Видимо птому, что они пишут на С++. А горбатого только могила...

EXO>Ну дак это то о чем я и говорил: .Net (все языки) и IIS — одна платформа.

Вообще-то IIS самый что ни на есть неуправляемый сервер, а дотнет просо его плагин. Но действительно реализован плагин качесвтенно. Однако говорят, что с Апачем Моно тоже неплохо инетегрируется. Тут дело видимо в компонентности. Кмпонентные среды хорошо интегрируются в разные серверы приложений.

EXO>И Апач с явой — тоже в одну платформу интегрированы.

Дык Моно в Апач интегрируется вроде тоже не плохо. Просто Ява тоже компонентная среда.

EXO>Ты разве не помнишь начало "явизации"??? И участие в этом того же микрософта. Да и остальных...

Мне кажется ты путашь причино-следственную связь. Это не Ява раскрутилась птому, что МС помогал. А МС начал помогать так как увидил, что Ява начала раскручиваться. А раскрутилась она так как перспективна

Если ты помнишь, то Яву талкали как средство создания аплетов, то есть как замену скриптам. А реально Ява раскрутилась скорее как средство создания серверного ПО. И приемущества у нее были именно те же, что у Эрлэнга — типобезопасность и простота. А уж когда подключились самоделкины, то даже убогость синтаксиса не стала огромной проблемой.

EXO>Макросы лиспа (так же как и констукции эрланга) — это сам язык.

Дык макросы Нэмерла тоже. Они на нем пишутся и им же манипулируют. Просто сам язык куда сложнее.

EXO> А речь была о парсерах и лексерах идущих в составе платформы. Это уже немного другое. (А .Net-овскую комплектацию посмотрю.)

Хм. Парсер есть у самого Нэмерла. Да и зачем "в кмплектациия"? В чем проблема скачать zip? Парсеры есть отдельные. От клонов yacc-а (Jey), до CocoR и ANTLD.

VD>>А, ну, да. Самому то не смешно? Значит на компилируемый дотнет перевести нельзя. Памяти мало и процессор дохлый. А на интерпретируемый Эрлэнг без вопросов. Класс!

EXO>А что смешного-то? Обычная и достаточно распространенная ситуация.
EXO>Я же не случайно спросил "Каково там будет .Net-у?", а не сколь шустро будут работать приложения на нем.

А каково Эрлэнгу и его ранайму?

Есть компакт-фрэймворк специльно заточеный на минимальное железо. У Эрлэнга наверно тоже есть упрощенный рантайм...

EXO>Просто потому, что они никак не будут работать. Потому, что там даже требуемая дотнетом весия виндов нормально не развернется. Не говоря уж про MS SQL (база требуется) и IIS (web-сервисы требуются).
EXO>А ерланг развернуть можно (например, под урезанной версией FreeBSD или под кнопиксом). Разрешения на кеши для мнезии конечно придется укрутить до минимума, но однако работать будет.

И что мешает развернуть тот же моно? Или использовать встраеваемую версию NT?

EXO>В курсе. (Хотя, на сколько я помню, для 2000-ного ограничение было 1 гиг.)

Да. Но что вспеминать 2000, когда на дворе 2006-ой год?
Да и для бесплатной версии самое оно. Если у кого-то большие объемы, то ему и полноценный сервер купить не грех.

EXO> Но все равно, при учете того на сколько "неплотная" у него база получается — это недостаточный объем. Требуеся масштабирование от 2 до 100 гиг (если мерять в объеме баз MSSQL). Просто из опыта предидущей версии.

Вот у тебя и убдет масштабирование. 100 гиг — это уже серьезная задача решать которую на разных изамных движках пишушихся на коленке — это глупость. Хот 2 гига тоже объем не малый. Если это минимум, то говорить о бесплатных серверах уже смешно. Если конечно речь не идет о сбросе в БД логов.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>>Тогдя я знаю идеальных язык. Это Брэйнфак. У него самый минимальный язык. И говорят, что на нем можно написать все что угодно.
G>Первое — с читаемостью не просто проблемы, а просто никакая она. Второго уже не требуется

А ты думал я этот язык как идеал читабельности привел? Я просто показываю тебе, что минимализм синтаксиса не дает простоты. Это ошибочная предпосылка.

Простота это очень сложное комплексное понятие.

G>Очень хорошо ! А насколько у тебя отличается количество строк в день в зависимости от языка ?

Очень сильно.

G>То-есть личная статистика ?

Статистики нет. Но приблизительно могу сравнить. Работающую версию редактора кода с подсветкой синтаксиса я создал за месяц ненапряжного труда. В разы более ириметивную версию на С++ я создавал пол года. Конечно я стал более опытным, но и сейчас бы у меня ушло на это бы месяца 4 не менее. Правда и объем исходников существнно меньше получился. Но все же положительная динамика в скорости аписания есть.

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

G>>> и слабо зависит от языка,
VD>>Ага. И от среды тоже? Это сказки.
G>Тем не менее, это так. Влияние среды, безусловно, есть — но оно не слишкос велико...

Оно огромно! Моя производительность снижается на порядок если я пишу в нотпэде.
Я готов отказаться от более продвинутого языка если есть менее продвинутый, но с отличной поддежкой среды. Ведь среда может компенсировать многие проблемы и дать огромный выирыш.

VD>>Оди использует соверменную IDE со средствами рефакторинга, а другой половину рабочего времени убивает на переключение между конослями.
G>Ну, ежели другая половина рабочего времени дает ему производительность в 4 раза выше, то пусть !

Простая арифметика. 4 < 20.

Ускорившись в 4 раза, я замедлюсь в 20. В тоге я все равно относительно замедлюсь. В бизнесе это называется упущенной выгодой. Ее може быть не заметно, но она есть.

G>Я, к примеру, лисповские сорцы читать просто не могу. Но это особенности моего восприятия и ничего не говорит об самом языке.

И я с трудом их читаю. И еще миллионы людей. Так что это общие особенности. И уверен, что им есть вполен конкретное обяснение.

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

Огромное количество. Одни соглашения о названих CAR/CDR чего стоят? Ну, почему не H/T хотя бы? Я уже не говорю, о том, что более длинные head/tail хотя и длиннее, но реально намного бы повысили бы простоту чтения.

Я придерживаюсь гипотизы, что для человека нет разницы между одно- двух-буквенными конструкциями и словами. Человек читает их какбудто распознает образы. Значимы обычно первая и последняя буква (поэтому в Лиспе так тяжело отличать CAR, CONS, CDR и т.п.).

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Q>Берешь и вызываешь. Макросы ничем в этом смысле от функций не отличаются.
Q>Лисп — это же не компилятор, а среда. Если в ней известны определенные функции на момент вызова макроса, то их можно вызвать.

Это будет код макроса. А речь о внешних модулях. Хотя это конечно скорее разговор о поддежке компонентного подхода.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

О том что ОКамл охринительный язык я понял когда пытаясь в нем разобраться не задал типы параметров и сделал какую-то ошибку. — моп твою ять — идумал я! — а вель еще говорят, что сообщения об ошибках в С++ запутаны!

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

Уж если говорить о том кто и что драл, то все они драли у Лиспа. В поставке Нэмерла есть файл metaprogramming.pdf. В его конце есть подробное описание того, что рассматривалось в качестве прототипа и какие приемущества/недостатки есть у той или иной реализации (Related work).

Авторы утверждают, что основным прототипом были макросы Схемы. А Окамл оценивают довольно скупо хотя и достойно:

10.4 CamlP4 CamlP4 [12] is preprocessor for OCaml. Its LL(1) parser is completely dynamic, thus allowing quite complex grammar extensions to be expressed. Macros (called syntax extensions) need to be compiled and loaded into the parser prior to be used. Once run, they can construct new expressions (using quotation system), but only at the untyped parse tree level. It is not possible to interact with compiler in more depth.

... << RSDN@Home 1.2.0 alpha rev. 637>>

raskin,

R>Гм, на КПК иногда хочется написать что-то, когда ноутбук далеко (дома),
R>а розеток в десяти метрах не было никогда

Позволь тебе порекомендовать J. Как раз для КПК самое то.

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

G>>Я, к примеру, лисповские сорцы читать просто не могу. Но это особенности моего восприятия и ничего не говорит об самом языке.

VD>И я с трудом их читаю. И еще миллионы людей. Так что это общие особенности. И уверен, что им есть вполен конкретное обяснение.

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

VD>Огромное количество. Одни соглашения о названих CAR/CDR чего стоят? Ну, почему не H/T хотя бы? Я уже не говорю, о том, что более длинные head/tail хотя и длиннее, но реально намного бы повысили бы простоту чтения.

VD>Я придерживаюсь гипотизы, что для человека нет разницы между одно- двух-буквенными конструкциями и словами. Человек читает их какбудто распознает образы. Значимы обычно первая и последняя буква (поэтому в Лиспе так тяжело отличать CAR, CONS, CDR и т.п.).

Проблемы с читабельностью лиспа кончаются, как только вы попробуете на нем писать. Причем минимальной практики достаточно — пары сотен строк. После этого вам будет в других местах не хватать того, как лихо можно редактировать программу с помощью insert-parentheses, mark-sexp и transpose-sexps.
Еще мне в лиспе нравиться отсутствующая в С свобода называния функций, делающая возможным имена типа:
method?, depth-first-strategy, number->string, set!, которые читабельности как раз весьма способствуют.

car и cdr уже 45 лет ни на что не заменили, потому, что из них логично и предсказуемо вытекают аббревеатуры вида:
cadar, cadddr и.т.д , которые в результате можно не запоминать. Ничто не мешает писать

(list-ref the-list 3)
;; вместо: 
(cadddr the-list)

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

Здравствуйте, VladD2, Вы писали:
VD>Простая арифметика. 4 < 20.

Ускорившись в 4 раза, я замедлюсь в 20. В тоге я все равно относительно замедлюсь.

Вот здесь похоже и есть точка непонимания.
У меня например, эта разница около 40%
Все остальные элементы спора — уже следствия.

VladD2 wrote:
> Здравствуйте, raskin, Вы писали:
>
> R>Гм, для того чтобы вызвать функцию 5 раз — причём параметры 5 вызова
> R>зависят от результата 4-го, я же не уверен в результате тестирования,
>
> Не понял, причем тут это? Нужно вызвать 5 раз — вызови пять раз.
Это пять запусков программы — я ещё не решил какие параметры.
>
> R>ещё надо выбирать при создании тип: консольное, вписывать write/print в
> R>зависимости от языка, и подключать модуль — который в некомпилируемом
> R>состоянии, так как интерфейс написан, а имплементация — нет.
>
> Это вопросы выбора языка. К вопросу интерпретации vs. компиляции
> отношения не имеющие. Нет проблем использовать компилируемую версию того
> же Питона из под VS 2005. Лично я предпочту Шарп, но это дело вкуса.
В программе на LISP просто пять вызовов функции не будут выводить
результат каждого без display, а вот в интерпретаторе будут.
>
> R>Или — alt-tab и вставить из буфера пару страниц кода (функция же требует
> R>предыдущую, согласен). Зависит от привычек, что лучше.
>
> А в клипборде то откуда возьмется? Вот пока будешь долбить без
> плноценного комплита и т.п. и офигешь.

Я рассматриваю ситуацию, когда от модуля есть куски, и я хочу прямо
сейчас их оттестировать. И они в файле лежат, причём редактирую я не в
MIT-Scheme Editor (например, потому что пишу не на MIT Scheme). А
комплит много где есть. Только в Nemerlish он такой странный (я пытался
убедить его напечатать за меня System.Console.WriteLine . Он победил).
Даже в ViM без настроек уже можно делать комплит по встречающимся словам
(нет ничего тупее), но в предположении написания и тестирования кода
мелкими кусочками комплит нужен не столько как подсказка, сколько как
сокращение набора.

Posted via RSDN NNTP Server 2.0

Здравствуйте, VladD2, Вы писали:
VD>Видимо птому, что они пишут на С++. А горбатого только могила...

Да нет, сейчас на C#.

VD>Мне кажется ты путашь причино-следственную связь. Это не Ява раскрутилась птому, что МС помогал. А МС начал помогать так как увидил, что Ява начала раскручиваться. А раскрутилась она так как перспективна

Я хорошо помню, какое сопротивление яве было в сообществе. И как тогда старались рекламисты микрософт.

VD>Если ты помнишь, то Яву талкали как средство создания аплетов, то есть как замену скриптам.

Очень недолго. Потом IBM громко закричал о северных задачах, а MS поддержал.

VD>Хм. Парсер есть у самого Нэмерла. Да и зачем "в кмплектациия"? В чем проблема скачать zip? Парсеры есть отдельные. От клонов yacc-а (Jey), до CocoR и ANTLD.

Кстати, посмотрел ANTLD. И обнаружил, что "знакомые все лица".
От своего предка — PCCTS он ушел не слишком далеко (а с последним я года полтора возился и глюки его знаю).
Так вот — наиболее критичный глюк основного алгоритма не исправлен.
Там токенайзер начинал вести себя странно, если требовалась глубина анализа больше 2.
То есть корректно компилировались только простые и очень однозначные грамматики.

VD>А каково Эрлэнгу и его ранайму?

Нормально.
Вот у меня сейчас на разработческой тачке для отладки запущен сервер + мнезия (с базой около полугига) + вебсервер.
Суммарно в памяти занимают 30 мег. При этом кеши мнезии не урезаны. Можно уплющить мег до 12, проиграв по быстродействию где-то в четверо. Если учесть, что на микрописишках базы обычно только "аварийного хранения" (дня на 4 — если в праздники оборвется связь с центральным сервером). То вполне можно жить.

VD>И что мешает развернуть тот же моно?

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

VD>Да и для бесплатной версии самое оно. Если у кого-то большие объемы, то ему и полноценный сервер купить не грех.

Вопрос в самих этих объемах.
В Штатах — да, граница где "лицензия sql уже не тяготит" проходит где-то в районе 4 гиг. В России денег у предприятий поменьше будет (некоторые сектора типа нефте-газа я не считаю). И граница эта колеблется примерно в районе 10-15 гиг.

VladD2,

VD>Огромное количество. Одни соглашения о названих CAR/CDR чего стоят? Ну, почему не H/T хотя бы? Я уже не говорю, о том, что более длинные head/tail хотя и длиннее, но реально намного бы повысили бы простоту чтения.

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

CAR и CDR — исторически сформировавшиеся и давно устоявшиеся названия. Если глянуть в историю, то всё становится достаточно логично:

The names have their origin in the first implementation of Lisp on an IBM 704 computer, and retain their primacy for purely nostalgic reasons. But on the 704, an atom was represented by a single 36-bit machine word containing a so-called address part and a decrement part. Each of these parts had a length of 15 bits. The address part was used to point to the head of a list and the decrement part was used to address its tail. The functions used to extract either part of a machine word were called car (Contents of Address of Register) and cdr (Contents of Decrement of Register).

http://en.wikipedia.org/wiki/Cadr

Кроме того ещё полезно прошвырнуться по листингам нетривиальных примеров Лисп программ и посмотреть, насколько часто там используются непосредственные манипуляции списками (то есть применение CAR/CDR) и насколько часто используются операции более высокого уровня.

structure-search-example.lisp, 4.5Kb — ни одного вхождения car/cdr
word-ladders.lisp, 4.5Kb — ни одного вхождения
backprop.lisp, 15Kb — ни одного вхождения
deftable.lisp, 12.5Kb — car=1, cdr=3
Gates.lisp, 6Kb — ни одного вхождения
blocks.lisp, 6.2Kb — ни одного вхождения
Simple-Metering.lisp, 21Kb — car=1, cdr=1

Здравствуйте, EXO, Вы писали:
VD>>И что мешает развернуть тот же моно?
EXO>То, что оно пока не продукт промышленного качества.
EXO>Но пока рано.

Кстати, в дальнейшем я бы уж смотрел скорее сингулярити, чем моно.
Но тоже рано.

VladD2 wrote:
> Здравствуйте, raskin, Вы писали:
>
> R>Замечу, речь о Linux. Когда увидел, что Mono — родная для nemerle среда
> R>- скачал, скомпилировал.
>
> Боюсь, что Линукс интересен не многим. Тут же речь не о частном случае,
> а в общем, как я понимаю?
Я спрашивал, стоит ли мне на это смотреть (=> ставить).
>
> R>Ну, всё равно writeln набирать. Это — лишнее.
>
> Хм. Мы еще о необходимости интерпретаторов или уже о синтаксисе
> конретного языка?
А в каком языке при вычислении числа и его выкидывании оно выведется на
экран. Ладно, нужен не writeln, а echo, printf, whatsoever.
>
> R>Для меня посчитать чуть-чуть — не всегда про числа.
>
> Посчитать лучше на калькуляторе. А как считать не про числа, я и
> представить то боюсь.
На калькуляторе простейший конечный автомат обычно не пишется.
Рекурренты требуют искусства и не всегда поддаются описанию. И т.д.
>
> R>Гм, на КПК иногда хочется написать что-то, когда ноутбук далеко (дома),
> R>а розеток в десяти метрах не было никогда
>
> На КПК проблематично именно писать. Если ты пишешь одиним пальцем, то
> может тебе и пофигу. А я без клавы писать очень не люблю. Ноут и то
> неудобство вызвает. Я знаете ли привых к "натуральным" клавам.
Мне не по фигу (пишу и правда где-то пятью пальцами), но это лучше, чем
не мочь сделать очевидное действие.
>
> R>На КПК ещё и компилировать — слишком, будет тормозить сильнее
> R>интерпретатора.
>
> Современный КПК это обычно не ниже 200 мегагерц. Я копилровал С++- и
> Дельфи-проекты еще на 90-ом Пне. Так что...
Ну, даже 500. На 486-66МГц я тоже программировал. Впрочем, КПК — это
RISC, но всё равно получается больше, да. Однако на маленьком экране
тормозить буду ещё и я при компиляции (я так и не научился эффективно
переключать окна). Плюс к тому — в простых случаях интерпретатор даёт
ответ почти мгновенно. Компилятор ещё надо выбрать, чтобы линковка не
занимала по секунде, а есть ещё и просто затраты на управление им.
А Схема уже есть.
PS. Не буду я ставить Nemerlish на КПК. Секунда-другая на 2+2 — это
много. Хотя через полминуты после появления приглашения тормозить перестаёт.
>
> R>Мне просто ни одну ещё поставить без глюков не довелось.
>
> И МС-ную?
Вроде да. Глюкодром. КПК — VGA-шный. Перерисовка консоли не всегда
затрагивает левый край.
>
> R>Я никого не хочу расстраивать, но эта опечатка — точка с запятой,
> R>испортившая if. Не помню, был ли это Си или Си++. Даже посмотрев в
> R>отладчике, как if игнорируется, я не понял, что происходит. Почему этот
> R>код был легален??
>
> Ты про такой случай:
>
> class Program
> {
> static void Main()
> {
> bool OK = true;
>
> if (OK)
> ;
> }
> }
>
>
> Компилятор C# про это дело тебе сразу же заметит:
>
> Program.cs(8,4): warning CS0642: Possible mistaken empty statement
>
Наконец-то это стало warning. Мучительно не пойму, почему это исходно (в
Си) не error — если это нужное поведение, то всё равно можно писать if(){} .

> R>А про хлам.. Си-шарп даст генерировать generic-ами что угодно? Тогда его
> R>тоже надо докручивать — так же, как Паскаль. Немерле посмотрю.
>
> Дженерики == обобщенное программирование. К метапрограммированию, в
> отличии от шаблонов С++ они оношения не имеют.
Ну, можно сказать, что язык без метапрограммирования вообще сам по себе
не живёт. Его надо докручивать. Паскаль я уже докрутил. Что есть — ООП
исходно + метапрограммирование. + замена Make, так как появились новые
типы зависимостей.
>
> R>Паскаль читаем. Схема требует привычки для чтения, Си* тоже.
>
> С читаем не хуже Паскаля, если конечно в коде не используется
> выкрутасов. Даже мне синтаксис паскаля нравится намного меньше. В
> Обероне он намного продуманнее.
Дело вкуса. Мне Паскаль читать приятнее (равно как и Shell-скрипты), а
ALL-CAPS куски кода на Обероне, приводившиеся в Философии, когда я её
ещё читал, нервировали.

Что-то как-то я совсем написал не в тему исходной ветки.

Posted via RSDN NNTP Server 2.0

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

VD>О том что ОКамл охринительный язык я понял когда пытаясь в нем разобраться не задал типы параметров и сделал какую-то ошибку. — моп твою ять — идумал я! — а вель еще говорят, что сообщения об ошибках в С++ запутаны!

Очень интересно, какую ошибку надо сделать, чтобы так подумать

Как правило, все сообщения об ошибках типизации в OCaml сводятся к
This expression has type ... but is here used with type ...

... << RSDN@Home 1.1.4 stable rev. 510>>

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

G>Битвы, во первых, нет. "Титаны" прекрасно друг друга понимают, и спорить не собираются.
Ну это я так, для красного словца, и дабы подчеркнуть уважение, т.е. ключевое слово — титаны, а не битва

.

G>Что же касается мета-макро-прочего — здесь у Немерле немного другой подход. По моим ощущениям, Camlp4 мощнее и гибче
Я, повторюсь, Немерле не видел. Просто мне различие уровня, на котором можно метапрограммировать в Немерле и в Camlp4, показалось существенным. Например, было бы неплохо, если бы в потоках не надо было отличать выражения-потоки и выражения-элементы синтаксически:

[<'elem1;stream1;'elem2;stream2>]

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Да вы шо?
Сделаем откровенную глупость:

#include <map>

using namespace std;

int main() {
    std::map<int, int> m;

    m.insert( std::make_pair(&m, &m) );
    return 0;
}

Получим:

g++ qqq.cpp
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_pair.h: In constructor `std::pair<_T1, _T2>::pair(const
 std::pair<_U1, _U2>&) [with _U1 = std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> > >*,
 _U2 = std::map<int, int, std::less<int>, std::allocator<std::pair<const int, int> > >*, _T1 = const int, _T2 = int]':
qqq.cpp:8:   instantiated from here
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_pair.h:90: error: invalid conversion from `std::map<int, int,
 std::less<int>, std::allocator<std::pair<const int, int> > >* const' to `int'
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_pair.h:90: error: invalid conversion from `std::map<int, int,
 std::less<int>, std::allocator<std::pair<const int, int> > >* const' to `int'

При этом любой плюс-плюсник, который не первый день с СТЛ, сразу найдет ошибку, т.к. знает, что из этого читать не надо.
В последней Visual Studio с этим значительно лучше, т.к. очень много усилий было затрачено на улучшение читабельности диагностики. Но вопрос принципиальный: в C++ шаблоны инстанцируются типами, типы могут рекурсивно вкладываться друг в друга, поэтому там запросто можно получить километровое имя типа (проблема то не в самом сообщении об ошибке, а в именах типов). В ML такое невозможно. Нужно только научиться читать типы функций и понимать, что такое currying.
Ну а в клинических случаях добавляешь аннотацию типа вручную, тогда скорее ткнут носом в проблемное место.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

VD>А ты думал я этот язык как идеал читабельности привел? Я просто показываю тебе, что минимализм синтаксиса не дает простоты. Это ошибочная предпосылка.
Язык должен быть легкочитаем, это понятно

VD>Простота это очень сложное комплексное понятие.
Это верно ! Но есть простые приближения к этой сложности

VD>Статистики нет. Но приблизительно могу сравнить. Работающую версию редактора кода с подсветкой синтаксиса я создал за месяц ненапряжного труда. В разы более ириметивную версию на С++ я создавал пол года. Конечно я стал более опытным, но и сейчас бы у меня ушло на это бы месяца 4 не менее. Правда и объем исходников существнно меньше получился. Но все же положительная динамика в скорости аписания есть.
Дык, я говорю не о скорости написания КОНЕЧНОГО ПРОДУКТА, а о скорости писания кода ! Вот в этом примере с редактором — ежели обьем кода на каждом языке разделить на время написания редактора на этом языке, не ролучатся ли близкие значения ?

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

VD>Оно огромно! Моя производительность снижается на порядок если я пишу в нотпэде.
VD>Я готов отказаться от более продвинутого языка если есть менее продвинутый, но с отличной поддежкой среды. Ведь среда может компенсировать многие проблемы и дать огромный выирыш.
Это весьма редкий случай, как мне кажется. Обычно люди не придают заметного значения наличию или отсутствию среды. Разве что для ваяния ГУЯ

VD>Простая арифметика. 4 < 20.

Ускорившись в 4 раза, я замедлюсь в 20. В тоге я все равно относительно замедлюсь. В бизнесе это называется упущенной выгодой. Ее може быть не заметно, но она есть.
А почему 20 ? Половина рабочего времени — это рабочий день / 2. То-есть будет общее ускорение в 4 / 2 раза.

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

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

VD>Огромное количество. Одни соглашения о названих CAR/CDR чего стоят? Ну, почему не H/T хотя бы? Я уже не говорю, о том, что более длинные head/tail хотя и длиннее, но реально намного бы повысили бы простоту чтения.
Ну, Лисп это еще не все языки

any(Pred, [H|T]) ->
    case Pred(H) of
        true  ->  true;
        false ->  any(Pred, T)
    end;
any(Pred, []) ->
    false.

Несколько более читаемо, правда ?

VD>Я придерживаюсь гипотизы, что для человека нет разницы между одно- двух-буквенными конструкциями и словами. Человек читает их какбудто распознает образы. Значимы обычно первая и последняя буква (поэтому в Лиспе так тяжело отличать CAR, CONS, CDR и т.п.).
Это близко к истине, на мой взгляд.

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

G>>Что же касается мета-макро-прочего — здесь у Немерле немного другой подход. По моим ощущениям, Camlp4 мощнее и гибче
PA>Я, повторюсь, Немерле не видел. Просто мне различие уровня, на котором можно метапрограммировать в Немерле и в Camlp4, показалось существенным. Например, было бы неплохо, если бы в потоках не надо было отличать выражения-потоки и выражения-элементы синтаксически:
PA>

PA>[<'elem1;stream1;'elem2;stream2>]
PA>

PA>Это можно сделать только при наличии информации о типах. В данном случае это мелочь, но могут быть случаи, когда это окажется серьезным препятствием.

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

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

Короче, они разные. В nemerle более гражданский, прикладной подход, а в OCaml — более системный, штоли.

Системы основанные на макросах (или чем-то подобным : макросы lisp и C ,C++ templates ,latex) обладают обшим недостатков — в некоторых случаях сообщения об ошибках очень невразумительные.

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

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

Q>>Берешь и вызываешь. Макросы ничем в этом смысле от функций не отличаются.
Q>>Лисп — это же не компилятор, а среда. Если в ней известны определенные функции на момент вызова макроса, то их можно вызвать.

VD>Это будет код макроса. А речь о внешних модулях. Хотя это конечно скорее разговор о поддежке компонентного подхода.

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

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

VK> Т.е. при наличие совместимой версии компилятора "макросы" можно распространять без исходного текста.

В CL — аналогично.

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

VD>Здравствуйте, Vermicious Knid, Вы писали:

VD>...

VD>Во-во. И я о том же. Вот и не ясно, почему Лиспы и Эрланги тут пиарятся как будто за них приплачивают. А о столь неординарной вещи практически тишина.

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

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

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

VD>Хм. Может все же прще глянуть на то о чем речь идет? В студии почти как ты говоришь и сделано. Есть специальное окно "Immediate". Вводишь в него строку, жмешь Ввод и получашь результат. Консоль чистой воды.

Да типа этого.

VD> Только переключаться никуда не надо. Окно можно закрепить где удобно.
:)

VD>Есть все же некоторая разница между Лиспом и языками с синтаксисом. К тому же попробуй "так" отлаживать нечто требовательное к производительности. При отладке дотнетного прилоежения замедление получается раза в 2-6 по сравненю с релизом без отладчика. А вот интерпретация да еще и интерактивная — это от 10 и выше. Не все так можно отлаживать.

Нет. В лиспе это вполне может быть компиляция, а интерпретация (В SBCL — так всегда, а в CMUCL — опционально). Лисповый процесс загружен в память и функции по мере написания копилируються и помещаються в памать процесса без перезапуска. Т.е. я могу написать функцию нажать Crtl-c Ctrl-c. И в окне комадной стркоки тут же провести пару тестов с этой функцией (и она уже будет откомпилена). Вообще у этого всего есть названи — инкриментальная компиляция.

Пример:
http://img506.imageshack.us/img506/6694/lastss2mk.png

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

VD>Больше потому что уровень интеграции другой. В Лиспе макросы — это препроцессор. А в Нэмерле — это плагины к компилятору.

VD>Дык в том, то все и дело, что в Нэмерле макрос может делать не только преобразования. Он еще может взаимодействовать с компилятором и использовать внешний, библиотечный код.

Если имеете ввиду лисп. То макрос тоже может использовать любой бибилотечный код, и вообще всё что угодно.
Вполне можно написать макрос который в момент компиляции обращаеться к астрологическому интернет ресурсу. И генерирует различный код взависимсости от фазы луны и положения марса относительно солнца:)

(defparameter *a-site* "astrology.org")

(defmacro defun-moon (name args  &body body)
  (let ((moon-phase (astrology:get-moon-phase *a-site*)))
    (case moon-phase
      (:full `(defun ,name ,args ....
           ))
      ....
      ....
      (:none `(progn
           (setf *dark* t)
           (print "moon defun does not work in new moon"))))))

(defun-moon blah (x y)
  .....)

Более релаьный прмер. Теоритически можно делать вообще так:

(def-ruby-func "
def x(a,b)
  c = 10 + a
  b * c
end
")

которая во время компиляции, используя вненший транслятор, преобразуеться в:

(defun x (a b)
  (let (c (+ 10 a))
        (* b c)))

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

VD>Огромное количество. Одни соглашения о названих CAR/CDR чего стоят? Ну, почему не H/T хотя бы? Я уже не говорю, о том, что более длинные head/tail хотя и длиннее, но реально намного бы повысили бы простоту чтения.

Есть синонимы first & rest. А Car cdr удобно, т.к. есть функции типа caddr аналогичные (car (cdr (cdr ...)).

On Thu, 02 Feb 2006 08:48:29 +0300, EXO <41956@users.rsdn.ru> wrote:

> VD>И что мешает развернуть тот же моно?
> То, что оно пока не продукт промышленного качества.
> Если доведут до ума, то возможно действительно будет интересным решением.
> Особенно если портиуют на не интеловское железо.

dotGNU бегает на разном железе, зато он еще менее промышленный, чем Mono

Его, собственно и создавали ,как во-первых быстрый легко потртируемый
интерпретатор, а уже потом JIT :D

> граница эта колеблется примерно в районе 10-15 гиг.

Вы же говорили про сотни гигов ?
на 10/15 вроде бегают бесплатные Firebird, Postgress, etc

--
Отправлено M2, революционной почтовой программой Opera:
http://www.opera.com/mail/

Posted via RSDN NNTP Server 2.0

VD>Думаю, что и большинству программистов нужен комплекс. Вопрос тольк в приоритетах.

так, я извиняюсь, на каком языке вы в конце концов остановились?

Здравствуйте, Arioch, Вы писали:
A>Вы же говорили про сотни гигов ?

Перечитайте внимательнее — речь про разное...

A>на 10/15 вроде бегают бесплатные Firebird, Postgress, etc

Они на бОльших размерах слишком тормозят.
А "универсальность SQL", без заточки на конкретную платформу, для больших задачь к сожалению миф...
То есть базу "на лету" в продукте не подменишь.
Да, в "нижнем сегменте" подошел бы POSTGRESS, в "верхнем" — MS SQL и ORACLE. Но ни то ни дугое, на всей линейке.
Мнезия воде бы необходимым масштабироывнием обладает:
— бесплатность и низкие требования к ресурсам на малых базах позволяет использовать ее в нижнем сегменте;
— по верхнему сегменту, известен пример проекта с базой примерно в 120 гиг (США, сеть казино. Мнезия стоит над BerkleyDB backend.)
Что касается работы на слабой технике (нижний сегмент), то тут нами уже все проверено. Как пойдут дела в верхнем сегменте будет ясно примерно через год. Пока видно только, что на базах порядка штук гиг она работает быстрее и MS SQL и Постгреса.
Правда следует признать, что оптимизатор запросов (в QLC) у нее более "тупой", чем у MS SQL и его чаще приходится "направлять пинками в нужную сторону". Больше всего напрягает пожалуй то, что QLC не использует статистику по таблице при выборе порядка использования индексов (хотя такая статистика есть).
На настоящий момент, мне представляется, что основное ограничение мнезии не по объему баз, а по количеству "плотно интегрированных" таблиц. Если архитектуру базы не удается разделить на достаточно обособленные блоки, не более чем по три десятка таблиц в каждом, то лучше взять какую-нибудь другую СУБД. Тогда как небольшом числе больших таблиц, мнезия вроде бы ведет себя весьма достойно.

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

EXO>Правда следует признать, что оптимизатор запросов (в QLC) у нее более "тупой", чем у MS SQL и его чаще приходится "направлять пинками в нужную сторону". Больше всего напрягает пожалуй то, что QLC не использует статистику по таблице при выборе порядка использования индексов (хотя такая статистика есть).

Так поправьте QLC, и научите его использовать статистику

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

G>Так поправьте QLC, и научите его использовать статистику

.

Смотрели, там не так все просто — правки надо начинать с mnesia:select...
Вобщем, все может быть, но это не та вещь, которая делается "с наскоку".
( Не "на коленке", как выражается Влад.)

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

G> Или биндинг к какому-нибудь симпатичному гую. Для GTK+, wxwindows и TCL уже есть...

Биндинг это фигня. EX11 идет верной дорогой.

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

Т>Биндинг это фигня. EX11 идет верной дорогой.
Вопрос в том, когда Армстронг допинает его до работоспособного состояния.
А GTKNode уже работает. Причем так же удаленно

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

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

PA>При этом любой плюс-плюсник, который не первый день с СТЛ, сразу найдет ошибку, т.к. знает, что из этого читать не надо.

А ты поробуй в итератор int-переменную подсунуть. Забавное, надо признать зрелище.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

_>Очень интересно, какую ошибку надо сделать, чтобы так подумать

_>Как правило, все сообщения об ошибках типизации в OCaml сводятся к
_>This expression has type ... but is here used with type ...

Реальная ошибка была черт знает где. А мен показывали совсем в другую степь.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

J>так, я извиняюсь, на каком языке вы в конце концов остановились?

Дык я еще не остановился.

Для рельных программ пока что использую C# 2.0.

Если же говорить о том что мне нравится, то скорее всего это Nemerle. В принципе мне так же понравилась Скала, но лично мне ближе рантайм дотнета, а Скала заточена на Яву.

Традиционные ФЯ меня как-то не очень вдахновляют. Но если бы заставили выбирать именно из них, то наверно я бы остановился на ОКамле. В прочем, сложность у него тоже явно избыточная. И синтаксис больно не привычен для меня.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

EXO>Да нет, сейчас на C#.

Каую-то ты фигню говоришь. Нельзя было писать на C# в VS6. Там был только VC++ 6. Ну, отдельным продуктом еще шел VB6.

EXO>Я хорошо помню, какое сопротивление яве было в сообществе. И как тогда старались рекламисты микрософт.

С очевидцами не спорят.

VD>>Если ты помнишь, то Яву талкали как средство создания аплетов, то есть как замену скриптам.

EXO>Очень недолго. Потом IBM громко закричал о северных задачах, а MS поддержал.

Ага. Чучуть. Года 4.

EXO>Кстати, посмотрел ANTLD. И обнаружил, что "знакомые все лица".
EXO>От своего предка — PCCTS он ушел не слишком далеко (а с последним я года полтора возился и глюки его знаю).

PCCTS это довольно древняя вещь. Ее автор на PCCTS дисер защитил. Потом правад, как я понил, в помоуйку пол дисера отправил. Сейчас отправляет оставшуюся часть переделывая АНТЛР на ДКА.

EXO>Так вот — наиболее критичный глюк основного алгоритма не исправлен.
EXO>Там токенайзер начинал вести себя странно, если требовалась глубина анализа больше 2.

Незнаю, не знаю. Для многих случаев он довольно большое К давал. А я так в Коке К = 1 использую и никаких проблем. Ну, а у АНТАЛР-а для шарпа обычно что-то полурукопашное использовалось.

EXO>То есть корректно компилировались только простые и очень однозначные грамматики.

Ну, да. Так и есть. Видимо по этому на сайте АНДЛР-а лежат только очень простые грамматики: С++, C#, Ява, SQL...

А главное, что лексер это такая сложная вещь! Что там какая-то грамматика для C# или C++?

VD>>А каково Эрлэнгу и его ранайму?

EXO>Нормально.
EXO>Вот у меня сейчас на разработческой тачке для отладки запущен сервер + мнезия (с базой около полугига) + вебсервер.
EXO>Суммарно в памяти занимают 30 мег. При этом кеши мнезии не урезаны. Можно уплющить мег до 12, проиграв по быстродействию где-то в четверо. Если учесть, что на микрописишках базы обычно только "аварийного хранения" (дня на 4 — если в праздники оборвется связь с центральным сервером). То вполне можно жить.

А, ну ясно. Для БД в 500 метров кэш 12 метров. Правильно, зачем зря память расходывать.

В общем, ты меня извини, но 12 метров для такой БД это сесть на винт. Ну, и 30 метров для машины с 64 метрами — это уже очень на мало. А ты ведь только одного пользователя подключил. Подключись к серверу 100 параллельных клиентов и сдохнет твоя 64-метровая машинка. А так, у меня тоже ничего не делающие экзешники много памяти не жрут при запуске. Но вот на рашем сервере кэш БД 1.5 гига, и веб-сервер жрет метров 300-500. Не думаю, что Эрлинг тут что-то иправил бы.

EXO>То, что оно пока не продукт промышленного качества.

Да? А Новел то незнает. Зарелизили 1.х совместимую версию.

EXO>Вопрос в самих этих объемах.
EXO>В Штатах — да, граница где "лицензия sql уже не тяготит" проходит где-то в районе 4 гиг. В России денег у предприятий поменьше будет (некоторые сектора типа нефте-газа я не считаю). И граница эта колеблется примерно в районе 10-15 гиг.

Что то я не понял этих вычислений лицензий в гигах.
А главное не понял, что же это за контора такая с 15 гигами информации и без денег? Видимо прийдется ей за 100 рублей диски покупать раз она в игрушки играется.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

A>Вы же говорили про сотни гигов ?
A>на 10/15 вроде бегают бесплатные Firebird, Postgress, etc

В раскорячку они бегают.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

EXO>Вот здесь похоже и есть точка непонимания.
EXO>У меня например, эта разница около 40%
EXO>Все остальные элементы спора — уже следствия.

Возможно. Остается узнать в какую сторону отличаются наш 1 раз.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

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

Прежде чем учить других чему-то неплохо удостовериться, что они этого не знают. Историю CAR/CDR я знаю не хуже тебя.

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

G>Дык, я говорю не о скорости написания КОНЕЧНОГО ПРОДУКТА, а о скорости писания кода ! Вот в этом примере с редактором — ежели обьем кода на каждом языке разделить на время написания редактора на этом языке, не ролучатся ли близкие значения ?

Нет не получатся. Дело в том, что даже одинаковый объем кода на шарпе пишется быстрее чем на плюсах. А уж меньший и подавно.

Простой пример. Чтобы реализовать интерфейс на С++ мне нужно вдолбить все его методы. При этом никакого комплита или помощи я не дождусь. Лучшее что я могу сделать — это отыскать определение интерфейса и скопипэстить его в класс реализующий этот интерфейс. Далее мне нужно вручную поправить все описания и только потом приступить к кодированию методов.

На C# сегодня я делаюс следующие действия:
1. Вбиваю буквы "cl".
2. Компличу слово "class" одним нажатием.
3. Жму таб. Получаю заготовку класса.
4. Вписываю " : " и начальные буквы интерфейса.
5. Компличу имя интерфейса.
6. Жму Ctrl+Alt+F10 и выбираю как я буду реализовывать интерфйс.
Все! Все методы описанне в интерфейсе но не реализованные в классе автоматически добавляются в класс. Причем мне уже не надо их править, так как они уже корректны.

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

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

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

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

Даже такая казалось бы банальная вещь как качественный кол-стрэк при рантайм-ошибке уже резко сокращает отладку.

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

G>А я говорю о том, что для каждого человека произодительность слабо меняется, хотя очень сильно меняется от человека к чкловеку.

Она меняется и от человека к человеку, и от языка и его среды. Ты же изначаль озвучил тезис, что программист вообще набивает энное количество кода не зависимо от языка. А это не так.

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

VD>>Я готов отказаться от более продвинутого языка если есть менее продвинутый, но с отличной поддежкой среды. Ведь среда может компенсировать многие проблемы и дать огромный выирыш.
G>Это весьма редкий случай, как мне кажется. Обычно люди не придают заметного значения наличию или отсутствию среды. Разве что для ваяния ГУЯ

Это "обычно" твое локальное частное мнение. Уверяю тебя, что ты уже в меньшинстве. И со временем крук людей которые так считают будет все уже (в процентном отношении по крайней мере).

VD>>Простая арифметика. 4 < 20.

Ускорившись в 4 раза, я замедлюсь в 20. В тоге я все равно относительно замедлюсь. В бизнесе это называется упущенной выгодой. Ее може быть не заметно, но она есть.
G>А почему 20 ? Половина рабочего времени — это рабочий день / 2. То-есть будет общее ускорение в 4 / 2 раза.

20 потому что я в 20 раз более продуктивен используя продвинутую IDE и заточенную под современный язык. Вот откуда ты взял половину рабочего времени?

VD>>И я с трудом их читаю. И еще миллионы людей. Так что это общие особенности. И уверен, что им есть вполен конкретное обяснение.
G>Но очень многие читают их без какого-либа напряга. И этому тоже должно быть обьяснение. Подозреваю, что это связано со зрением. Не остротой зрения, а чем-то другим.

Очень НЕ многие. Ты живешь в каком-то своем мире. Попробуй создать голосоание на этом сайте. Увидишь, что согласных с тобой не наберется и процента.

Просто сражаются в форумах еденицы вроде меня. Большинство людей или вообще не понимает, то о чем мы тут ведем беседу. Или понимает, но не может/не хочет принять.

Вот погляди на рекцию среднего мэйнстримщика на функциональный стиль Re: System.IO. Или вот Re: Nemerle рулит! :).

VD>>Огромное количество. Одни соглашения о названих CAR/CDR чего стоят? Ну, почему не H/T хотя бы? Я уже не говорю, о том, что более длинные head/tail хотя и длиннее, но реально намного бы повысили бы простоту чтения.
G>Ну, Лисп это еще не все языки

Несомненно не все. Но погляди как ревносно защищают апологеты Лиспа его бессмысленные CAR/CDR?!

G>

G>any(Pred, [H|T]) ->
G>    case Pred(H) of
G>        true  ->  true;
G>        false ->  any(Pred, T)
G>    end;
G>any(Pred, []) ->
G>    false.
G>

G>Несколько более читаемо, правда ?

Да, несомненно. Но тоже толкь после привчки. И еще прийдется объяснить, что значит H/T. Это для тебя очевидно, что это хвост и голова. А хля кого-то это HTML и TeX.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CP>Есть синонимы first & rest. А Car cdr удобно, т.к. есть функции типа caddr аналогичные (car (cdr (cdr ...)).

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CP>Если имеете ввиду лисп. То макрос тоже может использовать любой бибилотечный код, и вообще всё что угодно.
CP>Вполне можно написать макрос который в момент компиляции обращаеться к астрологическому интернет ресурсу. И генерирует различный код взависимсости от фазы луны и положения марса относительно солнца

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

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

def x = xml(<a><b/><a>)

то есть после xml( идет уже не Нэмерэловский код, а ХМЛ. И Нэмерел позволяет макрос xml() разобрать его как он хочет и вернуть AST соотвествющее инициализации графа объектов описывающего хтот ХМЛ.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

CP>Да немерле тоже очень хороший язык, просто пока менее применяемый — поэтому так.

Новый. Тут не поспоришь. Но все же он в той стадии когда с ним можно сравнивать.

CP> Только у него есть один большой недостаток и одновременно большое достоинство — он под .NET.

Ну, да. Кому как.

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

PA>Я, повторюсь, Немерле не видел. Просто мне различие уровня, на котором можно метапрограммировать в Немерле и в Camlp4, показалось существенным. Например, было бы неплохо, если бы в потоках не надо было отличать выражения-потоки и выражения-элементы синтаксически:
PA>

PA>[<'elem1;stream1;'elem2;stream2>]
PA>

PA>Это можно сделать только при наличии информации о типах. В данном случае это мелочь, но могут быть случаи, когда это окажется серьезным препятствием.

Именно так. Ниже я привел пример реализации C#-ного foreach-а на макросах немерла. Это код не из примеров которые конечно просые и даже работают но не дают такого же качества как контрукция встроенная в язык. А этот макрос проводит кучу дополнительного анализа и выдает тучу диагностики если что. При этом он строит код в зависимости от типа леального выражения. В общем, надесь, он понятен и тем кто не знает Нэмерел:

/**
 * The 'foreach' macro introduces a construction equivalent
 * to C#'s 'foreach' keyword, iterating over a collection.
 */
macro @foreach (inexpr, body)
syntax ("foreach", "(", inexpr, ")", body)
{
    match (ListComprehensionHelper.ExpandRange (inexpr, body)) {
        | Some (expr) => Nemerle.Imperative.Return (expr)
        | None => {}
    }

    def (iter, collection) =
        match (inexpr) {
            | <[ $i in $c ]> => (i, c)
            | e =>
                Message.FatalError ($ "the syntax is 'foreach (x in collection)', "
                                                            "got $e");
        }
        
    def typer = Macros.ImplicitCTX ();
    def tcollection = typer.TypeExpr (collection);

    // build the body of loop (may contain additional matching)
    def build_definition (val) {
        match (body) {
            | <[ match ($(null)) { ..$cases } ]> =>
                match (iter) {
                    | <[ $(x : name) ]> when char.IsLower (x.Id[0]) | <[ (..$_) ]> => ()
                    | _ => Message.FatalError ("only simple names available in pattern"
                                                                         " of foreach with direct matching")
                }

                <[ def $iter = $val; 
                     match ($iter) { ..$cases } 
                ]>

            | _ =>
                def mat =
                    match (iter) {
                        | <[ $pat :> $ty ]> =>
                            <[ match ($val :> $ty) { | $pat => $body; () | _ => () } ]>
                        | _ =>
                            <[ match ($val) { | $iter => $body; () | _ => () } ]>  
                    }
                mat.cases.Iter (fun (x : PT.MatchCase) { x.disable_warnings = true });
                mat
        }
    }

  // here we choose if we want to use enumerator pattern
  // of access GetEnumerator through IEnumarable
  // http://www.jaggersoft.com/csharp_standard/15.8.4.htm
  def decide_enumerator_pattern (tyinfo) {
    def all = tyinfo.LookupMember ("GetEnumerator");
    
    def choosen = List.Exists (all, fun (mem : IMember) {
      | meth is IMethod when !meth.IsStatic && meth.GetParameters ().IsEmpty =>
        match (meth.ReturnType) {
          // FIXME: do additional conservative checks              
          | MType.Class (tc, _) when
            !tc.LookupMember ("MoveNext").IsEmpty &&
            !tc.LookupMember ("Current").IsEmpty => true
            
          | _ => false
        }
      | _ => false
    });
    if (choosen)
      <[ $(tcollection : typed).GetEnumerator () ]>
    else
      <[ ($(tcollection : typed) : System.Collections.IEnumerable).GetEnumerator () ]>
  }

  typer.DelayMacro (fun (fail_loudly) {
    match (tcollection.Type.Hint) {
      | Some (MType.Class (tc, args)) =>
        if (tc.SuperType (InternalType.Nemerle_list_tc).IsSome) {
          def arg = List.Head (args);
          def definition = build_definition (<[ x ]>);
          Some (<[
            // we explicitly set parameter type to list, because collection's type
            // can be more specific (list.Cons, etc.)
            ($(PT.Name.Global ("_N_break") : name) : {
              def foreach_loop (_ : list [$(arg : typed)]) {
                | x :: xs =>
                  $(PT.Name.Global ("_N_continue") : name) : {
                    $definition;
                  }
                  foreach_loop (xs)
                | _ => ()
              }
              foreach_loop ($(tcollection : typed))
            })
          ]>)
        }
        else {
          def init_body = decide_enumerator_pattern (tc);

          def is_disposable = 
            typer.JustTry (fun () {
              def expr = typer.TypeExpr (init_body);
              expr.Type.Require (<[ ttype: System.IDisposable ]>)
            });

          def finally_body = 
            if (is_disposable)
              <[ (enumerator : System.IDisposable).Dispose () ]>
            else
              <[
                match (enumerator) {
                  | x is System.IDisposable => x.Dispose ();
                  | _ => ()
                }
              ]>;

          def definition = build_definition (<[ enumerator.Current ]>);

          Some (<[ 
            def enumerator = $init_body;
            $(PT.Name.Global ("_N_break") : name) : {
              def loop () {
                when (enumerator.MoveNext ()) {
                  $(PT.Name.Global ("_N_continue") : name) : {
                    $definition;
                  }
                  loop ();
                }
              }
              try { loop () } 
              finally { $finally_body }
            }
          ]>)
        }

      | Some (MType.Array (_ , rank)) =>
        def indices  = array (rank);
        def lengths = array (rank);
        for (mutable i = 0; i < rank; ++i) {
          indices [i] = Macros.NewSymbol ();
          lengths [i] = Macros.NewSymbol ();
        }
        def indices_list = List.RevMap (List.FromArray (indices), fun (x) {
            <[ $(x : name) ]> 
        });
        def build_loops (depth)  {
          /// build expression defining iteration symbols
          | 0 => build_definition ( <[ cached_collection [..$indices_list] ]> )
          | n => 
            def idx = indices [n - 1];
            <[ for (mutable $(idx : name) = 0; 
                    $(idx : name) < $(lengths [n - 1] : name);
                    ++ $(idx : name) ) 
                 $(build_loops (n - 1)) 
            ]>
        }
        mutable sequence = [ <[ $(build_loops (rank)) ]> ];
        if (rank == 1) 
          sequence = <[ def $(lengths [0] : name) = cached_collection.Length ]> :: sequence;
        else
          for (mutable i = rank - 1; i >= 0; --i)
            sequence = <[ def $(lengths [(rank - 1) - i] : name) = cached_collection.GetLength ($(i : int)) ]>
                       :: sequence;

        sequence = <[ def cached_collection = $(tcollection : typed) ]> :: sequence;
        Some (<[ { .. $sequence } ]>)

      | t =>
        when (fail_loudly) {
          def guess =
            match (t) {
              | Some (t) => $ "current best guess about the type is $t"
              | None => "the compiler has no idea what the type might be"
            }
          Message.Error ($ "collection in foreach must be an array or "
                           "type implementing enumerator pattern, $guess");
          Message.Hint ("try specifing the type directly using 'expr : SomeType'");
        }
        None ()
    }
  })
}

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

VD>Нет не получатся. Дело в том, что даже одинаковый объем кода на шарпе пишется быстрее чем на плюсах. А уж меньший и подавно.
Одинаковый по количеству строк ? Или все же одинаковый по функциональности обьем ?

VD>Точно так же на менее многословном языке реально я буду вынужден надолбить куда бльше текста, чем на Шарпе, но с поддержкой IDE.
А если тебе надо сделать то, для чего нет визардов в среде ? Придется ведь просто топтать клаву, как и делают ретрограды вроде меня ! 8))

VD>Ну, и главное в "надалбывании" кода. При процессе надалбывания основное время тратится на то, чтобы вспомнить какие методы нужно вызвать, их сингнатуру и т.п. Конечно хорошо, что интерпетаторы позволяю быстро поправиться, но лучше если я просто буду вводить сразу нужный мне код. Комплит как раз предоставляет списки метовов/свойств и их краткое описание. В дополнении среда еще позволяет быстро найти хэлп по нужной функции (ведь она знает, что это за функия!).
Навигатор по TAGS и хэлп у меня подцеплен к ФАРу, так что тут разница небольшая

VD>Ускоряют процесс оздания ПО и визуальные дизайнеры, вроде дизайнера классов и дизайнера форм/веб-фарм/компонентов. Например, мне не надо разбираться с тем, что за свойства нужно задать диалогу отрытия файлов. Я просто брошу соотвествующий компонет куда надо и настрою его свойства визуально.
Вот уж что меня мало заботит ! ГУЙ делают другие люди. На чем они его делают, меня не волнует, лишь бы они соблюдали протокол обмена.

VD>К тому же не надо забывать, что скорость разработки в большинстве случаев не упирается в скорость долбления кода. Он упирается такие факторы как простота отладки, простота модификации кода, простота серьезного рефаторинга. Если язык статически типзирован и имется хорошая среда, то рефакторино проходит очень просто и не вызвает серьезных проблем. Типобезопасность и хрооший отладчик обеспечивает поскую отладку (а зачастую типобезопасность в вообще избавляют от необходимости отладки).
Я не верю в приличный АВТОМАТИЧЕСКИЙ рефакторинг. Ручной и тот чаще всего бывает довольно бессмысленным

VD>Даже такая казалось бы банальная вещь как качественный кол-стрэк при рантайм-ошибке уже резко сокращает отладку.
Именно ! В языках, которые я использую чаще всего, это есть

VD>Это мнение родилось у, извинясь за выражение, старперов которые никогда не видели современной среды разработки. Они привыкли, что все нудно долбить руками, средств контроля почти нет, а отладчик имеет такое качесвто, что лучше бы его не было. Да, при таком расскладе наверно они правы. Но им бы вылезти из своего локального каменного века. Тогда бы они узнали, что люди живут по другому. Ну, по крайней мере многие из них.
Ну, как бы это так сказать...Представление о современной среде разработки у всех разное. ОЧЕНЬ многие используют Емакс — и счастливы, поскольку там есть все. Другие используют АНЖУТУ и ее клоны — и тоже довольны. Говорят, есть люди, которые используют Вижуал Студию,... 8)

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

VD>20 потому что я в 20 раз более продуктивен используя продвинутую IDE и заточенную под современный язык. Вот откуда ты взял половину рабочего времени?
Про половину ты писал : "полдня переключаются между консолями". А вот откуда ускорение в 20 раз за счет ИДЕ ? В десятки процентов я еще могу поверить, и то сильно напрягшись.

VD>Просто сражаются в форумах еденицы вроде меня. Большинство людей или вообще не понимает, то о чем мы тут ведем беседу. Или понимает, но не может/не хочет принять.
Нууу...Тут нужна статистика. Без нее сложно что-то утверждать/возражать.

G>>

G>>any(Pred, [H|T]) ->
G>>    case Pred(H) of
G>>        true  ->  true;
G>>        false ->  any(Pred, T)
G>>    end;
G>>any(Pred, []) ->
G>>    false.
G>>

VD>Да, несомненно. Но тоже толкь после привчки. И еще прийдется объяснить, что значит H/T. Это для тебя очевидно, что это хвост и голова. А хля кого-то это HTML и TeX.

Все, что с большой буквы — переменные. С маленькой атомы ( в том числе и имена функций )
Если бы было написано Head/Tail, было бы сильно лучше ?

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

EXO>>Да нет, сейчас на C#.
VD>Каую-то ты фигню говоришь. Нельзя было писать на C# в VS6.

Сообщением выше было сказано, что ребята перешли с VC6 на VC2005.
Я пишу, что сейчас они работают на C#. То есть сменили язык.
То, что под VC2005 есть C# для тебя ведь не секрет...

EXO>>Нормально.
EXO>>Вот у меня сейчас на разработческой тачке для отладки запущен сервер + мнезия (с базой около полугига) + вебсервер.
EXO>>Суммарно в памяти занимают 30 мег. При этом кеши мнезии не урезаны. Можно уплющить мег до 12, проиграв по быстродействию где-то в четверо. Если учесть, что на микрописишках базы обычно только "аварийного хранения" (дня на 4 — если в праздники оборвется связь с центральным сервером). То вполне можно жить.
VD>А, ну ясно. Для БД в 500 метров кэш 12 метров. Правильно, зачем зря память расходывать.

VD>В общем, ты меня извини, но 12 метров для такой БД это сесть на винт.

В квотинге написано "для отладки". Я где-то писал, что для полугиговой базы это "рабочий режим"?
Нет. Посто указал, что такое возможно.
Про то, что на микописишных устройствах полугиговые базы тоже речи небыло — не домысливай.

VD>Ну, и 30 метров для машины с 64 метрами — это уже очень на мало.

Разумеется. Ограничиваем напимер 15-ю. На базе порядка 100 мег будет вполне нормально работать.

VD> А ты ведь только одного пользователя подключил. Подключись к серверу 100 параллельных клиентов и сдохнет твоя 64-метровая машинка.

Во-первых, рост памяти на нового клиента у мнезии весьма мал, а во-вторых на микрописишных "сервеах опроса" не бывает сотини паралельных клиентов. Их опрашивают только сервера верхнего уровня.

VD> Но вот на рашем сервере кэш БД 1.5 гига, и веб-сервер жрет метров 300-500. Не думаю, что Эрлинг тут что-то иправил бы.

Ну и что? Это как раз нормальная ситуация масштабирования. Большая нагрузка — мощная машина, малая нагрузка — минимум ресурсов. Мнезии я тоже могу полтора гига под кеши отдать, если потребуется.

VD>А главное не понял, что же это за контора такая с 15 гигами информации и без денег?

"Страшно далеки они от народа..."

EXO,

EXO>Влад, диалог честное слово становится откровенно скучным.

Тогда делай как мы: расслабься и прекрати диалог

. Оставить реплику (особенно неконструктивную) безответной намного легче, чем тебе кажется. Нежелание спорить не есть признак слабости или некомпетентности.

Всё проще.

Be cool, stay in school! (c) Magnolia

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

G>Одинаковый по количеству строк ? Или все же одинаковый по функциональности обьем ?
По количеству строк. По функциональности вообще не обсуждается.

G>А если тебе надо сделать то, для чего нет визардов в среде ?

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

G> Придется ведь просто топтать клаву, как и делают ретрограды вроде меня ! 8))

Как показывает практика "топтать" получается в среднем раз в 10 меньше.

G>Навигатор по TAGS и хэлп у меня подцеплен к ФАРу, так что тут разница небольшая

Нашел с чем сравнивать. Нехочу устраивать еще один vs. но тут Фар просто полный 0. Если бы он давал хоть грам приемуществ, то я бы его использовал. А так я его уже лет 5 не открывал.

G>Вот уж что меня мало заботит ! ГУЙ делают другие люди. На чем они его делают, меня не волнует, лишь бы они соблюдали протокол обмена.

Пока его создавать не нужно. А припечет — забеспокоит.

G>Я не верю в приличный АВТОМАТИЧЕСКИЙ рефакторинг. Ручной и тот чаще всего бывает довольно бессмысленным

Это не предмет веры. Это просто ставится, осваиваетя и используется.

VD>>Даже такая казалось бы банальная вещь как качественный кол-стрэк при рантайм-ошибке уже резко сокращает отладку.
G>Именно ! В языках, которые я использую чаще всего, это есть

Думаю, что скорее всего он значительно хуже. Но даже если это и не так, то один кол-стэк погоды не делает. Погоду делает сочетание технологий. Вот в том же Нэмерле кол-стэк такой же как в C#. Но вот с отладчиком проблемы. Среда не интегрирована по человечески. Рефакторинга нет. Комплита... Ко всему я еше не очень хорошо его знаю и путаюсь в мелочах которые легко бы разрешились хотя бы комплитом. В итоге получаетя, что на Шарпе я пишу почти так же быстрок как по русски, а на Нэмерле вожусь с парой строк. И это еще я хоть Сцинтилу прикрутил. А из командной строки это вообще мрак было.

G>Ну, как бы это так сказать...Представление о современной среде разработки у всех разное.

Ага. Особенно у тех кто их не видел.

G> ОЧЕНЬ многие используют Емакс — и счастливы, поскольку там есть все. Другие используют АНЖУТУ и ее клоны — и тоже довольны. Говорят, есть люди, которые используют Вижуал Студию,... 8)

Ага. А очень многие Фар и тоже считют его очень приличным средством разработки.

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

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

G>Про половину ты писал : "полдня переключаются между консолями".

Гы. Мне то не надо переклюаться.

G>А вот откуда ускорение в 20 раз за счет ИДЕ ? В десятки процентов я еще могу поверить, и то сильно напрягшись.

Из опыта. Я тоже как бы без проблем могу помучаться в консоли. И скриптик написать если что. Но вот открывая настроенную под меня ИДЕ я получаю несравнимые премущества.

G>Все, что с большой буквы — переменные.

Тоже не очевидно.

G> С маленькой атомы ( в том числе и имена функций )

Это тоже прийдется человеку объяснять черт знает сколько времени.

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

G>Если бы было написано Head/Tail, было бы сильно лучше ?

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

... << RSDN@Home 1.2.0 alpha rev. 637>>

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

LCR>Тогда делай как мы: расслабься и прекрати диалог

. Оставить реплику (особенно неконструктивную) безответной намного легче, чем тебе кажется. Нежелание спорить не есть признак слабости или некомпетентности.

Я знаю.

Просто Влад мне во многом симпатичен. Потому это скорее намек ему...

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

VD>Упоминай не упоминай, но в нашей стране он на них и как видишь миллионов 50 пользуются результатом и более чем довольны.
вроде как у МТС раньше все было на жабе с ораклом, а сейчас для ДжинсЫ они переписали на Шарпе с MS SQL... результат — "на лице".. Те, кто на новом биллинге сидит (*100# вместо *102#) получают ответы намного быстрее — десятые секунды вместо 5-15 после 5 ошибок занятости сети у меня и ответы у них точнее (деньги списаны через секунду после разговора, а не через полчаса как у меня).
P.S. я на старом биллинге пока вынужден сидеть — еще не всех перетащили...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

G>>Я не верю в приличный АВТОМАТИЧЕСКИЙ рефакторинг. Ручной и тот чаще всего бывает довольно бессмысленным
VD>Это не предмет веры. Это просто ставится, осваиваетя и используется.
А для каковых языков ? Почему-то у меня такое ощущение, что только для Сшарпа, из-за заточенности самого языка на это, как утверждают знающие люди

VD>Ага. А очень многие Фар и тоже считют его очень приличным средством разработки.
И они тоже правы !

VD>Возможно, что круг твоих знакомых очень специфичен. И возможно менно из-за этого у тебя сложились такие стериотипы. Но уверяю тебя круг твоих знакомых и вообще похожих на них программистов не составляет сколь нибудь значимого процента от общего числа программистов.
Что может быть в них специфичного ? Кто-то пишет под Вынь, кто-то под линукс, кто-то под QNX и соляру. Кто-то делает финансовые системы, кто-то АСУшные задачи и пр.

G>>А вот откуда ускорение в 20 раз за счет ИДЕ ? В десятки процентов я еще могу поверить, и то сильно напрягшись.
VD>Из опыта. Я тоже как бы без проблем могу помучаться в консоли. И скриптик написать если что. Но вот открывая настроенную под меня ИДЕ я получаю несравнимые премущества.
Дык, может быть, это не преимущество ИДЕ над консолью, а индивидуальные проблемы без ИДЕ ?

VD>Я вообще поражюсь сколько в ФЯ ненужных и запутывающих концепций. Когда разберешся, вроде бы все понятно. Но все тоже самое можно ведь иметь без разжевывания.

Это не концепция, а соглашение об именах, не более того. Оное соглашение есть во всех языках.

G>>Если бы было написано Head/Tail, было бы сильно лучше ?
VD>Несравненно! Очень мнокие возможно поняли бы программу без многочасовых объяснений. Меня вообще радует когда функциональшики восхищаются птичим языком реально представляющим из себя набором однобуквенных идентификаторов.

Ну, в примере просто не было ни одного вызова стандартных функций. Вот к примеру :
dict:fetch, lists:keysort,calendar:local_time,ets:match,lists:map и т.д.
А вот другой пример

run_mz_loop()->
    receive
        stop->
            mz_kernel:stop();

        {kernel_request,Pid,Arg}->
            Answ=case Arg of
                [Func,Args,Ctx]->catch proceed_req(Func,Args,Ctx);
                _->nil
            end,
            Pid ! {kernel_answer,Answ},
            run_mz_loop();
            
        X->
            ?FLOG("unknown message : ~p",[X]),
            run_mz_loop()
    end.

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

VladD2,

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

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

Про религию.

( h4 рулит

)

Имеем Лисп. Обычный язык. Который тем не менее влияет на способ "думанья".
Имеем людей, которые работают на Лиспе. Просто люди. Их объединяет этот способ "думанья". Они формируют культуру. Суммарный опыт этих людей порождает традиции (как надо и как не надо использовать Лисп), и соглашения. Соглашения позволяют людям избавляться от передачи избыточной информации, поэтому их наличие важно.

Естественно, люди, непричастные к этой культуре (обозначим их O — others) часто не понимают людей причастных к этой культуре (L — lispers).

L говорят какие-то вещи, которые выглядят для O как чепуха. В то же время для L эти утверждения — продукт суммарного опыта и чепухой не являются.

Разумеется некоторые L тоже могут сказать чепуху. И такие утверждения для O тоже будут выглядеть как чепуха.

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

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

Нет никакой религии.

PS1: Я тут акцентировал на Лиспе, но очевидно вышесказанное обобщается на произвольную культуру.

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

VD>Кстати, лисповские макросы могут разбирать входяший текст. Например, в Нэмерле допустим о следущее расширение:
VD>

VD>def x = xml(<a><b/><a>)
VD>

VD>то есть после xml( идет уже не Нэмерэловский код, а ХМЛ. И Нэмерел позволяет макрос xml() разобрать его как он хочет и вернуть AST соотвествющее инициализации графа объектов описывающего хтот ХМЛ.

Такое тоже сделать можно. Только это будет не обычные макросы, a так называемые reader macros. Они расширяют стандартный алгоритм лексера и парсера.

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

EXO>Здравствуйте, Lazy Cjow Rhrr, Вы писали:

LCR>>Тогда делай как мы: расслабься и прекрати диалог

. Оставить реплику (особенно неконструктивную) безответной намного легче, чем тебе кажется. Нежелание спорить не есть признак слабости или некомпетентности.

EXO>Я знаю.

EXO>Просто Влад мне во многом симпатичен. Потому это скорее намек ему...

Анекдот что-то вдруг вспомнился, про Ржевского

. Кончается он очень поучительно:

...
— Поручик, пойдемте **ся.
— Хм, намек понял!

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

VD>На C# сегодня я делаюс следующие действия:
VD>1. Вбиваю буквы "cl".
VD>2. Компличу слово "class" одним нажатием.
VD>3. Жму таб. Получаю заготовку класса.
VD>4. Вписываю " : " и начальные буквы интерфейса.
VD>5. Компличу имя интерфейса.
VD>6. Жму Ctrl+Alt+F10 и выбираю как я буду реализовывать интерфйс.
VD>Все! Все методы описанне в интерфейсе но не реализованные в классе автоматически добавляются в класс. Причем мне уже не надо их править, так как они уже корректны.

Не удивил. В емаксе есть подобных кодогенирирующих и автодополняющих вещей куча. ТОлкько встроенные механизмы типа abbrev, tempo, skel. + элементарно запустить внешний скрипт, который тут же расширит нужную заготорвку до небходимого скелета. Конечно не для всех языков такие вещи есть out-of-box, для некоторых языков нужно будет поисктать решения в инете, для некоторых (особенно для своих) написать самому — но это пишеться за 20 минут — несколько часов на elisp + [perl/python/ruby], в зависимости от количества фич. И заметь есть для куууучи языков, а не только для C#/Java/VB. В том числе, уверен, и для немерле есть. Хотя возмжоно некоторые особые "интелектуальные" вещи будет посложнее написать... Вообще я последнее время очень часто пользуюсь различной кодогенерацией в "плоских" языках без хорошей макросистемы. Ведь зачем писать 10000 строк когда можно написать 500 + 200 генератора и получить то-же результат, но для это конечно нужно хорошо соображать, с чем у меня не всегда всё в порядке:)

VD>Ну, и главное в "надалбывании" кода. При процессе надалбывания основное время тратится на то, чтобы вспомнить какие методы нужно вызвать, их сингнатуру и т.п. Конечно хорошо, что интерпетаторы позволяю быстро поправиться, но лучше если я просто буду вводить сразу нужный мне код. Комплит как раз предоставляет списки метовов/свойств и их краткое описание. В дополнении среда еще позволяет быстро найти хэлп по нужной функции (ведь она знает, что это за функия!).

Тоже не удивил.

VD>Несомненно не все. Но погляди как ревносно защищают апологеты Лиспа его бессмысленные CAR/CDR?!

Я например не защищаю. Всегда пользуюсь first/rest. Только в оочень редких случая, когда имеем дело с вложенными списками пользуюсь функциями типа caadr.

	От:	pavel74
	Дата:	22.01.06 15:10
	Оценка:

	От:	Аноним
	Дата:	22.01.06 16:08
	Оценка:

От:	Mamut	http://dmitriid.com
Дата:	22.01.06 17:04
Оценка:	5 (1) +1

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	23.01.06 05:27
Оценка:	11 (2)

От:	Mamut	http://dmitriid.com
Дата:	23.01.06 07:55
Оценка:

От:	VladD2	www.nemerle.org
Дата:	25.01.06 03:46
Оценка:

От:	Gaperton	http://gaperton.livejournal.com
Дата:	25.01.06 12:37
Оценка:

	От:	Programmierer AG
	Дата:	25.01.06 16:15
	Оценка:	+1

От:	EXO	http://www.az.inural.ru
Дата:	26.01.06 04:58
Оценка:	+1

	От:	gandalfgrey
	Дата:	26.01.06 12:02
	Оценка:	10 (2)

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	28.01.06 12:56
Оценка:	1 (1) +1

От:	Курилка	http://kirya.narod.ru/
Дата:	30.01.06 10:01
Оценка:

	От:	А почему вы спрашиваете
	Дата:	30.01.06 20:54
	Оценка:

От:	potan	http://wtk.norilsk.net/pm/
Дата:	31.01.06 15:02
Оценка:

	От:	Vermicious Knid
	Дата:	31.01.06 17:09
	Оценка:	71 (9) +1

	От:	the_void
	Дата:	02.02.06 08:10
	Оценка:	1 (1) +2

	От:	little_alex
	Дата:	02.02.06 09:41
	Оценка:	5 (1) +2

От:	johny5	https://www.facebook.com/TachyonWars/
Дата:	03.02.06 02:21
Оценка:

	От:	Трурль
	Дата:	03.02.06 14:39
	Оценка:	4 (1)