[Java][Опрос] Откуда такая ненависть?

Ну, что есть в Убунте, то и поставил :) Всё равно вышла лучше чистой Java.

>ВовтОрых, Java тоже старой версии

Что, 1.7 зарелизили? :D

>ну а time под Windows запустить невозможно, поэтому непонятно как прогнать тесты под вендой?

Юзай FAR Manager. К нему есть таймерные плагины. Хотя точность ниже будет. В любом случае, винда не так интересна :)

Нет, Java(TM) SE Runtime Environment (build 1.6.0_07-b06) Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)

>Юзай FAR Manager. К нему есть таймерные плагины. Хотя точность ниже будет. В любом случае, винда не так интересна :)

95% юзает винду, это нишевый linux не так интересен. А вывод time можно было бы встроить в бенчмарк.

Да и вообще, что за тест фибоначчи? Что он измеряет? Создание объектов? или что?

Вот только таким образом не разделить user от system. Гонять под nice -19? И то будет большая погрешность.

>Что он измеряет? Создание объектов? или что?

Да. Объекты + условия + простая арифметика.

на жабе? о ужас. финансовую математику пишут на эйфеле с контрактами, CL и хаскелле.

взять msys или cygwin и bash/zsh оттуда

Блин. Ты функциональное программирование тестируй! По настоящему высокоуровневые фичи, а не примитивный синтаксический сахар.

Кто так измеряет вообще? Время старта VM надо отбрасывать, считать на разогретом.

Ну и какое эта ерунда имеет отношение к высокоуровневому программированию.

Лучше, например, парсер для более-менее сложного языка (e.g., XML), написанный в чисто функциональном стиле (на комбинаторах, как в Parsec), и посмотреть, насколько сольёт JVM тому же .NET-у или рантайму OCaml-а.

«Объектный Фибоначчи» показывает загрузку на типичных современных задачах. Создание объектов, вызовы методов.

Придумай аналогичный и практичный метод для ФП. Да ещё и работающий в широком спектре УЯП.

Поэтому Java за тест 10 расчётов и делает. Потому, как самый долгий стартап. У всего остального - много меньше, либо ниже уровня шума. В описании я указывал.

Да, вот так они и измеряют. А потом у них жаба тормозит, а PHP и OCaml летают. Даже измерить толком не могут, а уже лезут анализировать на ЛОР

Основная часть современного высокоуровневого массового прикладного программирования - именно оперирование объектами.

>Лучше, например, парсер для более-менее сложного языка (e.g., XML)

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

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

Сделай лучше.

Глупости говоришь. Сам не понимаешь, что "оперирование объектами" - понятие широкое?

> Задача, во-первых, весьма специфичная

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

> во-вторых, решаемая стандартными библиотеками.

А эту херню ты зачем сказал? Задача - не распарсить XML, а протестировать типичную для функциональных языков нагрузку. То есть, реализовать именно комбинаторный recursive descent парсер. Не хочешь XML - возьми любой другой язык, который стандартными средствами не парсится. Возьми такой, который в LALR(1) не выражается адекватно, чтоб выбора не было и надо было непременно использовать LL(\infty).

> но это будет тест не для прикладного, а системного программирования.

Вывод - ни хрена ты про прикладное программирование не знаешь.

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

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

> Создание объектов, вызовы методов.

У тебя мозги зашоренны напрочь. Ты мыслишь только в рамках Жабского подхода, и при этом пытаешься тут доказывать, что ущербная Жабская VM годится и для других, более высокоуровневых подходов. При этом ты явно вообще не понимаешь, как эти другие семантики выглядят. Что ты при таком уровне знаний тестировать собрался?!?

> Придумай аналогичный и практичный метод для ФП. Да ещё и работающий в широком спектре УЯП.

Я уже привел пример наиболее типичной нагрузки - recursive descent parser.

Сделай тест лучше. Я тоже что угодно обосрать могу :)

Кстати, я, например, полагаю, что ты не изучал в ВУЗе спецкурс планирования эксперимента. Я прав?

