Здравствуйте, WolfHound, Вы писали:
WH>Просто если уж начал писать на функциональном языке так пиши в функциональном стиле. WH>И заметь ни одной изменяемой переменной не вобще.
Здравствуйте, WolfHound, Вы писали:
WH>Ибо я могу взять рантайм и посмотреть как он работает. Так вот руби тормозит ужасно.
А ты знаешь систему, в которой есть такая же степень динамизма, но не такие тормоза?
Которая, к примеру, открытые классы поддерживала бы?
E>>Сильно сомневаюсь, что для статики можно загрузить по живому новую версию класса, например, с изменившейся таблицей виртуальных функций и изменившимися прототипами методов. WH>Это смотря как ее компилировать... если как С++ то конечно ничего не выдет.
Предложи вариант, как компилировать. Может как в Java или C#?
WH>Надеюсь ты не про это WH>
WH>auto test = new Testing(1, 2, 3);
WH>
WH> WH>Так вот по сравнению с неммерле это вобще ерунда.
Нет, не про это. Посмотри, скажем на исходный пример с CurryAll.
E>>А то, что D такой долгострой, так это вообще лично мне не понятно. Видимо, Брайт считает, что спешить особо не нужно. D нацелен на нишу C++, вытеснить оттуда C++ полностью вообще не получится, а вот отвоевать свое место вполне возможно. WH>На кой черт этот мутант там вобще нужен? WH>Если нужно выжимать биты из быйтов то нужен либо обыкновенный С/С++ либо совершенно иная нежели CLR и JavaVM виртуальная машина.
Да уж, виртуальная машина, чтобы биты выжимать. Круто.
Ты вот сейчас на C++ для Linux и AIX (если я ничего не перепутал) пишешь. В связи с этим два вопроса:
1) помешало бы тебе, чтобы вместо C++ там был гораздо более предсказуемый и стройный D, который и компилируется к тому же в сотни раз быстрее, чем C++? Чем хуже сегодня выжимать максимум из железа на D, а не на C++ (давай не будем брать библиотеки, просто основные качества языка)?
2) почему же ты не используешь Nemerle? Он что, биты хуже выжимает?
E>>Но для этого требуется время. Какие-то вещи в D (тот же самый вывод типов, теперь вот туплы) появляются с течением времени, что делает язык лучше. В общем, обычный процесс эволюции. WH>Тоже самое будет в следующем стандарте С++.
Есть у меня подозрения, что будущий стандарт C++ будет меня интересовать постольку, поскольку. К тому же у D есть все шансы предоставить такие же возможности, но на пару лет раньше.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, FR, Вы писали:
WH>>Просто если уж начал писать на функциональном языке так пиши в функциональном стиле. WH>>И заметь ни одной изменяемой переменной не вобще. FR>http://rsdn.ru/forum/Message.aspx?mid=2220435&only=1
Здравствуйте, FR, Вы писали:
WH>>В немерле совершенно иной вывод типов не имеющий ничего общего в ML. FR>Точно ничего общего не имеющий?
Ну начнем с того что в немерле принципиально иная система типов...
FR>И почему сразу вывод типов, а паттерн матчинг там откуда?
WH>А D? К тому же опять сколько времени делают немерле и сколько D? Я вот про D узнал за несколько лет до того как первый раз услышал про немерле. И еще учти что немерле горазо технологичнее чем D (один вывод типов чего стоит), а технологии требуют исследований. В тоже время в D нет вобще ничего скольнибудь не тривиального.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>А ты знаешь систему, в которой есть такая же степень динамизма, но не такие тормоза? E>Которая, к примеру, открытые классы поддерживала бы?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, FR, Вы писали:
WH>>>В немерле совершенно иной вывод типов не имеющий ничего общего в ML. FR>>Точно ничего общего не имеющий? WH>Ну начнем с того что в немерле принципиально иная система типов...
Да расширена, но основа то была, не на пустом месте делали.
FR>>И почему сразу вывод типов, а паттерн матчинг там откуда? WH>
WH>>А D? К тому же опять сколько времени делают немерле и сколько D? Я вот про D узнал за несколько лет до того как первый раз услышал про немерле. И еще учти что немерле горазо технологичнее чем D (один вывод типов чего стоит), а технологии требуют исследований. В тоже время в D нет вобще ничего скольнибудь не тривиального.
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, FR, Вы писали:
WH>>>Просто если уж начал писать на функциональном языке так пиши в функциональном стиле. WH>>>И заметь ни одной изменяемой переменной не вобще. FR>>http://rsdn.ru/forum/Message.aspx?mid=2220435&only=1
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, WolfHound, Вы писали:
WH>>Ибо я могу взять рантайм и посмотреть как он работает. Так вот руби тормозит ужасно.
E>А ты знаешь систему, в которой есть такая же степень динамизма, но не такие тормоза? E>Которая, к примеру, открытые классы поддерживала бы?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
E>>А ты знаешь систему, в которой есть такая же степень динамизма, но не такие тормоза? E>>Которая, к примеру, открытые классы поддерживала бы?
ANS>Э-э-э. Ну этот, ну ты понял.
So I was curious just how much better those mythical Smalltalk VMs did at array indexing, and ran some quick benchmarks. In all cases what I was measuring was the time it took to do one billion accesses of a 1000 element array of integers in the 0..255 range, discounting loop overhead and startup time. This is on my MacBook Pro; Ruby, Squeak and Java are running natively, Strongtalk is in Windows inside Parallels so probably slightly penalized. Here's what I got; for some reason the top three fall neatly into a 10x progression.
Java: 0.7s
Strongtalk Smalltalk: 7.0s
Squeak Smalltalk: 70s
Ruby: 200s
Java is definitely the winner, which shouldn't be that surprising given that it has a primitive char type whereas everyone else is working with tagged integers. The other three are a "fair" comparison, in that the languages are all equally dynamic, open classes, objects all the way down, yadda yadda. Except that it's not fair, because the Strongtalk VM just cleans the floor with the other two. And (as I always feel compelled to point out) Ruby could run on this VM with 0 performance penalty, completely unlike JRuby, Ruby.NET, and so on.
So, Tim, want RX to run 30x faster? Let's get Ruby running on Strongtalk.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
WolfHound wrote: > E>Тем более, что Nemerle -- это только .NET, в отличии от D. Т.к. они > вообще в разных песочницах расти будут. > А что у D в плане переносимости есть какието преймущества перед Mono?
Да. Для D есть GCC frontend, так что (в теории) D будет работать почти
на всех платформах, где есть GCC.
> В любом случае сделать рантайм немерле не завязанный на .NET вполне > возможно.
Ага, конечно.
When comparing with nested functions, the function form is analogous to static or non-nested functions, and the delegate form is analogous to non-static nested functions. In other words, [b]a delegate literal can access stack variables in its enclosing function[/url], a function literal cannot.
Хотя про замыкания действительно не помню, может это бага?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>А ты знаешь систему, в которой есть такая же степень динамизма, но не такие тормоза? E>Которая, к примеру, открытые классы поддерживала бы?
Меня такие системы не интерисуют ибо тормоза по определению.
WH>>Это смотря как ее компилировать... если как С++ то конечно ничего не выдет. E>Предложи вариант, как компилировать. Может как в Java или C#?
Так они точно также как С++ компилятся.(ну с мелкими отличиями)
E>Нет, не про это. Посмотри, скажем на исходный пример с CurryAll.
Прости не вижу я там вывода типов кроме самого примитива аля auto.
E>Да уж, виртуальная машина, чтобы биты выжимать. Круто.
Зря смеешся. Если в ВМ сделать поддержку работы с битами то это будет даже проще чем на С/С++ и с очень высокой вероятностью эффективней.
E>Ты вот сейчас на C++ для Linux и AIX (если я ничего не перепутал) пишешь. В связи с этим два вопроса:
Без AIX E>1) помешало бы тебе,
Мне оно ни разу бы не помогло. E>чтобы вместо C++ там был гораздо более предсказуемый и стройный D,
У меня и С++ очень предсказуемый. А у тех у кого С++ не предсказуемый и D будет страдать темже в полный рост. E>который и компилируется к тому же в сотни раз быстрее, чем C++?
Умные люди проектировавшие систему сделали так что все разбито на кучу маленьких so'шик. Сошки разложены по пакетам...
Так что с временем компиляции проблем не возникает вобще.
Те это конечно не плохо былобы иметь но это не критично вобще. E>Чем хуже сегодня выжимать максимум из железа на D, а не на C++
В D консервативный GC, а это тормоза по определению.
Плюс у меня огоромный сервер с сотнями потоков и жрущий память гигами. Работает эта дура на многопроцессорном железе. И живет все это в кластере из десятков таких железок...
Консервативный ГЦ в таких условиях это смерь всему. E>(давай не будем брать библиотеки, просто основные качества языка)?
А если будем?
E>2) почему же ты не используешь Nemerle? Он что, биты хуже выжимает?
либо совершенно иная нежели CLR и JavaVM виртуальная машина.
Ты вобще читаешь что я пишу?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>Может быть ты об этом: E>
E>When comparing with nested functions, the function form is analogous to static or non-nested functions, and the delegate form is analogous to non-static nested functions. In other words, [b]a delegate literal can access stack variables in its enclosing function[/url], a function literal cannot.
E>Хотя про замыкания действительно не помню, может это бага?
Не это не то просто function считается статическим и соответствено не может ссылатся на локальные переменные, delegate же может. Но для delegate там ниже написано что нельзя ссылатся на локальные переменные из вложенной функции, так как при выходе получим мусор указывающий на стек, я попробовал на простых примерах все почему-то работает, вот и гадаю теперь UB или не UB Ладно надо будет примерчик посложнее проверить.
Здравствуйте, FR, Вы писали:
FR>Только то что в D это получается не хуже чем в Nemerle, полный аналог твоего кода даже читабельней по моему:
А если взять чуть мение игрушечный пример? Re[7]: синтаксический анализатор
Здравствуйте, FR, Вы писали:
WH>>Ну начнем с того что в немерле принципиально иная система типов... FR>Да расширена, но основа то была, не на пустом месте делали.
Нет не расширена. Там совсем другая система типов.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн