Здравствуйте, VladD2, Вы писали:
VD>А вот зачем он на сервере?
Сейчас есть очень быстрые интерпретаторы JS.
Вот недавно запустили эмуляцию Linux, прямо в браузере.
Потом, разве Nemerle не показывает нам, что и без большого количества аннотаций типов может получаться быстрый статически типизированный код?
Вот и интерпретаторы JS так поступают. Выводят типы, применяют всякие эвристики для ускорения.
01.06.11 19:56: Перенесено модератором из 'Nemerle' — VladD2
Здравствуйте, Аноним, Вы писали:
А>Потом, разве Nemerle не показывает нам, что и без большого количества аннотаций типов может получаться быстрый статически типизированный код? А>Вот и интерпретаторы JS так поступают. Выводят типы, применяют всякие эвристики для ускорения.
Все эти эвристики это здорово, они помогают оптимизировать. Только вот контроля, который дает компиляция не дают Приходится либо забить на этот контроль либо писать дикое количество тестов, которые делает компилятор при компиляции статически типизированного языка.
Здравствуйте, Аноним, Вы писали:
VD>>А вот зачем он на сервере? А>Сейчас есть очень быстрые интерпретаторы JS. А>Вот недавно запустили эмуляцию Linux, прямо в браузере.
Шутку понял. Смешно!
А>Потом, разве Nemerle не показывает нам, что и без большого количества аннотаций типов может получаться быстрый статически типизированный код? А>Вот и интерпретаторы JS так поступают. Выводят типы, применяют всякие эвристики для ускорения.
Надеюсь ты это не всерьез говоришь. Потому что если это сказано всерьез — это клинический случай некомпетентности.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Скорость JavaScript
От:
Аноним
Дата:
01.06.11 14:06
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
VD>>>А вот зачем он на сервере? А>>Сейчас есть очень быстрые интерпретаторы JS. А>>Вот недавно запустили эмуляцию Linux, прямо в браузере.
VD>Шутку понял. Смешно!
А>>Потом, разве Nemerle не показывает нам, что и без большого количества аннотаций типов может получаться быстрый статически типизированный код? А>>Вот и интерпретаторы JS так поступают. Выводят типы, применяют всякие эвристики для ускорения.
VD>Надеюсь ты это не всерьез говоришь. Потому что если это сказано всерьез — это клинический случай некомпетентности.
Другой аноним. Скорость джаваскрип составляет в среднем 80% от С++(-О2) если не пользоваться аналогами "вычислить"
Здравствуйте, Аноним, Вы писали:
А>Другой аноним. Скорость джаваскрип составляет в среднем 80% от С++(-О2) если не пользоваться аналогами "вычислить"
Орлы вы несете несусветную чушь. Даже Java в Хотспотом не дает 80% производительности хороших С++-компиляторов. А жабаскрипт просто по архитектуре не может тягаться с компилируемыми языками. В лучшем случае вы получите ускорение отдельных операций (которые сводятся к статически-типизируемым). Как только вы начнете использовать ООП или ФП вы тот час же получите 5 и более раз проигрыша. В среднем более 10.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: Скорость JavaScript
От:
Аноним
Дата:
01.06.11 15:07
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Шутку понял. Смешно!
Над собой смеетсеь. (c)
VD>Надеюсь ты это не всерьез говоришь. Потому что если это сказано всерьез — это клинический случай некомпетентности.
Абсолютно серьезно. Пора уже выйти из сумрака и осознать, что на JS вполне себе пишут серверные приложения достаточно критичные к скорости.
Здравствуйте, VladD2, Вы писали:
VD>Даже Java в Хотспотом
Классическая, если не сказать, Epic, ошибка.
Надеюсь вы понимаете, что Java и JavaScript совершенно разные технологии.
VD>А жабаскрипт просто по архитектуре не может тягаться с компилируемыми языками.
Это вопрос не архитектуры, а вложений в интерпретатор-компилятор.
Условный Nemerle может быть сколь угодно хорош по архитектуре, но если его развивают три человека за бесплатно, суперпроизводительности он демонстрировать не будет. А если в разработку JS вкладываются миллионы от гугла, MS, Apple, то даже будь он безногий инвалид от рождения, с такой поддержкой он начнёт ставить рекорды.
Re[2]: Скорость JavaScript
От:
Аноним
Дата:
01.06.11 15:23
Оценка:
Здравствуйте, Ziaw, Вы писали:
Z>Все эти эвристики это здорово, они помогают оптимизировать. Только вот контроля, который дает компиляция не дают Приходится либо забить на этот контроль либо писать дикое количество тестов, которые делает компилятор при компиляции статически типизированного языка.
Тесты пишутся абсолютно такие же, что и для статически типизированного языка
Здравствуйте, Аноним, Вы писали:
А>Абсолютно серьезно. Пора уже выйти из сумрака и осознать, что на JS вполне себе пишут серверные приложения достаточно критичные к скорости.
Так. Просьба к фанатам этого недоязыка покинуть палубу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, VladD2, Вы писали:
VD>>Даже Java в Хотспотом А>Классическая, если не сказать, Epic, ошибка. А>Надеюсь вы понимаете, что Java и JavaScript совершенно разные технологии.
Если бы ты внимательно читал, то понял бы, что именно это я и подчеркиваю. У Java есть хоть какие-то шанся тягаться с плюсамип. У жабаскрипта ни малейших.
VD>>А жабаскрипт просто по архитектуре не может тягаться с компилируемыми языками. А>Это вопрос не архитектуры, а вложений в интерпретатор-компилятор.
Это вопрос понимания в теме обсуждения. Если оно есть, то такие эпические глупости говорить не будешь.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
А>>Другой аноним. Скорость джаваскрип составляет в среднем 80% от С++(-О2) если не пользоваться аналогами "вычислить" VD>Орлы вы несете несусветную чушь. Даже Java в Хотспотом не дает 80% производительности хороших С++-компиляторов. А жабаскрипт просто по архитектуре не может тягаться с компилируемыми языками.
Хмм....
Здравствуйте, Cyberax, Вы писали:
C>http://bellard.org/jslinux/ — здесь на JavaScript эмулируется PC, в котором работает Линукс.
Ну, и что это доказывает? Я тебе командную строку и на PHP нарисую.
У меня 15 лет назад Линкус пахал на 486-ом проце который наверно раз 1000 медленнее чем мой современный процессор. Это куда более большая разница чем десятикратный проигрыш, который в среднем дают интерпретаторы.
C>https://developer.mozilla.org/en-US/demos/detail/doom-on-the-web/ — здесь на JS портирован оригинальный Doom.
Веб-страница недоступна
C>Так что пока рано говорить о том, что JS никогда не сможет тягаться с компилируемыми языками.
Надо быть вообще полным неучем чтобы не понимать этого. Любой скрип принципиально не может добиться скорости прямых вычислений.
Фокусы вроде компиляции скриптво дают только локальные результаты на частях кода которые могут быть статически типизированы (путем вывода типов).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, VladD2, Вы писали:
А>>>Другой аноним. Скорость джаваскрип составляет в среднем 80% от С++(-О2) если не пользоваться аналогами "вычислить" VD>>Орлы вы несете несусветную чушь. Даже Java в Хотспотом не дает 80% производительности хороших С++-компиляторов. А жабаскрипт просто по архитектуре не может тягаться с компилируемыми языками. C>Хмм....
C>http://bellard.org/jslinux/ — здесь на JavaScript эмулируется PC, в котором работает Линукс. https://developer.mozilla.org/en-US/demos/detail/doom-on-the-web/ — здесь на JS портирован оригинальный Doom.
гм, а что это поделка от мозилы захлопнула мне лиса без всяких предупреждений? кстати, оригинальный дум шел на очень слабом железе и сейчас его можно и на полном программном эмуляторе запустить, так что это ничего не доказывает.
americans fought a war for a freedom. another one to end slavery. so, what do some of them choose to do with their freedom? become slaves.
Здравствуйте, VladD2, Вы писали:
C>>http://bellard.org/jslinux/ — здесь на JavaScript эмулируется PC, в котором работает Линукс. VD>Ну, и что это доказывает? Я тебе командную строку и на PHP нарисую.
Это не командная строка. Это полноценный эмулятор PC — в нём Win3.11 можно даже запустить.
VD>У меня 15 лет назад Линкус пахал на 486-ом проце который наверно раз 1000 медленнее чем мой современный процессор. Это куда более большая разница чем десятикратный проигрыш, который в среднем дают интерпретаторы.
Трассирующие интерпретаторы пока ещё в самой молодости, но они уже сократили разрыв между интерпретаторами и компиляторами с сотен раз до десятков.
C>>Так что пока рано говорить о том, что JS никогда не сможет тягаться с компилируемыми языками. VD>Надо быть вообще полным неучем чтобы не понимать этого. Любой скрип принципиально не может добиться скорости прямых вычислений. VD>Фокусы вроде компиляции скриптво дают только локальные результаты на частях кода которые могут быть статически типизированы (путем вывода типов).
Трассирующие компиляторы позволяют не только динамически выводить типы, но ещё и перекомпилировать использующий их код при смене структуры типов.
Собственно, локальный вывод типов для JS вообще отстойно работает из-за того, что самый частый объект манипуляции — это узлы DOM.
VD>>>А вот зачем он на сервере? А>>Сейчас есть очень быстрые интерпретаторы JS. А>>Вот недавно запустили эмуляцию Linux, прямо в браузере. VD>Шутку понял. Смешно!
<КО>
Никаких шуток. Только не эмуляцию Linux, а собственно, Linux, на жаваскриптовом эмуляторе x86 железа. http://bellard.org/jslinux/ http://bellard.org/jslinux/tech.html
</КО>
Если уж совсем неверится — там есть простенький C компилятор — tcc — мона написать свою прогу и скомпилять и она даже будет работать. Есть и vi чтобы прогу написать и даже клипборд (/dev/clipboard) который представляет собой копию того что вкопипастено в окошко справа.
Как много веселых ребят, и все делают велосипед...
Здравствуйте, Cyberax, Вы писали:
C>Трассирующие компиляторы позволяют не только динамически выводить типы, но ещё и перекомпилировать использующий их код при смене структуры типов.
Чудес не бывает. Если что-то делается динамически, то мы за это платим временем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>Трассирующие компиляторы позволяют не только динамически выводить типы, но ещё и перекомпилировать использующий их код при смене структуры типов. VD>Чудес не бывает. Если что-то делается динамически, то мы за это платим временем.
Бывают, бывают. Динамика лёгким движением руки превращается в статику с помощью трассирующих компиляторов. Конечно, будет некоторый оверхед — так как код таки сначала нужно протрассировать, но не такой уж огромный.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, Аноним, Вы писали:
А>>Сейчас есть очень быстрые интерпретаторы JS.
_>JS быстрее C# _>Я серь-хи-хи-ёзно! :троллфейс:
Это ты сравнил mutable строку в C++ с immutable строкой в C#
Тем более со стороны C# там mono работает, над рантаймом которого работают не как над js и Microsoft .NET.
Здравствуйте, gandjustas, Вы писали:
G>Это ты сравнил mutable строку в C++ с immutable строкой в C#
стрингбилдер не умеет +=, не удобно
G>Тем более со стороны C# там mono работает, над рантаймом которого работают не как над js и Microsoft .NET.
Проблемы MS и .net
java медленнее http://ideone.com/evyrW результат: успешно время: 2.03s
js рулит.
Хотя по выделенной памяти заметно, что js оптимизирует(забивает на) освобождение памяти
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Это ты сравнил mutable строку в C++ с immutable строкой в C# _>стрингбилдер не умеет +=, не удобно
StringBuilder.Append
Не всегда литеральное сходство программ соответствует их семантическому сходству.
O>Никаких шуток. Только не эмуляцию Linux, а собственно, Linux, на жаваскриптовом эмуляторе x86 железа.
Не взлетело. Тормозило несколько минут, а потом предложило прибить скрпт, бо он тормозит весь компьютер. Дал ему еще немного времени, но картинка так и осталась черным квадратом, так что пришлось таки прибить.
Здравствуйте, Vamp, Вы писали:
O>>Никаких шуток. Только не эмуляцию Linux, а собственно, Linux, на жаваскриптовом эмуляторе x86 железа. V>Не взлетело. Тормозило несколько минут, а потом предложило прибить скрпт, бо он тормозит весь компьютер. Дал ему еще немного времени, но картинка так и осталась черным квадратом, так что пришлось таки прибить.
Здравствуйте, Аноним, Вы писали:
Z>>Все эти эвристики это здорово, они помогают оптимизировать. Только вот контроля, который дает компиляция не дают Приходится либо забить на этот контроль либо писать дикое количество тестов, которые делает компилятор при компиляции статически типизированного языка.
А>Тесты пишутся абсолютно такие же, что и для статически типизированного языка
Здравствуйте, gandjustas, Вы писали:
G>Тебе шашечки или ехать?
Ехать конечно. СтрингБилдер — шашечки.
Глупый вопрос: зачем "неизменяемой" строке "изменяющий" оператор +=? Пусть или убирают, или оптимизируют. Я сажусь в первую машину которая едет в нужную мне точку. Статистически замечено, что чаще всего попадаются маршрутки (string). Что делать? Можно сделать свой специально заточенный велосипед (MySuperString), в простонародье купить машину. А лучше танк T-80 с боекомплектом, чтоб проложить прямой путь до работы.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Тебе шашечки или ехать?
_>Ехать конечно. СтрингБилдер — шашечки.
Синтаксис — "шашечки", а "ехать" — чтобы работало как надо.
_>Глупый вопрос: зачем "неизменяемой" строке "изменяющий" оператор +=?
Он изменяющий ссылку, а не значение.
string a = "string";
string b = a;
a += "!";
Поменялась ссылка на строку в a, а не значение самой строки.
Кстати такой код в цикле в C++ сколько будет выполняться?
_>Пусть или убирают, или оптимизируют.
Склейка строк и так оптимизирована по самое небалуйся. Паталогический случай только один — ровно тот что ты привел в своем примере, и то он хреново работает не из-за самих строк, а из-за сборки мусора.
_>Я сажусь в первую машину которая едет в нужную мне точку. Статистически замечено, что чаще всего попадаются маршрутки (string). Что делать?
Учиться. Не стоит обвинять язык или фреймворк в том что ты чего-то не знаешь.
Здравствуйте, gandjustas, Вы писали:
G>Синтаксис — "шашечки", а "ехать" — чтобы работало как надо.
Мне как пользователю множества языков, платформ, ос, не хватает человеческих ресурсов на изучение, на оптимальное применение возможностей и тп. Надо ехать, а не шашечки (стрингбилдеры) выбирать. Я пользователь.
Дело принимает серьезные обороты. Поря сматывать удочки.
А теперь вопрос, а при чем здесь сравнение с с++?
Вроде же утверждалось что JS > C#. В JS нет стрингбилдера. И тесты они такие тесты.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Синтаксис — "шашечки", а "ехать" — чтобы работало как надо.
_>Мне как пользователю множества языков, платформ, ос, не хватает человеческих ресурсов на изучение, на оптимальное применение возможностей и тп. Надо ехать, а не шашечки (стрингбилдеры) выбирать. Я пользователь.
Это не оправдывает твое незнание.
_>Дело принимает серьезные обороты. Поря сматывать удочки. _>А теперь вопрос, а при чем здесь сравнение с с++? _>Вроде же утверждалось что JS > C#. В JS нет стрингбилдера. И тесты они такие тесты.
Встроенного может и нет, но если бы программил на JS, то знал бы что довольно часто там использует массив строк и операция join. По сути это и есть stringbuilder.
ЗЫ. Вообще никто, кроме полных идиотов, в циклах строки не клеит, ни в java, ни в js, ни в C#
Здравствуйте, fin_81, Вы писали:
_>Мне как пользователю множества языков, платформ, ос, не хватает человеческих ресурсов на изучение, на оптимальное применение возможностей и тп. Надо ехать, а не шашечки (стрингбилдеры) выбирать. Я пользователь.
Ну так и выбирайте: или вы одинаково плохо пишете на всём, или относительно неплохо — на нескольких языках. В любом случае, ваше знание/незнание матчасти никак не повлияет на достоинства и недостатки языка. Поэтому с гордо-глуповатым "я пользователь" — куда-нибудь на другой ресурс плиз.
Здравствуйте, gandjustas, Вы писали:
G>Это не оправдывает твое незнание.
G>Встроенного может и нет, но если бы программил на JS, то знал бы что довольно часто там использует массив строк и операция join. По сути это и есть stringbuilder.
Я знаю что есть стрингбилдер, и для чего он нужен. Имею представление как должен работать += для "хитрых" строк в c#. Для с# более правильно s = s + 'a', тк оператор += "сворован" из с/c++, где он имеет семантику "изменить значение". Так что воровать тоже надо осторожно, чтоб не поиметь проблем от стереотипов.
[offtop] G>ЗЫ. Вообще никто, кроме полных идиотов, в циклах строки не клеит, ни в java, ни в js, ни в C#
Спасибо, ты тоже класный
Но во время троллинга я не переходил на личности. Я всеми междометиями пытался акцентировать на неадекватность этого "исследования".
В общем, я, наверно, не знаю толк в троллинге и надо было обязательно кого-нибудь замарать в грязи.
В общем предлагаю мир, не умею я на таком уровне троллить.
[/offtop]
Здравствуйте, ononim, Вы писали:
o> Никаких шуток. Только не эмуляцию Linux, а собственно, Linux, на жаваскриптовом эмуляторе x86 железа. o> http://bellard.org/jslinux/
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, ononim, Вы писали:
o>> Никаких шуток. Только не эмуляцию Linux, а собственно, Linux, на жаваскриптовом эмуляторе x86 железа. o>> http://bellard.org/jslinux/
AB>Мне опять не везет:
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Это не оправдывает твое незнание.
G>>Встроенного может и нет, но если бы программил на JS, то знал бы что довольно часто там использует массив строк и операция join. По сути это и есть stringbuilder.
_>Я знаю что есть стрингбилдер, и для чего он нужен. _>Имею представление как должен работать += для "хитрых" строк в c#.
Абсолютно не имеешь судя по всему.
_>Для с# более правильно s = s + 'a'
Если что x+=y — это сахар для x=x+y, ты не можешь переопределить оператор +=.
_>тк оператор += "сворован" из с/c++, где он имеет семантику "изменить значение".
Вообще-то этот оператор в C без плюсов еще был. Да и в инструкциях процессора операция add меняет первый аргумент.
_>Так что воровать тоже надо осторожно, чтоб не поиметь проблем от стереотипов.
Точно, воровать осторожно надо:
string a = "string";
string b = a;
a+="!";
if(a == b)
{
cout<<"FUCK";
}
Посмотри реализацию string и сколько сил приложено чтобы приведенный выше код не ругался. Посмотри сколько еще реализация строк придумано, у которых есть проблемы в таких сценариях. так что действительно воровать надо осторожно. Вот кстати в C#\java\js нету таких проблем. Там от самой строки не требуется крайне хитрых механизмов чтобы работал приведенный выше сценарий.
_>[offtop] G>>ЗЫ. Вообще никто, кроме полных идиотов, в циклах строки не клеит, ни в java, ни в js, ни в C# _>Спасибо, ты тоже класный _>Но во время троллинга я не переходил на личности. Я всеми междометиями пытался акцентировать на неадекватность этого "исследования". _>В общем, я, наверно, не знаю толк в троллинге и надо было обязательно кого-нибудь замарать в грязи. _>В общем предлагаю мир, не умею я на таком уровне троллить. _>[/offtop]
К твоему сожалению это не троллинг, а правда жизни. Если программист на C#\Java пишет такие циклы, то его надо увольнять.
А>>Абсолютно серьезно. Пора уже выйти из сумрака и осознать, что на JS вполне себе пишут серверные приложения достаточно критичные к скорости.
VD>Так. Просьба к фанатам этого недоязыка покинуть палубу.
О, Влад сам стал жертвой парадокса блаба
Отткрываю страшную тайну: да, на JS сейчас некоторые пишут серверные приложения (ключевые для поиска слова: node.js, Plurk).
Здравствуйте, gandjustas, Вы писали:
_>>тк оператор += "сворован" из с/c++, где он имеет семантику "изменить значение". G>Вообще-то этот оператор в C без плюсов еще был. Да и в инструкциях процессора операция add меняет первый аргумент.
ко? выделил жирным: "сворован" из с/c++
_>>Так что воровать тоже надо осторожно, чтоб не поиметь проблем от стереотипов. G>Точно, воровать осторожно надо: G>
G>string a = "string";
G>string b = a;
G>a+="!";
G>if(a == b)
G>{
G> cout<<"FUCK";
G>}
G>
G>Посмотри реализацию string и сколько сил приложено чтобы приведенный выше код не ругался. Посмотри сколько еще реализация строк придумано, у которых есть проблемы в таких сценариях. так что действительно воровать надо осторожно. Вот кстати в C#\java\js нету таких проблем. Там от самой строки не требуется крайне хитрых механизмов чтобы работал приведенный выше сценарий.
Мне не важно что под капотом, мне важно удобство. Не важно, copy-on-write использован, или тупое копирование. Мне важно то, что в stl решили не плодить сущности без особой надобности, сохранив баланс(для меня) между удобством и производительностью. И, вообще, на данном этапе у ЯП хаос с мутабельностью значений. Что победит не известно, но, скорее всего, удобство в виде иммутабельности, в ущерб производительности.
И вообще, что за жОский оффтопик — тема про js! Кому здесь нужны сравнения с++ и c#?! Все сравнения "недоязыков", вон из этой темы.
Здравствуйте, fin_81, Вы писали:
_>>>Так что воровать тоже надо осторожно, чтоб не поиметь проблем от стереотипов. G>>Точно, воровать осторожно надо: G>>
G>>string a = "string";
G>>string b = a;
G>>a+="!";
G>>if(a == b)
G>>{
G>> cout<<"FUCK";
G>>}
G>>
G>>Посмотри реализацию string и сколько сил приложено чтобы приведенный выше код не ругался. Посмотри сколько еще реализация строк придумано, у которых есть проблемы в таких сценариях. так что действительно воровать надо осторожно. Вот кстати в C#\java\js нету таких проблем. Там от самой строки не требуется крайне хитрых механизмов чтобы работал приведенный выше сценарий.
_>Мне не важно что под капотом, мне важно удобство. Не важно, copy-on-write использован, или тупое копирование.
Да ну? Если бы там было тупое копирование ты бы сейчас совсем по-другому говорил
_>Мне важно то, что в stl решили не плодить сущности без особой надобности, сохранив баланс(для меня) между удобством и производительностью. И, вообще, на данном этапе у ЯП хаос с мутабельностью значений. Что победит не известно, но, скорее всего, удобство в виде иммутабельности, в ущерб производительности.
Тут уже было обсуждение в котором std::string слил string\StringBuilder, почитай.
Суть в том что mutable строка и immutable строка — разные контракты, и надобность плодить сущности есть, только ты её осознать не можешь. _>И вообще, что за жОский оффтопик — тема про js! Кому здесь нужны сравнения с++ и c#?! Все сравнения "недоязыков", вон из этой темы.
Здравствуйте, fin_81, Вы писали:
А>>Сейчас есть очень быстрые интерпретаторы JS.
А кто реально их сейчас использует?
_>JS быстрее C#
_>Доказательства: _>С#: http://ideone.com/GZv0X результат: успешно время: 1.9s _>JS: http://ideone.com/7C6y8 результат: успешно время: 1.47s
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, VladD2, Вы писали:
VD>>Даже Java в Хотспотом А>Классическая, если не сказать, Epic, ошибка. А>Надеюсь вы понимаете, что Java и JavaScript совершенно разные технологии.
VD>>А жабаскрипт просто по архитектуре не может тягаться с компилируемыми языками. А>Это вопрос не архитектуры, а вложений в интерпретатор-компилятор. А>Условный Nemerle может быть сколь угодно хорош по архитектуре, но если его развивают три человека за бесплатно, суперпроизводительности он демонстрировать не будет. А если в разработку JS вкладываются миллионы от гугла, MS, Apple, то даже будь он безногий инвалид от рождения, с такой поддержкой он начнёт ставить рекорды.
ЕГЭ сдал?
Я что-то теряю нить общения. Буду просто отбиваться.
Здравствуйте, gandjustas, Вы писали:
_>>Мне не важно что под капотом, мне важно удобство. Не важно, copy-on-write использован, или тупое копирование. G>Да ну? Если бы там было тупое копирование ты бы сейчас совсем по-другому говорил
А кто говорил что там тупое копирование? Зависит от реализации. Но в с++ одна сущность — строка, а мутабелность управляется средствами языка. А то что в c# и java проблемы с этим и приходится создавать другие сущности для этого, это проблемы языка. Не мои проблемы.
_>>Мне важно то, что в stl решили не плодить сущности без особой надобности, сохранив баланс(для меня) между удобством и производительностью. И, вообще, на данном этапе у ЯП хаос с мутабельностью значений. Что победит не известно, но, скорее всего, удобство в виде иммутабельности, в ущерб производительности. G>Тут уже было обсуждение в котором std::string слил string\StringBuilder, почитай.
Не интересно std::string — одна сущность, string/StringBuilder — целых две. Кто быстрее, один бегун по дистанции, или два посменно бегущих.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
G>>ЗЫ. Вообще никто, кроме полных идиотов, в циклах строки не клеит, ни в java, ни в js, ни в C#
N>Не клеит только потому, что библиотека не позволяет.
Как не позволяет? В любом из перечисленных языков есть оператор += для строк.
N>Вариант со стрингбилдером слишком многословный для современного языка. Это очевидно, как день.
Помоему самое то. То что плохо работает должно плохо выглядеть. К сожалению для immutable строк не удалось этого добиться.
Здравствуйте, fin_81, Вы писали:
_>Я что-то теряю нить общения. Буду просто отбиваться.
_>Здравствуйте, gandjustas, Вы писали:
_>>>Мне не важно что под капотом, мне важно удобство. Не важно, copy-on-write использован, или тупое копирование. G>>Да ну? Если бы там было тупое копирование ты бы сейчас совсем по-другому говорил _>А кто говорил что там тупое копирование? Зависит от реализации. Но в с++ одна сущность — строка, а мутабелность управляется средствами языка. А то что в c# и java проблемы с этим и приходится создавать другие сущности для этого, это проблемы языка. Не мои проблемы.
Ниче не понял...
_>>>Мне важно то, что в stl решили не плодить сущности без особой надобности, сохранив баланс(для меня) между удобством и производительностью. И, вообще, на данном этапе у ЯП хаос с мутабельностью значений. Что победит не известно, но, скорее всего, удобство в виде иммутабельности, в ущерб производительности. G>>Тут уже было обсуждение в котором std::string слил string\StringBuilder, почитай. _>Не интересно std::string — одна сущность, string/StringBuilder — целых две. Кто быстрее, один бегун по дистанции, или два посменно бегущих.
Именно, каждый "специализированный" бегущий бежит быстрее свою дистанцию, чем один универсальный.
не ты ли тут начал с демонстрации скорости работы?
Здравствуйте, gandjustas, Вы писали:
G>Именно, каждый "специализированный" бегущий бежит быстрее свою дистанцию, чем один универсальный.
Естественно, но почему то мне предлагается посмотреть на результат сравнения "одинокого" std.string против команды string и stringbuilder. Несправедливо как-то.
G>не ты ли тут начал с демонстрации скорости работы?
Я сравнивал "практически одинаковый" код и их скорость. А сравнивать спринтера (std.string) и шумахера(string) на феррари(strinbuilder) как-то не по-спортивному.
Здравствуйте, gandjustas, Вы писали:
G>Тут уже было обсуждение в котором std::string слил string\StringBuilder, почитай.
почему не std::string\std::stringstream ?
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Именно, каждый "специализированный" бегущий бежит быстрее свою дистанцию, чем один универсальный. _>Естественно, но почему то мне предлагается посмотреть на результат сравнения "одинокого" std.string против команды string и stringbuilder. Несправедливо как-то.
Да, и поэтому надо выбрать из пары того кто наименее подходит для такой задачи и сравнивать его. Ну очень справедливо
G>>не ты ли тут начал с демонстрации скорости работы? _>Я сравнивал "практически одинаковый" код и их скорость.
Практически одинаковый по написанию, но не по семантике, я тебе это уже говорил.
_>А сравнивать спринтера (std.string) и шумахера(string) на феррари(strinbuilder) как-то не по-спортивному.
А как ты думаешь в нормальном коде что будет? То что ты написал или stringbuilder?
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Тут уже было обсуждение в котором std::string слил string\StringBuilder, почитай. A>почему не std::string\std::stringstream ?
А причем тут stringstream?
mutable строка в .NET и Java это StringBuilder, так вот и сравнивай его на задачах где требуется mutable, а там где не требуется, там обычный string.
_>Я сравнивал "практически одинаковый" код и их скорость.
В общем я ухожу из темы сравнения с++ и с#. Тк не для того я сравнивал js и c#.
js > c#!
точка!
[offtop]
ничего против c# не имею. хороший язык. но не понятно: зачем придумали его при живом java? чтобы нам программистам-пользователям плохо жилось? лучше бы "окна" рисовали, интернет эксплорер доработали. планшетами занимались. счастье пользователям приносили, за их деньги. а так бесполезное распиливание средств. ради чего пока не ясно. конкуренты давят. java живет. интернет упустили. куда катится мир. билли вернись. дай пинка балмеру, чтоб у него волосы выросли. вдруг поможет.
[/offtop]
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Abyx, Вы писали:
A>>Здравствуйте, gandjustas, Вы писали:
G>>>Тут уже было обсуждение в котором std::string слил string\StringBuilder, почитай. A>>почему не std::string\std::stringstream ?
G>А причем тут stringstream?
G>mutable строка в .NET и Java это StringBuilder, так вот и сравнивай его на задачах где требуется mutable, а там где не требуется, там обычный string.
мутабельность тут ни при чем
StringBuilder быстрее чем string потому что там внутри сидит поток который эффективно выделяет буферы памяти,
а string и вполне себе мутабельный std::string при конкатенации создают новую строку, потому что в старую не влазит.
вот и получается что std::string вызывает resize (malloc\free) в каждом operator+=
а StringBuilder и std::stringstream вызывают malloc только когда текущий буфер переполнится.
Здравствуйте, fin_81, Вы писали:
f> [offtop] f> ничего против c# не имею. хороший язык. но не понятно: зачем придумали его при живом java? чтобы нам программистам-пользователям плохо жилось? лучше бы "окна" рисовали, интернет эксплорер доработали. планшетами занимались. счастье пользователям приносили, за их деньги. а так бесполезное распиливание средств. ради чего пока не ясно. конкуренты давят. java живет. интернет упустили. куда катится мир. билли вернись. дай пинка балмеру, чтоб у него волосы выросли. вдруг поможет. f> [/offtop]
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, Mamut, Вы писали:
M>>Оба сливают Erlang'у
_>не спец по структурам эрланга. вроде надо поменять местами $a, L _>f(L, I) -> f([L, $a], I + 1)
_>http://ideone.com/QJlo5
_>Этот код "еще" быстрее.
_>А где же string?
И где внешний внешний цикл?
Изучил эрланг за 10 минут.
Вот мой вариант http://ideone.com/RMjRU
Но все равно быстро
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, Abyx, Вы писали:
A>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Тут уже было обсуждение в котором std::string слил string\StringBuilder, почитай. A>>>почему не std::string\std::stringstream ?
G>>А причем тут stringstream?
G>>mutable строка в .NET и Java это StringBuilder, так вот и сравнивай его на задачах где требуется mutable, а там где не требуется, там обычный string.
A>мутабельность тут ни при чем
Еще как причем.
A>StringBuilder быстрее чем string потому что там внутри сидит поток который эффективно выделяет буферы памяти, A>а string и вполне себе мутабельный std::string при конкатенации создают новую строку, потому что в старую не влазит.
Мы тут рассматриваем операцию добавления символа в конец (+=). Для std::string и StringBuilder это ammortized O(1), для System.String это всегда o(n) из-за копирования.
Теперь понимаешь причем тут мутабельность?
A>вот и получается что std::string вызывает resize (malloc\free) в каждом operator+= A>а StringBuilder и std::stringstream вызывают malloc только когда текущий буфер переполнится.
Готов поспотри что std::string работает также. Не бараны его писали.
Здравствуйте, fin_81, Вы писали:
_>>Я сравнивал "практически одинаковый" код и их скорость.
_>В общем я ухожу из темы сравнения с++ и с#. Тк не для того я сравнивал js и c#.
_>js > c#! _>точка! _>
Здравствуйте, gandjustas, Вы писали:
G>http://ideone.com/xbIqq
G>Ты неправ. Пора бы уже признать это, а не выкручиваться.
Я так не играю, почему при сравнении c++ mutable и immutable имеют важное значение, а при сравнении с js не имеют.
Не спортивно.
js array не предлагать — это не буффер, это скорее всего map.
Надо бы сравнить скорость TypedArray. Думаю скорости будут сравнимы.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, divergo, Вы писали:
D>>memory: 37528 kB D>>memory: 213568 kB
_>Память дешевая, время разработки дороже.
Смотря какая память имеется в виду. Предположим, имеем 10 000 серверов, пишем что-то на жабе/жабоскрипте/etc., которая сливает в унитаз процентов 30 (не)ресурсов. Итого 3000*$20000=$60 000 000 просто выкидываем т.к. кто-то очень умный считает, что память (и процессор, надо думать) — не ресурс, а вот его рабочее время, в которое он генерирует говнокод, — бесценно.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>http://ideone.com/xbIqq
G>>Ты неправ. Пора бы уже признать это, а не выкручиваться.
_>Я так не играю, почему при сравнении c++ mutable и immutable имеют важное значение, а при сравнении с js не имеют. _>Не спортивно.
Да и в js так клеить строки не стоит.
Гугли stringbuilder для js.
_>js array не предлагать — это не буффер, это скорее всего map.
map в js это Object, а Array больше похож на .NET ArrayList и C++ vector.
_>Надо бы сравнить скорость TypedArray. Думаю скорости будут сравнимы.
А за чем дело стало? http://ideone.com/exdTX http://ideone.com/UqTo9 http://ideone.com/0dLH6
Для JS конечно нечестно получилось, ибо там боксинг. Также есть подозрение что Microsoft .NET будет пошустрее, чем mono.
Здравствуйте, 0xC0DE, Вы писали:
CDE>Здравствуйте, fin_81, Вы писали:
_>>Здравствуйте, divergo, Вы писали:
D>>>memory: 37528 kB D>>>memory: 213568 kB
_>>Память дешевая, время разработки дороже.
CDE>Смотря какая память имеется в виду. Предположим, имеем 10 000 серверов, пишем что-то на жабе/жабоскрипте/etc., которая сливает в унитаз процентов 30 (не)ресурсов. Итого 3000*$20000=$60 000 000 просто выкидываем т.к. кто-то очень умный считает, что память (и процессор, надо думать) — не ресурс, а вот его рабочее время, в которое он генерирует говнокод, — бесценно.
Где ты видел такое количество серверов? А хотябы в 20 раз меньше? И чтобы они выполняли один и тот же код на js.
Кстати цифры расчетов какие-то странные. Память на цену компа влияет чуть менее чем никак. Гиг памяти стоит меньше 1000р. На месячную ЗП можно купить сотню гигов.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, 0xC0DE, Вы писали:
CDE>>Здравствуйте, fin_81, Вы писали:
_>>>Здравствуйте, divergo, Вы писали:
D>>>>memory: 37528 kB D>>>>memory: 213568 kB
_>>>Память дешевая, время разработки дороже.
CDE>>Смотря какая память имеется в виду. Предположим, имеем 10 000 серверов, пишем что-то на жабе/жабоскрипте/etc., которая сливает в унитаз процентов 30 (не)ресурсов. Итого 3000*$20000=$60 000 000 просто выкидываем т.к. кто-то очень умный считает, что память (и процессор, надо думать) — не ресурс, а вот его рабочее время, в которое он генерирует говнокод, — бесценно.
G>Где ты видел такое количество серверов? А хотябы в 20 раз меньше? И чтобы они выполняли один и тот же код на js.
Ну, 10000 пока не видел, а в 20 раз меньше наблюдаю каждый день. Кста у яндекса, говорят, 30000 серверов, у гугла вообще какие-то неразумные количества.
G>Кстати цифры расчетов какие-то странные. Память на цену компа влияет чуть менее чем никак. Гиг памяти стоит меньше 1000р. На месячную ЗП можно купить сотню гигов.
Память надо куда-то вставлять, и слишком много памяти на одном сервере тоже не всегда хорошо. Можно с дуру и терабайт на один сервер поставить, да, но с этой памятью еще и работать надо, да и шина не резиновая.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, fin_81, Вы писали:
_>>Здравствуйте, gandjustas, Вы писали:
G>>>http://ideone.com/xbIqq
G>>>Ты неправ. Пора бы уже признать это, а не выкручиваться.
_>>Я так не играю, почему при сравнении c++ mutable и immutable имеют важное значение, а при сравнении с js не имеют. _>>Не спортивно. G>Да и в js так клеить строки не стоит.
Как надо склеивать строки, когда одновременно все части не доступны, поступают последовательно? а результат в виде строки нужен после каждого склеивания? И тест придуман для строк, а не для "стероидных бодибилдеров" из c#, которых нет в js.
G>Гугли stringbuilder для js. _>>js array не предлагать — это не буффер, это скорее всего map. G>map в js это Object, а Array больше похож на .NET ArrayList и C++ vector.
И убедится что его нет. А поделки на array — это те еще тормоза, проходили-с. Возможно, я не умею готовить.
Я не знаю нутро js, но по поведению js array — это, скорее всего, хеш-таблица оптимизированная для целочисленных индексов, или список с индексом (разреженные таблицы намекают), но точно не буфер. Поэтому на роль "стероидного бодибилдера" не подходит.
Посмотреть бы на поделки на основе TypedArray, не спроста же линукс летает на эмуляторе x86, написанном шустрых TypedArray.
_>>Надо бы сравнить скорость TypedArray. Думаю скорости будут сравнимы. G>А за чем дело стало? G>http://ideone.com/exdTX G>http://ideone.com/UqTo9 G>http://ideone.com/0dLH6
G>Для JS конечно нечестно получилось, ибо там боксинг. Также есть подозрение что Microsoft .NET будет пошустрее, чем mono.
Здравствуйте, 0xC0DE, Вы писали:
_>>Память дешевая, время разработки дороже.
CDE>Смотря какая память имеется в виду. Предположим, имеем 10 000 серверов, пишем что-то на жабе/жабоскрипте/etc., которая сливает в унитаз процентов 30 (не)ресурсов. Итого 3000*$20000=$60 000 000 просто выкидываем т.к. кто-то очень умный считает, что память (и процессор, надо думать) — не ресурс, а вот его рабочее время, в которое он генерирует говнокод, — бесценно.
Спасибо, ты тоже классный!
Ну в общем, тебе объяснили ценность памяти в современных серверах. От себя добавлю.
10000 серверов не за один день собирается. И пока это количество набирается в течении минимум 5 лет, нормальные 100 программистов пишут нормальный код, зарабатывая нормальную зарплату в размере $1 000 000 в год каждый. При этот этот нормальный продукт-сервис приносит более нормальный доход — $1 000 000 000 в год.
Я тоже умею рассказывать сказки. Чья сказка правдивее? Интереснее? Более мотивирующая?
Здравствуйте, fin_81, Вы писали:
f> H>FreePascal: время: 0.02s память: 252 kB
f> не честно! f> нельзя s := s + 'aa'; f> надо s := s + 'a'; f>
У FPC не юникодные строки, потому читерим Кстати, тут еще мой косяк, нужно заменить String на AnsiString. Так же у FPC ужасно тормозной менеджер памяти (на каждую конкатенацию — реаллокация), на дельфях этот код исполняется за 0.01s
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, fin_81, Вы писали:
_>>>Здравствуйте, gandjustas, Вы писали:
G>>>>http://ideone.com/xbIqq
G>>>>Ты неправ. Пора бы уже признать это, а не выкручиваться.
_>>>Я так не играю, почему при сравнении c++ mutable и immutable имеют важное значение, а при сравнении с js не имеют. _>>>Не спортивно. G>>Да и в js так клеить строки не стоит.
_>Как надо склеивать строки, когда одновременно все части не доступны, поступают последовательно? а результат в виде строки нужен после каждого склеивания?
Покажи реальный сценарий где такое нужно?
_>И тест придуман для строк, а не для "стероидных бодибилдеров" из c#, которых нет в js.
Ты пытаешься различать типы только по названию, тогда как умные люди различают из по семантике
G>>Гугли stringbuilder для js. _>>>js array не предлагать — это не буффер, это скорее всего map. G>>map в js это Object, а Array больше похож на .NET ArrayList и C++ vector.
_>И убедится что его нет. А поделки на array — это те еще тормоза, проходили-с. Возможно, я не умею готовить.
Ты точно не умеешь готовить. Хотя сильно зависит от движка JS.
_>Я не знаю нутро js, но по поведению js array — это, скорее всего, хеш-таблица оптимизированная для целочисленных индексов, или список с индексом (разреженные таблицы намекают), но точно не буфер. Поэтому на роль "стероидного бодибилдера" не подходит.
См выше.
_>>>Надо бы сравнить скорость TypedArray. Думаю скорости будут сравнимы. G>>А за чем дело стало? G>>http://ideone.com/exdTX G>>http://ideone.com/UqTo9 G>>http://ideone.com/0dLH6
G>>Для JS конечно нечестно получилось, ибо там боксинг. Также есть подозрение что Microsoft .NET будет пошустрее, чем mono. _>Каким боком это относится к js TypedArray?
Покажи где есть этот TypedArray?
Здравствуйте, hattab, Вы писали:
H>У FPC не юникодные строки, потому читерим Кстати, тут еще мой косяк, нужно заменить String на AnsiString. Так же у FPC ужасно тормозной менеджер памяти (на каждую конкатенацию — реаллокация), на дельфях этот код исполняется за 0.01s
Pascal... Как много в этом слове ...
Так не отвлекаемся, надо в этой теме набрать не менее 100 сообщений.
В виду того, что появилось много примеров с очень малым значением времени исполнения, предлагаю для них во внешний цикл прибавить один нолик.
О результатах отписываемся в этой теме.
Задача максимум устроить rsdn dos атаку на ideone.com.
Здравствуйте, gandjustas, Вы писали:
G>Ты точно не умеешь готовить. Хотя сильно зависит от движка JS.
Рабочий пример? Стараюсь не оценивать в флеймовых форумах, но за рабочий пример поставлю оценку 3.
У меня строки были быстрее. Проверял на хроме и лисе.
_>>Как надо склеивать строки, когда одновременно все части не доступны, поступают последовательно? а результат в виде строки нужен после каждого склеивания?
G>Покажи реальный сценарий где такое нужно?
Протестую, вопрос не по существу. Мой тест мои правила, вроде одинаковые и для js и для c#.
G>Покажи где есть этот TypedArray?
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Ты точно не умеешь готовить. Хотя сильно зависит от движка JS. _>Рабочий пример? Стараюсь не оценивать в флеймовых форумах, но за рабочий пример поставлю оценку 3. _>У меня строки были быстрее. Проверял на хроме и лисе.
Щас времени нет.
Можешь сам глянуть. http://www.google.ru/search?q=js+string+concatenation+vs+join
_>>>Как надо склеивать строки, когда одновременно все части не доступны, поступают последовательно? а результат в виде строки нужен после каждого склеивания? G>>Покажи реальный сценарий где такое нужно? _>Протестую, вопрос не по существу. Мой тест мои правила, вроде одинаковые и для js и для c#.
100% слив. Современные языки\рантаймы\библиотеки как раз затачиваются на распространенные сценарии.
G>>Покажи где есть этот TypedArray?
_>http://bellard.org/jslinux _>Работает шустро, компилирует и исполняет сишный-код. Работает на стероидах TypedArray.
Здравствуйте, gandjustas, Вы писали:
G>>>Ты точно не умеешь готовить. Хотя сильно зависит от движка JS. _>>Рабочий пример? Стараюсь не оценивать в флеймовых форумах, но за рабочий пример поставлю оценку 3. _>>У меня строки были быстрее. Проверял на хроме и лисе. G>Щас времени нет.
G>Можешь сам глянуть. http://www.google.ru/search?q=js+string+concatenation+vs+join
То ли +1 поставить, то ли дальше спорить.
В общем, скажу так: зависит от реализации. Мне когда начинал использовать js попалось исследование, где было наглядно показано, что в среднем по больнице/браузерам "+=" чуть-чуть быстрее join. Проверил, вроде у меня тоже повторяется. Лиса чуть выпадала из общего строя на больших списках с длинными строками. Ссылку привести не могу.
И вообще, какие проблемы могут быть для оптимизации += для строк. std::string, какбе намекае, как это можно сделать. Cоздайте внутренний буфер и меняйте как хотите имея в виду копирование буфера при изменении.
Нафига нам сдались эти "бодибилдеры"? На их теле стриги не самая приметная/смешная деталь.
_>>>>Как надо склеивать строки, когда одновременно все части не доступны, поступают последовательно? а результат в виде строки нужен после каждого склеивания? G>>>Покажи реальный сценарий где такое нужно? _>>Протестую, вопрос не по существу. Мой тест мои правила, вроде одинаковые и для js и для c#. G> G>100% слив. Современные языки\рантаймы\библиотеки как раз затачиваются на распространенные сценарии.
Ага, а распространенный (и логичный) сценарий это
s = s + 'a'?
или
sb = stringbuilder();
sb.append('a');
s = sb.tostring()
?
Для меня второй случай это Костыль с большой буквы, а не распространенный сценарий. Разве нет?
G>В каких браузерах сейчас поддерживается?
В хроме 11.
Typed array я привел как способ сравнять шансы js и c#.
G>>Можешь сам глянуть. http://www.google.ru/search?q=js+string+concatenation+vs+join _>То ли +1 поставить, то ли дальше спорить. _>В общем, скажу так: зависит от реализации. Мне когда начинал использовать js попалось исследование, где было наглядно показано, что в среднем по больнице/браузерам "+=" чуть-чуть быстрее join. Проверил, вроде у меня тоже повторяется. Лиса чуть выпадала из общего строя на больших списках с длинными строками. Ссылку привести не могу.
_>И вообще, какие проблемы могут быть для оптимизации += для строк. std::string, какбе намекае, как это можно сделать. Cоздайте внутренний буфер и меняйте как хотите имея в виду копирование буфера при изменении.
Еще раз. В .NET += и так конкатенация строк заоптимизирована, только не для циклического добавления в конец, а для вполне жизненных сценариев. Для Других есть String.Concat
Но ты этого так и не хочешь понять, все демонстрируя поытки почесать правой ногой левое ухо.
_>>>>>Как надо склеивать строки, когда одновременно все части не доступны, поступают последовательно? а результат в виде строки нужен после каждого склеивания? G>>>>Покажи реальный сценарий где такое нужно? _>>>Протестую, вопрос не по существу. Мой тест мои правила, вроде одинаковые и для js и для c#. G>> G>>100% слив. Современные языки\рантаймы\библиотеки как раз затачиваются на распространенные сценарии.
_>Ага, а распространенный (и логичный) сценарий это _>s = s + 'a'?
Да, а вот он же но в цикле — не очень.
_>или _>sb = stringbuilder(); _>sb.append('a'); _>s = sb.tostring() _>?
_>Для меня второй случай это Костыль с большой буквы, а не распространенный сценарий. Разве нет?
Ты еще не понял что вопрос не в единичном добавлении в конец, а в когда это происходит в цикле?
G>>В каких браузерах сейчас поддерживается? _>В хроме 11. _>Typed array я привел как способ сравнять шансы js и c#.
В нормальных сценариях все равно не догонит. Синтетические тесты с заведомо неэффективным кодом для одного из языков — ну вообще не показатель.
Здравствуйте, wraithik, Вы писали:
W>Здравствуйте, gandjustas, Вы писали:
G>>ЗЫ. Вообще никто, кроме полных идиотов, в циклах строки не клеит, ни в java, ни в js, ни в C#
W>Ок. Твой вариант кода. Цель вывести фильтр по списку элементов в строку.
W>
W>СтрокаФильтра = "";
W>Для Каждого Стр из СписокФильтра Цикл
W> СтрокаФильтра = СтрокаФильтра + ?(СтрокаФильтра = "", "", ", ") + Стр.Представление;
W>КонецЦикла;
W>
W>СписокФильтра — аналог TList. W>В 1С нет +=, по этому написал его аналог.
string.Concat, string.Join. выбирай что больше нравится.
Здравствуйте, vsb, Вы писали:
vsb>Firefox 4 попробуйте, у меня всё работает.
а вы уверены, то это жабоскрипт, а не хитрые апи фокса? =)
погляжу, только в 4 фоксе оно и работает.....
Здравствуйте, gandjustas, Вы писали:
G>Ты еще не понял что вопрос не в единичном добавлении в конец, а в когда это происходит в цикле?
Пусть циклы идут лесом, забыли про них. Мы сравниваем использование сущности "строка" в языках. На обоих пишем одинаковый код с использованием этой сущности для того чтобы собрать более длинную "строку". Потом сравниваем результаты.
Почему я должен на одном языке заниматься premature optimization и вводить в программу другие сущности, чтобы догнать по скорости? Многие проекты не доходят до стадии вылизывания кода "бодибилдерами" . Они уже приносят деньги. И некоторое конкурентное преимущество в скорости работы += может сыграть большую роль.
Поэтому js > c#
Поэтому js везде.
G>В нормальных сценариях все равно не догонит. Синтетические тесты с заведомо неэффективным кодом для одного из языков — ну вообще не показатель.
Согласен. Поэтому сравнивал скорости строк, а не стрингбилдеров. И в этом сравнении.
js(rhino) > c#(mono)
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Ты еще не понял что вопрос не в единичном добавлении в конец, а в когда это происходит в цикле?
_>Пусть циклы идут лесом, забыли про них. Мы сравниваем использование сущности "строка" в языках. На обоих пишем одинаковый код с использованием этой сущности для того чтобы собрать более длинную "строку". Потом сравниваем результаты. _>Почему я должен на одном языке заниматься premature optimization и вводить в программу другие сущности, чтобы догнать по скорости? Многие проекты не доходят до стадии вылизывания кода "бодибилдерами" . Они уже приносят деньги. И некоторое конкурентное преимущество в скорости работы += может сыграть большую роль.
Взаимоисключающие предложения в конце.
_>Поэтому js > c# На синтетических тестах с заведомо неэффективным кодом — да.
_>Поэтому js везде.
Пока что только в браузере. Раньше был Windows Script, то теперь его вытеснил powershell.
G>>В нормальных сценариях все равно не догонит. Синтетические тесты с заведомо неэффективным кодом для одного из языков — ну вообще не показатель. _>Согласен. Поэтому сравнивал скорости строк, а не стрингбилдеров. И в этом сравнении. _>js(rhino) > c#(mono)
См выделенное.
Здравствуйте, gandjustas, Вы писали:
_>>Пусть циклы идут лесом, забыли про них. Мы сравниваем использование сущности "строка" в языках. На обоих пишем одинаковый код с использованием этой сущности для того чтобы собрать более длинную "строку". Потом сравниваем результаты. _>>Почему я должен на одном языке заниматься premature optimization и вводить в программу другие сущности, чтобы догнать по скорости? Многие проекты не доходят до стадии вылизывания кода "бодибилдерами" . Они уже приносят деньги. И некоторое конкурентное преимущество в скорости работы += может сыграть большую роль.
G>Взаимоисключающие предложения в конце.
Мой модуль data mining имеет другое мнение
_>>Поэтому js > c# G>На синтетических тестах с заведомо неэффективным кодом — да.
Синтетические тесты такие "синтетические".
А нормальные пацаны на js пишут вполне шустрые эмуляторы и запускают бинарный код линукс.
_>>Поэтому js везде. G>Пока что только в браузере. Раньше был Windows Script, то теперь его вытеснил powershell.
А браузеры с js везде. Даже больше чем везде. Они даже там где не надо. А где "революционный" дотнет с силверлайтом? Неужели его забросят?
А "энергичная оболочка" пусть завоевывает себе место пока энергии хватает, а то как-то несолидно иметь ос без нормальных средств автоматизации действий. Даже на гламурном маке есть, как наследство от bsd.
Здравствуйте, fin_81, Вы писали:
_>>>Поэтому js > c# G>>На синтетических тестах с заведомо неэффективным кодом — да. _>Синтетические тесты такие "синтетические". _>А нормальные пацаны на js пишут вполне шустрые эмуляторы и запускают бинарный код линукс.
У меня дежавю. Ваша дискуссия напоминает "С# vs C++". Некоторые не могут принять и смириться.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>Пусть циклы идут лесом, забыли про них. Мы сравниваем использование сущности "строка" в языках. На обоих пишем одинаковый код с использованием этой сущности для того чтобы собрать более длинную "строку". Потом сравниваем результаты. _>>>Почему я должен на одном языке заниматься premature optimization и вводить в программу другие сущности, чтобы догнать по скорости? Многие проекты не доходят до стадии вылизывания кода "бодибилдерами" . Они уже приносят деньги. И некоторое конкурентное преимущество в скорости работы += может сыграть большую роль.
G>>Взаимоисключающие предложения в конце. _>Мой модуль data mining имеет другое мнение
Опишу более подробно: если есть "конкурентное преимущество в скорости работы", то полюбому напишут не +=, а Concat или Join в .NET
Полных дебилов не рассматриваем.
_>>>Поэтому js > c# G>>На синтетических тестах с заведомо неэффективным кодом — да. _>Синтетические тесты такие "синтетические". _>А нормальные пацаны на js пишут вполне шустрые эмуляторы и запускают бинарный код линукс.
Да пусть пишут, что с того? Твои "тесты" от этого правильнее не становятся.
Здравствуйте, Nuzhny, Вы писали:
N>У меня дежавю. Ваша дискуссия напоминает "С# vs C++". Некоторые не могут принять и смириться.
С++ — надо сильно упростить, пересмотреть. Надстройка над си шаблонов и классов смотрится слишком тяжело. Иногда при написании кода на с++ хочется сказать: да ну нафиг эти классы и шаблоны, на чистом си давно бы написал и отладил.
C# — хороший язык, gc. Клон java и этим все сказано.
js — тоже хороший язык, но у него проблемы с модульностью, и это как-то аукнется в будущем.
Но js > c#
Потому что тесты.
Потому что это тема про скорость js. И я буду защищать js, тк он не настолько плохой язык чтобы его называть "недоязыком". Пусть защищают свою позицию "языки с подмоченной репутацией".
Здравствуйте, March_rabbit, Вы писали:
M_>Здравствуйте, vsb, Вы писали:
vsb>>Firefox 4 попробуйте, у меня всё работает. M_>а вы уверены, то это жабоскрипт, а не хитрые апи фокса? =) M_>погляжу, только в 4 фоксе оно и работает.....
Здравствуйте, March_rabbit, Вы писали:
vsb>>Firefox 4 попробуйте, у меня всё работает. M_>а вы уверены, то это жабоскрипт, а не хитрые апи фокса? =) погляжу, только в 4 фоксе оно и работает.....
Обычная страница, как в этом случае, не имеет доступа к тому хитрому API.
Здравствуйте, gandjustas, Вы писали:
G>Опишу более подробно: если есть "конкурентное преимущество в скорости работы", то полюбому напишут не +=, а Concat или Join в .NET G>Полных дебилов не рассматриваем.
Осталось ввести полный контроль на производстве, чтоб никто не подумал даже а простом и приятном +=, а писал все генерации строк только через регэкс, тк это оптимизировано и работает нативно. И указкой по пальцам "преступивших", в угол и на горох. Как-то не мотивирует.
В век перепроизводства преимущество имеет тот кто раньше сделает достаточно удобный продукт. += — короче, понятнее и быстрее кодится. stringbuilder нервно курит в сторонке.
G>Да пусть пишут, что с того? Твои "тесты" от этого правильнее не становятся.
А какой код для js правильный?
1) с join, который дико тормозит/тормозил на ie (на последних версиях не проверял, может оптимизировали этот костыль для конкатенации строк)
2) или с +=, более стабильный и предсказуемый по скорости на разных реализациях.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, wraithik, Вы писали:
W>>Здравствуйте, gandjustas, Вы писали:
G>>>ЗЫ. Вообще никто, кроме полных идиотов, в циклах строки не клеит, ни в java, ни в js, ни в C#
W>>Ок. Твой вариант кода. Цель вывести фильтр по списку элементов в строку.
W>>
W>>СтрокаФильтра = "";
W>>Для Каждого Стр из СписокФильтра Цикл
W>> СтрокаФильтра = СтрокаФильтра + ?(СтрокаФильтра = "", "", ", ") + Стр.Представление;
W>>КонецЦикла;
W>>
W>>СписокФильтра — аналог TList. W>>В 1С нет +=, по этому написал его аналог.
G>string.Concat, string.Join. выбирай что больше нравится.
Чем это будет отличаться от += ?
Это разве не склейка строк?
Здравствуйте, fin_81, Вы писали:
_>С++ — надо сильно упростить, пересмотреть. Надстройка над си шаблонов и классов смотрится слишком тяжело. Иногда при написании кода на с++ хочется сказать: да ну нафиг эти классы и шаблоны, на чистом си давно бы написал и отладил.
Над C++ да тяжело, но это не значит что их нужно выкидывать. Просто нормально переписать, например взяв за образец D.
Здравствуйте, FR, Вы писали:
_>>С++ — надо сильно упростить, пересмотреть. Надстройка над си шаблонов и классов смотрится слишком тяжело. Иногда при написании кода на с++ хочется сказать: да ну нафиг эти классы и шаблоны, на чистом си давно бы написал и отладил.
FR>Над C++ да тяжело, но это не значит что их нужно выкидывать. Просто нормально переписать, например взяв за образец D.
С++ не надо выкидывать. Там пока не все так плохо. Практики на D у меня нет никакой. Со стороны вроде красиво.
В общем, проблема с++ в том что он слишком глубоко впитывается в мозг и шаг влево или вправо вызывает резкое отторжение, тк ломает то что зазубривалось годами. Надо полностью переделать/пересмотреть всю объектную и функциональную семантику оставив только популярные примитивы c++, чтоб не срабатывали с++-стереотипы. Надо еще придумать как стыковать старые и новые модули. Скорее всего надо на новую объектно-функциональную парадигму наложить примитивы с++ которые не мешают этой новой парадигме для привлечения с++-ников. И примирить объектников и функциональщиков.
Здравствуйте, Cyberax, Вы писали:
C>Бывают, бывают. Динамика лёгким движением руки превращается в статику с помощью трассирующих компиляторов. Конечно, будет некоторый оверхед — так как код таки сначала нужно протрассировать, но не такой уж огромный.
А зачем ее превращать? Мы ее имеем здесь и сразу. При этом еще имеем кучу всего что вы в своей динамике не имеете. Так что сиди и жди чудес. А мы пока попользуетмя более высокоуровневыми языками которые быстры без приседаний и мегабаксов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>Бывают, бывают. Динамика лёгким движением руки превращается в статику с помощью трассирующих компиляторов. Конечно, будет некоторый оверхед — так как код таки сначала нужно протрассировать, но не такой уж огромный. VD>А зачем ее превращать? Мы ее имеем здесь и сразу. При этом еще имеем кучу всего что вы в своей динамике не имеете. Так что сиди и жди чудес.
Аналогично с динамикой. К примеру, скрипты миграции БД на динамику ложатся очумительно красиво. Скажем, добавление полей в таблицу выглядит как операция с метаклассом.
Здравствуйте, Cyberax, Вы писали:
C>Аналогично с динамикой. К примеру, скрипты миграции БД на динамику ложатся очумительно красиво. Скажем, добавление полей в таблицу выглядит как операция с метаклассом.
Здравствуйте, VladD2, Вы писали:
C>>Аналогично с динамикой. К примеру, скрипты миграции БД на динамику ложатся очумительно красиво. Скажем, добавление полей в таблицу выглядит как операция с метаклассом. VD>Это ты рассказывай тем, кто вот этого не видел.
LOL. Ну представили DML в виде макросов. И что?
Как мне загрузить объекты, сменить у части из них тип, добавить к оставшимся новое поле и заполнить его вычисленным значением? Причём так, чтобы это не отличалось от обычной работы с ORM?
Здравствуйте, Cyberax, Вы писали:
C>LOL. Ну представили DML в виде макросов. И что?
И все. Задача решена и еще к тому же статически проверяется при компиляции.
C>Как мне загрузить объекты, сменить у части из них тип, добавить к оставшимся новое поле и заполнить его вычисленным значением? Причём так, чтобы это не отличалось от обычной работы с ORM?
Твой мозг поражен извращениями. Зачем менять какие то там объекты когда можно описать ДСЛ и на нем описать свои намерения?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Опишу более подробно: если есть "конкурентное преимущество в скорости работы", то полюбому напишут не +=, а Concat или Join в .NET G>>Полных дебилов не рассматриваем. _>Осталось ввести полный контроль на производстве, чтоб никто не подумал даже а простом и приятном +=, а писал все генерации строк только через регэкс, тк это оптимизировано и работает нативно. И указкой по пальцам "преступивших", в угол и на горох. Как-то не мотивирует. _>В век перепроизводства преимущество имеет тот кто раньше сделает достаточно удобный продукт. += — короче, понятнее и быстрее кодится. stringbuilder нервно курит в сторонке.
Ты снова передергиваешь. Ведь ты можешь писать += на C# и в цикле. Нормальные программисты поправят твой код, никто не пострадает. Если нету тех кто может поправить, то видимо эта группа программистов зря взялась за .NET и им стоит писать на js.
G>>Да пусть пишут, что с того? Твои "тесты" от этого правильнее не становятся. _>А какой код для js правильный? _>1) с join, который дико тормозит/тормозил на ie (на последних версиях не проверял, может оптимизировали этот костыль для конкатенации строк) _>2) или с +=, более стабильный и предсказуемый по скорости на разных реализациях.
Во-первых ты привел тесты где код разный по семантике. Во-вторых ты привел код, который далек от оптимального. В-третьих ты привел сценарий, который крайне редко встречается. Миллионы строк таким образом очень мало кто клеит тупо в циклах.
Теперь вопрос, что ты хотел сравнить? И что ты хотел этим показать?
Здравствуйте, wraithik, Вы писали:
W>>>Ок. Твой вариант кода. Цель вывести фильтр по списку элементов в строку.
W>>>
W>>>СтрокаФильтра = "";
W>>>Для Каждого Стр из СписокФильтра Цикл
W>>> СтрокаФильтра = СтрокаФильтра + ?(СтрокаФильтра = "", "", ", ") + Стр.Представление;
W>>>КонецЦикла;
W>>>
W>>>СписокФильтра — аналог TList. W>>>В 1С нет +=, по этому написал его аналог.
G>>string.Concat, string.Join. выбирай что больше нравится.
W>Чем это будет отличаться от += ?
По результату нет, по скорости — да.
W>Это разве не склейка строк?
Склейка строк разная бывает. Ботай как работают управляемые среды (1C кстати тоже).
Здравствуйте, VladD2, Вы писали:
C>>LOL. Ну представили DML в виде макросов. И что? VD>И все. Задача решена и еще к тому же статически проверяется при компиляции.
Она решена примерно на 10%. Точнее, вообще не решена, так как DML банально удобнее.
C>>Как мне загрузить объекты, сменить у части из них тип, добавить к оставшимся новое поле и заполнить его вычисленным значением? Причём так, чтобы это не отличалось от обычной работы с ORM? VD>Твой мозг поражен извращениями. Зачем менять какие то там объекты когда можно описать ДСЛ и на нем описать свои намерения?
Затем, что я хочу работать с объектами, а не записями в БД.
Здравствуйте, gandjustas, Вы писали:
G>Ты снова передергиваешь.
Да, я такой.
G>Ведь ты можешь писать += на C# и в цикле. Нормальные программисты поправят твой код, никто не пострадает. Если нету тех кто может поправить, то видимо эта группа программистов зря взялась за .NET и им стоит писать на js.
Я и пишу +=. И не надо мои мечтания затенять стрингбилдерами. Я верю в то, что += работает в с, с++, java, js, c# и работает достаточно эффективно чтоб не разбились мои мечты. Но когда _компилируемый_ ОО язык ведет себя странно с _объектами_ и проигрывает по скорости скриптовому языку это заставляет задуматься. То есть приходится думать не над логикой, а над тем как правильно писать элементарные операции. И без этого проблем хватает.
А на "нормальных" программистов ресурсов не хватило, проект еще не начал приносить деньги. Вот когда проект заматереет, тогда и пригласят "нормальных" для удержания рынка, переманят у конкурента, зацикленного на нормальности
G>>>Да пусть пишут, что с того? Твои "тесты" от этого правильнее не становятся. _>>А какой код для js правильный? _>>1) с join, который дико тормозит/тормозил на ie (на последних версиях не проверял, может оптимизировали этот костыль для конкатенации строк) _>>2) или с +=, более стабильный и предсказуемый по скорости на разных реализациях.
G>Во-первых ты привел тесты где код разный по семантике. Во-вторых ты привел код, который далек от оптимального. В-третьих ты привел сценарий, который крайне редко встречается. Миллионы строк таким образом очень мало кто клеит тупо в циклах.
1) Я не юрист, поэтому не вижу разной семантики в приведенных тестах.
2) Это тест не про то как надо правильно оптимизировать код, а про то как два языка работают с объектами в частности со строками.
3) Я привел код, который в цикле выполняет наиболее часто встречающуюся строковую операцию в моем и не только в моем коде. Пока меня не приспичит показать свою крутость — собирать строки через формат или регекспы. Крайне _часто_ встречается
G>Теперь вопрос, что ты хотел сравнить? И что ты хотел этим показать?
Повторюсь.
Когда _компилируемый_ ОО язык ведет себя странно с _объектами_ и проигрывает по скорости скриптовому языку это заставляет задуматься. C# медленнее, Java еще медленнее. А зачем такие компиляторы (для меня), если они плохо работают с родными для языка и платформы абстракциями. Это проблемы языка/платформы. Не мои проблемы.
Это я хотел сперва проверить, посмотрел, удивился и решил поделится. Вот весь мой мотив.
Здравствуйте, fin_81, Вы писали:
G>>Ведь ты можешь писать += на C# и в цикле. Нормальные программисты поправят твой код, никто не пострадает. Если нету тех кто может поправить, то видимо эта группа программистов зря взялась за .NET и им стоит писать на js. _>Я и пишу +=. И не надо мои мечтания затенять стрингбилдерами. Я верю в то, что += работает в с, с++, java, js, c# и работает достаточно эффективно чтоб не разбились мои мечты. Но когда _компилируемый_ ОО язык ведет себя странно с _объектами_ и проигрывает по скорости скриптовому языку это заставляет задуматься. То есть приходится думать не над логикой, а над тем как правильно писать элементарные операции. И без этого проблем хватает.
Ну правильно, += почти везде работает. Не работает только в "тесте" который ты привел.
_>А на "нормальных" программистов ресурсов не хватило, проект еще не начал приносить деньги. Вот когда проект заматереет, тогда и пригласят "нормальных" для удержания рынка, переманят у конкурента, зацикленного на нормальности
Некогда пилу точить — пилить надо.
G>>>>Да пусть пишут, что с того? Твои "тесты" от этого правильнее не становятся. _>>>А какой код для js правильный? _>>>1) с join, который дико тормозит/тормозил на ie (на последних версиях не проверял, может оптимизировали этот костыль для конкатенации строк) _>>>2) или с +=, более стабильный и предсказуемый по скорости на разных реализациях.
G>>Во-первых ты привел тесты где код разный по семантике. Во-вторых ты привел код, который далек от оптимального. В-третьих ты привел сценарий, который крайне редко встречается. Миллионы строк таким образом очень мало кто клеит тупо в циклах. _>1) Я не юрист, поэтому не вижу разной семантики в приведенных тестах.
Для C++ — mutable строка, для C# и JS — immutable
_>2) Это тест не про то как надо правильно оптимизировать код, а про то как два языка работают с объектами в частности со строками.
Ну ты показал что js не освобождает память, а .NET освобождает... А нахрена ты время привел, для очевидно неоптимального кода?
_>3) Я привел код, который в цикле выполняет наиболее часто встречающуюся строковую операцию в моем и не только в моем коде.
"В цикле" — уже совершенно другая операция.
_>Когда _компилируемый_ ОО язык ведет себя странно с _объектами_ и проигрывает по скорости скриптовому языку это заставляет задуматься.
В первую очередь стоит задуматься что это твой косяк (в данном случае очевидно, тебе сразу привели нормальный пример). Во вторых ты как-то упустил из виду память, js не стесняясь выжрал вообще все.
_>C# медленнее, Java еще медленнее.
Тебе привели пример где C# быстрее, ты продолжаешь повторять чушь.
_>А зачем такие компиляторы (для меня), если они плохо работают с родными для языка и платформы абстракциями. Это проблемы языка/платформы. Не мои проблемы.
Нет это именно твои проблемы, потому что ты не знаешь как использовать язык и платформу. Язык и платформа позволяют тебе сделать код быстрым и надежным, если ты этим не пользуешься, то ты баран, а не создатели языка.
_>Это я хотел сперва проверить, посмотрел, удивился и решил поделится. Вот весь мой мотив.
Все чем ты поделился — своим незнанием C#, и все.
Ты сел в лужу по самую макушку, а теперь пытаешься выкрутиться, причем совершенно неумело.
Здравствуйте, Cyberax, Вы писали:
C>сменить у части из них тип, добавить к оставшимся новое поле и заполнить его вычисленным значением?
Ну и где тут необходима динамическая типизация?
{-# LANGUAGE TypeFamilies #-}import Data.Has
-- Объявляем поля, которые будем объединять в записи:data Foo = Foo; type instance TypeOf Foo = Integer
data Bar = Bar; type instance TypeOf Bar = Double-- Конструируем из объявленных полей запись:
record = Foo ^- 2 & Bar ^- 2
-- Тип полученной записи - FieldOf Foo :&: FieldOf Bar
-- Читаем поля записи и вычисляем новое значение:
foobar r = (Bar ^. r) ** fromIntegral (Foo ^. r)
-- Объявляем еще одно поле.data Baz = Baz; type instance TypeOf Baz = Double-- Добавляем поле Baz с вычисленным значением
record' = record & Baz ^- foobar record
-- Тип новой записи будет FieldOf Foo :&: FieldOf Bar :&: FieldOf Baz
-- foobar работает и с записью типа FieldOf Foo :&: FieldOf Bar :&: FieldOf Baz,
-- потому что поля Foo и Bar у этой записи есть.
x = foobar record'
Но, конечно, по мере ухудшения решения, потребность в динамической типизации для его осуществления будет возрастать — тут я спорить не буду.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, gandjustas, Вы писали:
G>Ну правильно, += почти везде работает. Не работает только в "тесте" который ты привел.
В тесте он работает. На то что не работает я не жаловался. Я жаловался, на то что с чего это вдруг компилируемый язык работает с объектами в том же временном порядке, даже чуть медленнее, что и скриптовый/интерпретируемый. То есть у языка проблемы. Я не сравнивал присутствие/отсутствие/оптимизацию отдельных классов. Потому что тема не про реализацию стрингбилдеров в разных языках, это тема про сами языки.
_>>А на "нормальных" программистов ресурсов не хватило, проект еще не начал приносить деньги. Вот когда проект заматереет, тогда и пригласят "нормальных" для удержания рынка, переманят у конкурента, зацикленного на нормальности
G> G>Некогда пилу точить — пилить надо.
Пилу точат когда она тупая, а (внимание наезд) если пила изначально "тупая", точи, не точи, много леса не навалишь.
_>>1) Я не юрист, поэтому не вижу разной семантики в приведенных тестах. G>Для C++ — mutable строка, для C# и JS — immutable
И где разница семантики между c# и js. C++ шел отдельным пунктом, вне сравнения.
_>>2) Это тест не про то как надо правильно оптимизировать код, а про то как два языка работают с объектами в частности со строками. G>Ну ты показал что js не освобождает память, а .NET освобождает... А нахрена ты время привел, для очевидно неоптимального кода?
Тогда более "тяжелый" вариант с движком spidermonkey http://ideone.com/hl6ad
в 3 быстрее, 10 раз меньше памяти по сравнению c#(mono).
_>>3) Я привел код, который в цикле выполняет наиболее часто встречающуюся строковую операцию в моем и не только в моем коде. G>"В цикле" — уже совершенно другая операция.
Цикл нужен для создания тестовых условий. Проверяется код s += "a". И тест заставляет задуматься над скоростью работы с immutable объектами. Ибо с такими объектами "проще" работать.
_>>А зачем такие компиляторы (для меня), если они плохо работают с родными для языка и платформы абстракциями. Это проблемы языка/платформы. Не мои проблемы. G>Нет это именно твои проблемы, потому что ты не знаешь как использовать язык и платформу. Язык и платформа позволяют тебе сделать код быстрым и надежным, если ты этим не пользуешься, то ты баран, а не создатели языка.
_>>Это я хотел сперва проверить, посмотрел, удивился и решил поделится. Вот весь мой мотив. G>Все чем ты поделился — своим незнанием C#, и все. G>Ты сел в лужу по самую макушку, а теперь пытаешься выкрутиться, причем совершенно неумело.
Спасибо, ты тоже кудрявый.
Признаю свою некомпетентность и короткошерстность.
Ты че такой дерзкий!
Не буду дальше нагнетать атмосферу, я хотел поговорить о скорости языков, а не о скорости быстрого нахождения самого оптимального решения для конкретного языка. Хотел частично развеять или подтвердить (для себя тоже) мифы про скорость работы языков с базовыми абстракциями языков (в частности иммутабельных объектов).
Всем спасибо.
Извиняюсь за все негативные эмоции которые я вызвал в ваших сердцах.
Здравствуйте, fin_81, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
G>>Ну правильно, += почти везде работает. Не работает только в "тесте" который ты привел. _>В тесте он работает. На то что не работает я не жаловался. Я жаловался, на то что с чего это вдруг компилируемый язык работает с объектами в том же временном порядке, даже чуть медленнее, что и скриптовый/интерпретируемый. То есть у языка проблемы. Я не сравнивал присутствие/отсутствие/оптимизацию отдельных классов. Потому что тема не про реализацию стрингбилдеров в разных языках, это тема про сами языки.
Ты ведешь себя как дите. Ну сравни память, которую отожрал JS и .NET. Подумай головой что освобождение памяти небесплатно и поймешь разницу. Вот только ты про это не заикнулся когда тесты приводил, а когда тебя неоднократно ткнули носом в то где ты неправ ты уже целую философию выдумал про сравнение языков.
_>>>А на "нормальных" программистов ресурсов не хватило, проект еще не начал приносить деньги. Вот когда проект заматереет, тогда и пригласят "нормальных" для удержания рынка, переманят у конкурента, зацикленного на нормальности
G>> G>>Некогда пилу точить — пилить надо. _>Пилу точат когда она тупая, а (внимание наезд) если пила изначально "тупая", точи, не точи, много леса не навалишь.
Пила — это твои способности писать на каком-то языке. Ну если тупая — значит тупая.
_>>>1) Я не юрист, поэтому не вижу разной семантики в приведенных тестах. G>>Для C++ — mutable строка, для C# и JS — immutable _>И где разница семантики между c# и js. C++ шел отдельным пунктом, вне сравнения.
Разница в освобождении памяти.
_>>>2) Это тест не про то как надо правильно оптимизировать код, а про то как два языка работают с объектами в частности со строками. G>>Ну ты показал что js не освобождает память, а .NET освобождает... А нахрена ты время привел, для очевидно неоптимального кода? _>Тогда более "тяжелый" вариант с движком spidermonkey http://ideone.com/hl6ad _>в 3 быстрее, 10 раз меньше памяти по сравнению c#(mono).
А нормальный вариант кода на C# рвет любой код на JS в какашки. Только ты его в упор не видишь. У тебя какая-то избирательная слепота, наверное чтобы оправдать собственную глупость. Ну ниче, бывает.
_>>>3) Я привел код, который в цикле выполняет наиболее часто встречающуюся строковую операцию в моем и не только в моем коде. G>>"В цикле" — уже совершенно другая операция. _>Цикл нужен для создания тестовых условий. Проверяется код s += "a". И тест заставляет задуматься над скоростью работы с immutable объектами. Ибо с такими объектами "проще" работать.
Я не про внешний, а про внутренний цикл.
G>>Ты сел в лужу по самую макушку, а теперь пытаешься выкрутиться, причем совершенно неумело. _>Спасибо, ты тоже кудрявый. _>Признаю свою некомпетентность и короткошерстность.
Гы, в чем? В том что я знаю как заставить код на C# работать быстрее?
Не бывает кривых языков и кривых рантаймов, бывают подходяще средства для решения задач и не подходящие, бывают программисты, умеющие писать на языках и не умеющие.
Все что ты показал: свое неумение и выбор неподходящих средств. Не надо вокруг своих заблуждений строить философию.
Здравствуйте, anonymous, Вы писали:
O>>>Никаких шуток. Только не эмуляцию Linux, а собственно, Linux, на жаваскриптовом эмуляторе x86 железа. V>>Не взлетело. Тормозило несколько минут, а потом предложило прибить скрпт, бо он тормозит весь компьютер. Дал ему еще немного времени, но картинка так и осталась черным квадратом, так что пришлось таки прибить. A>Пока что не всякий браузер такое умеет.
Скриптовый язык, который работает только по желанию левой пятки быдлокодера -- не нужен.
Здравствуйте, quwy, Вы писали:
A>>Пока что не всякий браузер такое умеет. Q>Скриптовый язык, который работает только по желанию левой пятки быдлокодера -- не нужен.
Быдлокодер, не удосужившийся разобраться в вопросе, не нужен.
Здравствуйте, fin_81, Вы писали:
>Пусть циклы идут лесом, забыли про них. Мы сравниваем использование сущности "строка" в языках. На обоих пишем одинаковый код с использованием этой сущности для того чтобы собрать более длинную "строку". Потом сравниваем результаты.
Вот ведь как! По немецки — "цацки-пецки", а по-русски — "бутерброд"!
То есть по твоему мнению языки так и разрабатываются, да? Ну чтобы думать и знать надо было меньше и писать почти на С?
Это же целое поле для троллинга, взять конструкцию языка А и пойти к ребятам языка Б.
Есть такое мнение чтобы что-то сравнивать надо а) понимать основы сравниваемых объектов, б) принимать критику и поправки к аргументам.
>Почему я должен на одном языке заниматься premature optimization и вводить в программу другие сущности, чтобы догнать по скорости? Многие проекты не доходят до стадии вылизывания кода "бодибилдерами" . Они уже приносят деньги. И некоторое конкурентное преимущество в скорости работы += может сыграть большую роль.
Берём человека, который не знает как работает .net и даём ему деньги чтобы он сделал работу. Он выбирает .net и пишет плохой код потому, что он так писал на JS.
Какая фатальная череда несчастий. Невезучий его работодатель/заказчик.
Во-вторых: >Многие проекты не доходят до стадии вылизывания кода "бодибилдерами"
В 90% случаев хватает даже одного прохода профайлером. Если кто-то заплатил деньги можно и потратить 5 минут.
В-третьих: использование StringBuilder'а — это не premature optimization, а common sense. Вспомни Маяковского с "Нате".
В-чётвёртых: >И некоторое конкурентное преимущество в скорости работы += может сыграть большую роль.
Эта фраза особенно доставила! Ещё скажу, что *= может порой играть такую большую роль, что Гамлет нервно курит.
Как можно требовать от одного языка работать как и другой, даже если они похожи. Как можно приводить аргумент, что это "может сыграть большую роль" в случае когда код писать будет человек не знающий основ используемого языка (и в тот момент ещё свет Венеры отразится от перисто-кучевых облаков и попадёт к нему на монитор).
И кстати, а как насчёт javascript pitfalls тогда?
«История жизни – это, по существу, развитие сознания, которое завуалировано морфологией.» Пьер Тейяр де Шарден
Здравствуйте, VladD2, Вы писали:
C>>Затем, что я хочу работать с объектами, а не записями в БД. VD>Тебя мы обсуждать не будем потому как п. 5. Больше тут обсуждать не чего.
Дальше что? Статическое решение, позволяющее это сделать красиво, будет?
Если нет, то я смело на любое возражение Немерлистов могу говорить ровно теми же словами.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, VladD2, Вы писали:
C>>>Затем, что я хочу работать с объектами, а не записями в БД. VD>>Тебя мы обсуждать не будем потому как п. 5. Больше тут обсуждать не чего. C>Дальше что? Статическое решение, позволяющее это сделать красиво, будет?
Там все что нужно и так генерируется. Ты что думаешь, там люди запросы в текстовом виде пишут?
То что ты не в силах даже почитать вики никто не виноват.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
C>>Дальше что? Статическое решение, позволяющее это сделать красиво, будет? VD>Там все что нужно и так генерируется. Ты что думаешь, там люди запросы в текстовом виде пишут? VD>То что ты не в силах даже почитать вики никто не виноват.
Мне неинтересно как генерируются запросы, это я и сам знаю. Мне интересно как статически выражается изменение модели данных.
Вариант Klapaucius'а показывает как примерно это будет выглядеть на статике — не особо красиво. Если нужно менять топологию модели, то вообще всё плохо становится.
Здравствуйте, Klapaucius, Вы писали:
C>>Мне интересно как статически выражается изменение модели данных. K>Операциями над типами.
Я понял.
C>>Вариант Klapaucius'а показывает как примерно это будет выглядеть на статике — не особо красиво. K>Давайте предметно обсудим, что именно не устраивает.
Насколько я понял, у тебя просто создаются новые типы, а именованый тип изменить после создания нельзя.
C>>А на динамике всё ОК. K>Ну, это пока ничем не обоснованное заявление, которое неплохо бы подтвердить.
Ну как бы, в динамике нет проблем с типами.
Здравствуйте, Cyberax, Вы писали:
C>Насколько я понял, у тебя просто создаются новые типы, а именованый тип изменить после создания нельзя.
Ну, в Хаскеле и значения создаются новые, а не меняются после создания. Никакого отношения к ограничениям статической типизации вообще это не имеет.
Да и непонятно, зачем нужно именно изменить тип?
C>Ну как бы, в динамике нет проблем с типами.
Ну правильно: нет типов — нет проблем с типами. Зато есть проблемы без типов. Т.е. явно не все ОК.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
C>>Насколько я понял, у тебя просто создаются новые типы, а именованый тип изменить после создания нельзя K>Ну, в Хаскеле и значения создаются новые, а не меняются после создания. Никакого отношения к ограничениям статической типизации вообще это не имеет. K>Да и непонятно, зачем нужно именно изменить тип?
А каким образом к этому типу обращаться в остальном коде? Явно по версированому имени? Неудобно.
C>>Ну как бы, в динамике нет проблем с типами. K>Ну правильно: нет типов — нет проблем с типами. Зато есть проблемы без типов. Т.е. явно не все ОК.
Ну кто же спорит. Нет человекатипов — нет проблем.
Здравствуйте, Cyberax, Вы писали:
C>А каким образом к этому типу обращаться в остальном коде?
Что значит "обращатся к типу"? Функция, читающая поля записи работает и с первоначальной записью и с той, в которой добавилось поле. И будет работать с любой записью, в которой есть поля, к которым функция обращается.
C>Явно по версированому имени?
И что значит "версированное имя"? Имени у типа записи можно сказать, что и нет. Это "утиная" типизация, реализованная в библиотеке.
C>Ну кто же спорит. Нет человекатипов — нет проблем.
Ну так в том и дело — от отсутствия типов все проблемы не исчезают, да еще и новые добавляются.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, fin_81, Вы писали:
_>java медленнее http://ideone.com/evyrW результат: успешно время: 2.03s
_>js рулит. _>Хотя по выделенной памяти заметно, что js оптимизирует(забивает на) освобождение памяти
java: http://ideone.com/LaLiT
время: 0.06s
Здравствуйте, Nuzhny, Вы писали:
N>Не клеит только потому, что библиотека не позволяет. Вариант со стрингбилдером слишком многословный для современного языка. Это очевидно, как день.
Ну, если тебе синтаксис покороче, то пожалуйста:
new string('a', 1000)
Бредовой задаче идиотское решение.
А для нормальных задач есть string.Join().
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Ну кто же спорит. Нет человекатипов — нет проблем. НС>Ну и? В отличие от динамики, в статике динамически работать с данными можно. Можно даже сахарок синтаксический прикрутить, как в C#.
То есть?
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>То есть? НС>Ну то есть берешь динамическую структуру типа датасета и вперед.
А ещё можно все структуры заменить хэш-таблицами, а все вызовы — на динамические. И получить динамический язык в итоге.
Вот недавно ещё одну фишку вспомнил, которая в статических языках плохо делается — реактивное программирование.
Здравствуйте, Cyberax, Вы писали:
C>>>То есть? НС>>Ну то есть берешь динамическую структуру типа датасета и вперед. C>А ещё можно все структуры заменить хэш-таблицами, а все вызовы — на динамические.
Все то зачем? Только те что нужно. В этом — цимус.
C> И получить динамический язык в итоге.
Зачем?
C>Вот недавно ещё одну фишку вспомнил, которая в статических языках плохо делается — реактивное программирование.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>>>То есть? НС>>>Ну то есть берешь динамическую структуру типа датасета и вперед. C>>А ещё можно все структуры заменить хэш-таблицами, а все вызовы — на динамические. НС>Все то зачем? Только те что нужно. В этом — цимус.
Для того, чтобы добиться гибкости динамического языка.
C>>Вот недавно ещё одну фишку вспомнил, которая в статических языках плохо делается — реактивное программирование. НС>Чо, Rx уже отменили?
Примерно да. Он решает немного другие задачи, по сравнению с Trellis для Питона или http://knockoutjs.com/ для JS.
Здравствуйте, Cyberax, Вы писали:
C>Для того, чтобы добиться гибкости динамического языка.
Какой такой гибкости?
C>>>Вот недавно ещё одну фишку вспомнил, которая в статических языках плохо делается — реактивное программирование. НС>>Чо, Rx уже отменили? C>Примерно да.
C> Он решает немного другие задачи, по сравнению с Trellis для Питона или http://knockoutjs.com/ для JS.
Ну так раскрой мысль, что такого не хватает статически типизированным языкам.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>> Он решает немного другие задачи, по сравнению с Trellis для Питона или http://knockoutjs.com/ для JS. НС>Ну так раскрой мысль, что такого не хватает статически типизированным языкам.
Нельзя, к примеру, динамически поменять функциональность методов, чтобы отслеживать любое обращение к данным внутри наблюдаемого множества. Можно делать статический weaving, но проблема в том, что его придётся делать для всего кода и всех возможных ситуаций.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Ночной Смотрящий, Вы писали:
C>>> Он решает немного другие задачи, по сравнению с Trellis для Питона или http://knockoutjs.com/ для JS. НС>>Ну так раскрой мысль, что такого не хватает статически типизированным языкам. C>Нельзя, к примеру, динамически поменять функциональность методов, чтобы отслеживать любое обращение к данным внутри наблюдаемого множества.
А PropertyChangedBuilder из BLToolkit разве не это как раз реализует?
Здравствуйте, Константин Б., Вы писали:
НС>>>Ну так раскрой мысль, что такого не хватает статически типизированным языкам. C>>Нельзя, к примеру, динамически поменять функциональность методов, чтобы отслеживать любое обращение к данным внутри наблюдаемого множества. КБ>А PropertyChangedBuilder из BLToolkit разве не это как раз реализует?
Нет, там хитрее.
В виде псевдокода:
var a = 10;
var b = 20;
//Указываем как мы рассчитываем текст на поле ввода
form.displayField.text = function() {
return a+b; //Обычный код, может включать вызовы других функций и т.п.
}
...
a=11; //И значение в поле ввода тут же меняется.
От Rx отличие в том, что нет никакой завязки в коде на него.
Здравствуйте, Cyberax, Вы писали:
C>В виде псевдокода:
C>var a = 10;
C>var b = 20;
C>//Указываем как мы рассчитываем текст на поле ввода
C>form.displayField.text = function() {
C> return a+b; //Обычный код, может включать вызовы других функций и т.п.
C>}
C>...
C>a=11; //И значение в поле ввода тут же меняется.
Ну правильно, как я и сказал выше, динамическая типизация сопутствует плохому решению. Т.е. это такие костыли для костылей. Реактивное программирование с неконтролируемым состоянием вообще не очень хорошо сочетается.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
НС>>>>Ну так раскрой мысль, что такого не хватает статически типизированным языкам. C>>>Нельзя, к примеру, динамически поменять функциональность методов, чтобы отслеживать любое обращение к данным внутри наблюдаемого множества. КБ>>А PropertyChangedBuilder из BLToolkit разве не это как раз реализует? C>Нет, там хитрее.
C>В виде псевдокода: C>
C>var a = 10;
C>var b = 20;
C>//Указываем как мы рассчитываем текст на поле ввода
C>form.displayField.text = function() {
C> return a+b; //Обычный код, может включать вызовы других функций и т.п.
C>}
C>...
C>a=11; //И значение в поле ввода тут же меняется.
C>
C>От Rx отличие в том, что нет никакой завязки в коде на него.
Ну и на шарпе это выглядело бы как-нибудь так:
public abstract class Foo : IPropertyChanged {
public abstract int a {get;set;}
public abstract int b {get;set;}
public string c
{
get {return (a + b).ToString();}
}
}
foo = TypeAccessor.CreateInstance<Foo>()
form.displayField.DataBindings.Add(new Binding("Text", foo, "c"))
foo.a = 11
Здравствуйте, Константин Б., Вы писали:
C>>От Rx отличие в том, что нет никакой завязки в коде на него. КБ>Ну и на шарпе это выглядело бы как-нибудь так:
Не пройдёт. Во-первых, тебе надо будет всё помещать в один большой контекст.
Во-вторых:
var a = 10;
var b = 20;
//Указываем как мы рассчитываем текст на поле ввода
form.displayField.text = function() {
return a+b; //Обычный код, может включать вызовы других функций и т.п.
}
form.displayField2.text = function() {
return b^2;
}
a=11; //Пересчитается первое поле
b=12; //Пересчитаются оба поля
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
C>>>От Rx отличие в том, что нет никакой завязки в коде на него. КБ>>Ну и на шарпе это выглядело бы как-нибудь так: C>Не пройдёт. Во-первых, тебе надо будет всё помещать в один большой контекст.
Нет не надо.
C>Во-вторых: C>
C>var a = 10;
C>var b = 20;
C>//Указываем как мы рассчитываем текст на поле ввода
C>form.displayField.text = function() {
C> return a+b; //Обычный код, может включать вызовы других функций и т.п.
C>}
C>form.displayField2.text = function() {
C> return b^2;
C>}
C>a=11; //Пересчитается первое поле
C>b=12; //Пересчитаются оба поля
C>
И где такое чудо? O_o В треллисе и нокаут-жсе будут пересчитаны оба.
А такое оно тоже разрулит?
var a = 10;
var b = 20;
var c = 30;
//Указываем как мы рассчитываем текст на поле ввода
form.displayField.text = function() {
if a < 20:
return b;
else:
return c;
}
form.displayField2.text = function() {
if a < 20:
return c;
else:
return b;
}
b=12; //Пересчитаются только первое поле?
с=12; //Пересчитается только второе поле?
Здравствуйте, Константин Б., Вы писали:
КБ>И где такое чудо? O_o В треллисе и нокаут-жсе будут пересчитаны оба.
Поспорим? В Треллисе будет пересчитано только то, что зависит от изменяемой переменной.
КБ>А такое оно тоже разрулит? КБ>
КБ>var a = 10;
КБ>var b = 20;
КБ>var c = 30;
КБ>//Указываем как мы рассчитываем текст на поле ввода
КБ>form.displayField.text = function() {
КБ> if a < 20:
КБ> return b;
КБ> else:
КБ> return c;
КБ>}
КБ>form.displayField2.text = function() {
КБ> if a < 20:
КБ> return c;
КБ> else:
КБ> return b;
КБ>}
КБ>b=12; //Пересчитаются только первое поле?
КБ>с=12; //Пересчитается только второе поле?
КБ>
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>И где такое чудо? O_o В треллисе и нокаут-жсе будут пересчитаны оба. C>Поспорим? В Треллисе будет пересчитано только то, что зависит от изменяемой переменной.
Здравствуйте, Cyberax, Вы писали:
C>>> Он решает немного другие задачи, по сравнению с Trellis для Питона или http://knockoutjs.com/ для JS. НС>>Ну так раскрой мысль, что такого не хватает статически типизированным языкам. C>Нельзя, к примеру, динамически поменять функциональность методов
Это не задача
C>, чтобы отслеживать любое обращение к данным внутри наблюдаемого множества
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Нельзя, к примеру, динамически поменять функциональность методов НС>Это не задача
Это иногда бывает нужно при решении задач.
C>>, чтобы отслеживать любое обращение к данным внутри наблюдаемого множества НС>Зачем его отслеживать? http://rsdn.ru/forum/flame.comp/4347619.aspx
Здравствуйте, Cyberax, Вы писали:
C>>>Нельзя, к примеру, динамически поменять функциональность методов НС>>Это не задача C>Это иногда бывает нужно при решении задач.
Передавать обёртку аля Binding<T> (имя можно подсократить)? Если хочется абсолютно идентичного поведения — придётся повозиться с разбором expression tree, да и производительность (без emit-а) будет близка к яваскрипту.
Если чуть упростить задачу — достаточно
public Binding GetBinding(Func<Binding[], Binding> selector, params Binding[] sources)
{
}
Или, если не стоит задача "сделать один в один" — списываем систему биндингов с WPF.
Здравствуйте, Sinix, Вы писали:
S>Передавать обёртку аля Binding<T> (имя можно подсократить)? Если хочется абсолютно идентичного поведения — придётся повозиться с разбором expression tree, да и производительность (без emit-а) будет близка к яваскрипту.
Можно на динамиках сделать. Не теряя, где это возможно, статики.
S>Или, если не стоит задача "сделать один в один" — списываем систему биндингов с WPF.
+1. Только в испольнении шарпа там все печально. Нужна или доработка языка или метапрограмминг.
Здравствуйте, Константин Б., Вы писали:
КБ>>>И где такое чудо? O_o В треллисе и нокаут-жсе будут пересчитаны оба. C>>Поспорим? В Треллисе будет пересчитано только то, что зависит от изменяемой переменной. КБ>Давай
No problemo:
#!/usr/bin/python
from peak.events import trellis
def very_complex_function(a, b):
return (a+b)/2
class TestContext(trellis.Component):
trellis.attrs(a = 0, b = 5, c=10)
@trellis.perform
def show_values(self):
if (self.a>20):
print "A is greater than 20: %d" % very_complex_function(self.b,self.c)
else:
print "A is less than 20, so: %d" % self.b
tc = TestContext()
print "Now mutating self.c ..."
tc.c = 11 # Ничего не персчитается, мы не зависим от self.c сейчас
print "mutated."
print "Now mutating self.b ..."
tc.b = 12 # А вот от self.b мы зависим - пересчитается
print "mutated."
print "Now mutating self.a ..."
tc.a = 21 # Теперь зависим от b и c.
print "mutated."
print "Now mutating self.c ..."
tc.c = 5 # Так что СЕЙЧАС оно пересчитается
print "mutated."
Вывод:
A is less than 20, so: 5
Now mutating self.c ...
mutated.
Now mutating self.b ...
A is less than 20, so: 12
mutated.
Now mutating self.a ...
A is greater than 20: 11
mutated.
Now mutating self.c ...
A is greater than 20: 8
mutated.
— как такой пример на статике красиво сделать? S>Передавать обёртку аля Binding<T> (имя можно подсократить)? Если хочется абсолютно идентичного поведения — придётся повозиться с разбором expression tree, да и производительность (без emit-а) будет близка к яваскрипту.
Не получится. Точнее, придётся делать разбор произвольных функций и их интерпретацию. По сути, сделать динамику собственными руками.
C>Не получится. Точнее, придётся делать разбор произвольных функций и их интерпретацию. По сути, сделать динамику собственными руками.
Необязательно, достаточно передавать список переменных, за обновлениями которых нужно следить.
Впрочем, разбор не вызовет особых проблем, если передавать ExpressionTree<Func<T>>.
Здравствуйте, Sinix, Вы писали:
C>>Не получится. Точнее, придётся делать разбор произвольных функций и их интерпретацию. По сути, сделать динамику собственными руками. S>Необязательно, достаточно передавать список переменных, за обновлениями которых нужно следить.
Посмотри пример с Trellis'ом — этот список может динамически меняться.
Здравствуйте, Klapaucius, Вы писали:
C>>как такой пример на статике красиво сделать? K>А как такой пример красиво сделать на динамике? http://rsdn.ru/forum/flame.comp/4348289.aspx
Здравствуйте, Cyberax, Вы писали:
C>Посмотри пример с Trellis'ом — этот список может динамически меняться.
Тогда да, только разбор. Ну, или какой-нить AOP.
K>И где тут красота?
Везде Как такое сделать-то на статике? Вопрос не совсем праздный, так как я собираюсь делать подобный фреймворк для Скалы.
К примеру, оно ещё и двустороннее. Т.е. мы можем взять два поля ввода, скажем, градусы в Цельсиях и градусы в Фаренгейтах — и при изменении одного поля пересчитывается другое.
Здравствуйте, Cyberax, Вы писали: C>Здравствуйте, Константин Б., Вы писали: КБ>>>>И где такое чудо? O_o В треллисе и нокаут-жсе будут пересчитаны оба. C>>>Поспорим? В Треллисе будет пересчитано только то, что зависит от изменяемой переменной. КБ>>Давай C>No problemo:
Скрытый текст
C>
C>#!/usr/bin/python
C>from peak.events import trellis
C>def very_complex_function(a, b):
C> return (a+b)/2
C>class TestContext(trellis.Component):
C> trellis.attrs(a = 0, b = 5, c=10)
C> @trellis.perform
C> def show_values(self):
C> if (self.a>20):
C> print "A is greater than 20: %d" % very_complex_function(self.b,self.c)
C> else:
C> print "A is less than 20, so: %d" % self.b
C>tc = TestContext()
C>print "Now mutating self.c ..."
C>tc.c = 11 # Ничего не персчитается, мы не зависим от self.c сейчас
C>print "mutated."
C>print "Now mutating self.b ..."
C>tc.b = 12 # А вот от self.b мы зависим - пересчитается
C>print "mutated."
C>print "Now mutating self.a ..."
C>tc.a = 21 # Теперь зависим от b и c.
C>print "mutated."
C>print "Now mutating self.c ..."
C>tc.c = 5 # Так что СЕЙЧАС оно пересчитается
C>print "mutated."
C>
C>Вывод: C>
C>A is less than 20, so: 5
C>Now mutating self.c ...
C>mutated.
C>Now mutating self.b ...
C>A is less than 20, so: 12
C>mutated.
C>Now mutating self.a ...
C>A is greater than 20: 11
C>mutated.
C>Now mutating self.c ...
C>A is greater than 20: 8
C>mutated.
C>
Здравствуйте, Константин Б., Вы писали:
КБ>Понял в чем жульничество %) При каждом вычислении он запоминает к каким атрибутам было обращение. На шарпе можно сделать точно так же.
Ну да. На Шарпе такое сделать не очень просто — нужно статически заранее делать инструментацию всех классов. В JS с этим проще — все объекты можно в рантайме заменять на прокиски.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
КБ>>Понял в чем жульничество %) При каждом вычислении он запоминает к каким атрибутам было обращение. На шарпе можно сделать точно так же. C>Ну да. На Шарпе такое сделать не очень просто — нужно статически заранее делать инструментацию всех классов. В JS с этим проще — все объекты можно в рантайме заменять на прокиски.
Ну БлТулкит же как-то умудряется генерировать проксики в рантайме.
Здравствуйте, Cyberax, Вы писали:
C>Ну да. На Шарпе такое сделать не очень просто — нужно статически заранее делать инструментацию всех классов.
Можно и динамически, через Profiler API либо копирование IL кода в новый тип. Только вот это все к статическому контролю типов отношения не имеет — инструментация и прочие АОПообразные техники на статическую модель не влияют.
Вобщем, ты путаешь динамический рантайм и отсутствие статической проверки типов.
Здравствуйте, Константин Б., Вы писали:
C>>Ну да. На Шарпе такое сделать не очень просто — нужно статически заранее делать инструментацию всех классов. В JS с этим проще — все объекты можно в рантайме заменять на прокиски. КБ>Ну БлТулкит же как-то умудряется генерировать проксики в рантайме.
Это надо проксики для всего кода генерировать.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Константин Б., Вы писали:
C>>>Ну да. На Шарпе такое сделать не очень просто — нужно статически заранее делать инструментацию всех классов. В JS с этим проще — все объекты можно в рантайме заменять на прокиски. КБ>>Ну БлТулкит же как-то умудряется генерировать проксики в рантайме. C>Это надо проксики для всего кода генерировать.
Здравствуйте, Cyberax, Вы писали:
K>>И где тут красота? C>Везде
А я считаю — нигде.
Для меня красота и удобство — это когда можно комбинировать простые вещи простыми операциями, подчиняющимися простым законам. А тут какие-то шаманские пляски на костылях. Сразу хочу отметить, что это может быть практически оправдано и востребовано, но с красотой это ни в каком пункте не связано.
C> Как такое сделать-то на статике? Вопрос не совсем праздный, так как я собираюсь делать подобный фреймворк для Скалы. C>К примеру, оно ещё и двустороннее. Т.е. мы можем взять два поля ввода, скажем, градусы в Цельсиях и градусы в Фаренгейтах — и при изменении одного поля пересчитывается другое.
Раньше работали с "голыми" сигналами. Но это проблематично по ряду причин — если сигналы первоклассные то легко можно писать код который приведет к утечкам памяти и времени. Сейчас напишут функции
перевода туда и обратно и лифтнут их в соответствующий функтор. А уж когда и что будет пересчитывается — от реализации реактивного программирования зависит. Если push (не любят из-за плохого "разделения") — пересчитается при изменении "поля", если pull (течет память) — соотвественно при считывании. Передний край сейчас push-pull FRP, там, видимо будут и с шарингом проблемы и память будет течь. Шутка. Вообще, статей по реактивному программированию достаточно, читайте и реализуйте — какие проблемы-то?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Приходится либо забить на этот контроль либо писать дикое количество тестов, которые делает компилятор при компиляции статически типизированного языка.
и даже клипборд (/dev/clipboard) который представляет собой копию того что вкопипастено в окошко справа.