Значит у нас с тобой просто очень разные представления о «типичных нагрузках». Напиши свой вариант тестов - оценим быстродействие и по нему.

На Java я довольно мало программировал. Если ты про императивный подход вообще - да. У меня им мозги прилично подпорчены. В основном из-за Thinkig Forth.

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

Мои представления основаны на практике. Твои - от балды.

> Напиши свой вариант тестов - оценим быстродействие и по нему. Возможно, если найду время. Писать аналог Parsec-а на голой Жабе - занятие весьма неблагодарное.

Именно! Ну так откуда тогда ты взял свой странный вывод о том, что JVM вообще для реализации других парадигм подходит, если ты их, другие парадигмы, не понимаешь?

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

Тебе так кажется. libastral свой пересобери.

>Возможно, если найду время.

То есть никогда. Типичная отмазка.

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

Время холодного старта - это не незначащий параметр. Не ламери так больше.

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

> типичную загрузку современных объектных систем.

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

Возьми мои тесты. Подправь с учётом старта VM. Если мой ряд принципиально изменится - я осёл. Если останется принципиально тем же - то ты неуч. Берёшься доказать свою правоту?

Безусловно я имел в виду императивные языки. Я выше писал про отравленность восприятия :)

>Это не является типичной загрузкой. Ты не в теме.

Для меня - является. И не в теме - ты. Что дальше? :D

...

Давай посмотрим на десктопы, за которыми сидим и пересчитаем программы, где актуален объектный подход, а где - иной (кстати, укажи точнее, какой, ибо «функциональный» - слишком обще).

Потом посмотрим на типичный LAMP/IIS-сервер с той же целью.

Это вместе взятое - процентов 90, наверное, если не больше всех вычислительных задач.

Поправь, (с конкретикой и деталями) если я не прав.

Так тебе же сразу было сказано про другие парадигмы, про высокоуровневые декларативные языки? Зачем ты тогда вообще весь этот спор затеял?

> Для меня - является. И не в теме - ты. Что дальше? :D

Ну, ты только ещё больше упал в моих глазах. Вместо того, чтоб разобраться - упираешься. Бравируешь безграмотностью и ограниченностью. Некрасиво это.

> Давай посмотрим на десктопы, за которыми сидим и пересчитаем программы, где актуален объектный подход, а где - иной (кстати, укажи точнее, какой, ибо «функциональный» - слишком обще).

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

> Потом посмотрим на типичный LAMP/IIS-сервер с той же целью.

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

> Это вместе взятое - процентов 90,

Процентов 10 максимум.

Возьмём, к примеру, такую десктопную задачу, как веб-бровзер, с поддержкой flash и javascript. Догадываешься, что нагрузка в таких задачах и близко не похожа на твою фибоначчу?

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

>Мы, кажется, про ынтырпрайз говорили.

Тебе кажется. Лично я говорю про программирование в целом. Обобщение - это удел недоучек.

>Возьмём, к примеру, такую десктопную задачу, как веб-бровзер, с поддержкой flash и javascript. Догадываешься, что нагрузка в таких задачах и близко не похожа на твою фибоначчу?

Гораздо ближе, чем парсинг XML :) (это хорошо, что ты flash и javascript добавил, а то парсинг HTML-деревьев концептуально уже ближе).

Кроме того, есть браузеры на Си, Си++, Java. Но я не видел ни одного браузера на ФЯП. Не подкинешь мне ссылочек на такие? :)

Как думаешь, почему так?

другой_анонимус> Closure, http://common-lisp.net/project/closure/quickstart.html http://common-lisp.net/project/closure/ (хотя лисп не совсем чистый ФЯП)

(Там чуть выше только что спрашивали про Flash и JavaScript... Как с ними в указанном браузере? И, надеюсь, они тоже на ФЯП? :D )

но в целом яваскрипт не нужен, если есть скриптинг на Common Lisp, см. http://www.progmatism.com/software/kamen/index.php

Потенциально была бы польза, если бы JS компилировался в Common lisp, HTML компилировался в тот же Common Lisp, и это бы всё кешировалось на уровне структурных блоков. Тогда это было бы эффективнее того же JS+движок-интерпретатор+"браузер на XUL поверх JS поверх однопоточного интерпретатора".

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

> Тебе кажется. Лично я говорю про программирование в целом.

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

> Обобщение - это удел недоучек.

"Лично я говорю про программирование в целом."

> Гораздо ближе, чем парсинг XML :)

Ты, похоже, не представляешь себе, как recursive descent parsing работает. Ламер.

> это хорошо, что ты flash и javascript добавил, а то парсинг HTML-деревьев концептуально уже ближе)

Как работают интерпретаторы флеша и жабаскрипта ты тоже не знаешь. Позорище!

> Как думаешь, почему так?

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

И при чём тут это? Заметь, даже тогда спор тоже не я затеивал :)

>Мне плевать, о чем ты говоришь.

Тогда можешь дальше общаться сам с собою.

>Ты, похоже, не представляешь себе, как recursive descent parsing работает. Ламер.

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

>Как работают интерпретаторы флеша и жабаскрипта ты тоже не знаешь. Позорище!

Я тебе уже говорил, что libastral тебе патчить надо. Он постоянно промахивается.

>Потому, что они годами пишутся. Никто just for fun за бровзер не возьмется

Тоже ответ. Почему-то на Си/Си++/Java браузеры пишут, в том числе и JustForFun, в том числе и в последнее время, а на ФЯП - нет. Почему тот же WebKit, явно не отягащённый наследственностью, был написан опять на Си, но не на хотя бы O'Caml?

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

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

И после этого, когда нормальные источники стали доступны (кстати, они лет тридцать как доступны - ну ты и дед!), ты доучиваться не стал? Ну точно ламер. Ламеры учиться не любят.

> Я тебе уже говорил, что libastral тебе патчить надо. Он постоянно промахивается.

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

кстати, да. Краткий ликбез:

1. Flash : виртуальная машина, байткод, ActionScript на базе Tamarin
2. JS:
a) Tamarin в флеше или Mozilla, внутри форт-подобный байткод см. http://wiki.forth.org.ru/Tamarin
б) SquirrelFish в WebKit, http://webkit.org/blog/189/announcing-squirrelfish/ , см. список литературы. Виртуальная машина для быстрой интерпретации, регистровый байт-код вместо стекового, оценка эффективности интерпретации.

3. и в общем-то, JS -- функциональный язык, да.
http://www.hunlock.com/blogs/Functional_Javascript

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

> но не на хотя бы O'Caml?

чисто технически ничто этому не мешает. Вот hv3 в tkhtml строился на основе правил, которые автоматически генерировались из спецификации CSS, HTML. То есть, мы получаем парсер, который автоматически правильно удовлетворяет спецификации. Плюс набор тестов если что-то можно/проще разобрать человеку а не программе.

Сам виджет правда на Си. Но уже когда есть более-менее готовый набор правил, его всё равно на каком языке писать. Можно и на O'Caml.

кстати, кто смотрел
http://www.imdb.com/title/tt0088000/ ?

/me уходит, бормоча под нос *Lambda Lambda Lambda Lambda*

И что? Какое это отношение имеет к тому «кто первый начал»? Это что, первые сообщения в теме? Ты, вообще, в какой реальности сейчас? :D

>ты доучиваться не стал?

Учусь понемногу. Но это сегодня не самоцель. Лет через 10 и ты это поймёшь.

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

Походу, тебе не только libastral надо патчить, но и обычный OCR. Или, как минимум, логический блок.

Такое моё утверждение - в студию.

...

Впрочем, ладно, разок не поленюсь откатать, хоть и по GPRS: «Возьмём, к примеру, такую десктопную задачу, как [...] flash и javascript.» --> «Гораздо ближе, чем парсинг XML :)»

Как теперь из утверждения, что обработка flash и javascript ближе к работе с объектами, чем парсинг XML, ты получаешь утверждение «нагрузка на таком интерпретаторе похожа на твой идиотский тест»?

Ты точно высыпаешься достаточно?

Чисто теоретически не только не мешает, но даже способствует. Но чисто практически - облом.

О чём я и говорю.