Глава Oracle считает что OpenOffice нужно переделать под JavaFX

> Кстати, такое лёгкое троллоло: C++ std::map<std::string,bool> работает в 10 (десять) раз медленнее чем java.util.HashMap<String, Boolean>

ТОЛСТО. http://www.sgi.com/tech/stl/Map.html : "Map is a Sorted Associative Container". Давайте хеши сравнивать с хешами.

Ларри дело говорит. Ооо надо использовать все свои отличия от MSOffice. Жава - стандарт для всяких энтерпрайз-приложений. Если их разрабам нужен опенофис, они должны такую возможность получить.

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

Модель Оракла - бесплатная клиентская часть и прочая инфраструктура (линукс), а бабло брать за БД и энтерпрайз-аппликухи. Причем они хотят поставлять все решение, целиком, включая железо (возможно для этого Сан и купили). Очевидно что клиентская часть (jvm и jar'ы с Oooo) в этом случае должна быть бесплатной и быть везде, чтоб народ к ней был к ней привыкши.

Перечитай - я написал что просто описался и сравнивал HashMap vs hash_map. Отчасти проблема в том что std::string кешировать хешкоды не умеет.

> Как раз наоборот - гибкость у него вполне, HashMap вызывает только equals & hashCode. Реализовать можешь как угодно.

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

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

2. Поскольку в Java класс String является immutable, то сравнивать модифицируемые плюсовые строчки стоит не с ним, а, скажем, со StringBuffer'ом. Хотя, конечно, для данной задачи mutable-объекты часто излишество, и можно обойтись чем-то более быстрым, начиная с const std::string и заканчивая, где это возможно и разумно, специализированными строчными объектами, чьи хэш коды насчитаны прямо в момент инициализации или даже компиляции (разумеется, автоматически). Хотите посравнивать эффективность HashMap<String,...> и map<int,...> ? :)

3. Сборщик мусора не является чем-то таким особенно джаво-специфичным. Более того, сборщики мусора есть и для C++, не бог весть какая космическая технология. Однако, стоит заметить, что там, где у проектировщика на C++ есть возможность сесть и, немножко подумав и четко специфицировав время жизни того или иного объекта, отказаться от использовании кучи вообще или выбрать кучку, подходящую именно для объектов такого типа, проектировщику на Java приходится полагаться на технический гений индусских программистов корпораций Сан и Оракл и хорошее к себе отношение и здравый смысл господ МаНили и Эллисона.

В общем и целом +1, но:

1. Не понял пр чем здесь отличия мсо и оо.

2. собственно вопрос чем поможет javafx??

>возможность использования не-дефолтной хэш-функции скорее призрачна.

Стандартно реализуется при помощи классов-обёрток. Не шибко красяво, но и требуется редко.

>со StringBuffer'ом.

Со StringBuilder ;) Не, она для этого совсем не предназначен - у него даже hashCode & equals не переопределён.И это правильно - использование в качестве ключа мутабл-обектов верный путь к раку мозга.

>Сборщик мусора не является чем-то таким особенно джаво-специфичным.

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

>на C++ есть возможность сесть и, немножко подумав и четко специфицировав время жизни того или иного объекта

На Джаве реализуется пулом объектов. Нужен очень редко - ибо аллокация в джаве очень быстрая (быстрее плюсовой).

>Интересно, а ванильную сановскую сборку кто-нибудь использует?

Fedora

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

> 1. Не понял пр чем здесь отличия мсо и оо.

отличие в том, что майкрософту будет слабо начать бесплатно распространять мс офис, а тем более заопенсорсить и открыть его. А Оооо уже открыт, терять тут нечего. Значит, любое решение, в котором нужны интегрированные куски офиса, сану/ораклу сделать проще чем майкрософту. Появление и повсеместное распространение libooo.jar для сана/оракла будет только позитивом. МС выпустить бесплатную libmsoffice.dll просто забоится.

> 2. собственно вопрос чем поможет javafx??

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

как пользователю, мне не очень отход от веба импонирует. Но

1. джаверы и оракл традиционно коряво работали c вебом (url не сохранить, back/forward не работают и т д). толку от веб-ности было только что не надо клиента скачивать-запускать.

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

> Стандартно реализуется при помощи классов-обёрток. Не шибко красяво, но и требуется редко.

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

> Со StringBuilder ;) Не, она для этого совсем не предназначен - у него даже hashCode & equals не переопределён.И это правильно - использование в качестве ключа мутабл-обектов верный путь к раку мозга.

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

Но в сторону обвинения в геноциде, вернёмся к техническим вопросам. Хотите ли Вы провести сравнение эффективности java.util.HashMap<String, ...> и std::map<int,... > ?

> ибо аллокация в джаве очень быстрая (быстрее плюсовой).

Хы-хы, какой плюсовой? В самом расстандартном GCC libstdc+++ для объектов размером до 8, кажется, байт штатно используется нечто вроде арены. Ну и, это, кого не устраивает стандартный аллокатор для объектов какого-либо типа или какого-либо использования - подкладывают свои. Получается, чес-слово, неплохо.

> Хотите ли Вы провести сравнение эффективности

Не, мы же так и написали - хотим троллить! Мне нужен был быстрое отоброжение из строк в числа. Задач об отображении строк во-что-либо очень часто встречается, наверно одна из самых частых задач для отображений =). При этом писать самому не хотелось. Я и взял стандартное решение на джаве и на с++, и за бенчмаркил.

>Итак, чей мозг Вы пытаетесь угробить, доверчивых и беззащитных ЛОРовцев?

:D

>Хы-хы, какой плюсовой? В самом расстандартном GCC libstdc+++ для объектов размером до 8, кажется,

Ну, 8 - это совсем не о чём =). Кстати, у libstdc++ (у вашей что то плюсов многовато =) стандартной библиотеки по размеру оверхед существенный, гугл вон свой с блекджеокм-и-шлюхам написал более эффективный и с меньшим оверхедом по памяти, на гуглокоде лежит.

> lyx в разы удобнее для набора мат. формул. Причем он еще и быстрый. Вот его бы чуть-чуть допилить...

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

В LyX, конечно, есть замечательная вводная инструкция и другая документация, но кто её станет читать, в наше-то время?..

Но доделать было бы неплохо, наверно. Ещё бы дождаться LaTeX3, вот тогда заживём.

> Не, мы же так и написали - хотим троллить!.. Я и взял стандартное решение на джаве и на с++, и за бенчмаркил.

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

> Ну, 8 - это совсем не о чём =). Кстати, у libstdc++ (у вашей что то плюсов многовато =) стандартной библиотеки по размеру оверхед существенный, гугл вон свой с блекджеокм-и-шлюхам написал более эффективный и с меньшим оверхедом по памяти, на гуглокоде лежит.

Хых. Они и libc свою написали, тоже, типа, ради размера и скорости. Я, заметьте, нигде и не утверждал, что у GCC самый разэффективный рантайм. Он просто есть, и предлагает неплохое соответствие стандартам...

А что касается "гугл и C++" - не далее как в пятницу наблюдал не слишком успешные попытки взлететь (то есть, начать всерьез портирование некоторого нашего большого плюсового приложения) на Android. Оказалось, что родная андроидная libstdc++ собрана без исключений (-fno-exceptions). Более того, своя сборка libstdc++ тоже не катит, т.к. у LD тамошнего в настоящее время некоторых мозгов не хватает, не успели дописать (по состоянию на 2 июня).

Так что, я бы не полагался всерьёз на рассказы о том, как крут из замечателен, по крайней мере, пока, гугловый фреймворк Да, и dalvik у них тоже вряд ли проходит сертификацию :)

> А будет ли эффект? Всё равно человек, пишущий в текстовом процессоре, думает в других категориях, нежели человек, пишущий (где угодно) с помощью LaTeX.

lyx это НЕ редактор LaTeX. Фактически lyx это wysiwyg редактор -- например, таблица это прямогольник из клеточек (а не клизма из макр теха), можно удалить строку, вставить столбец. Дробь это горизонтальная линия, над и под которой можно ходить курсором (в отличии от говно-ooo-math). К этому идет доп. бонус пользования макросами теха (но если хочется, их можно не юзать).

>lyx это wysiwyg редактор

Нет, он WYSIWY_M_ редактор. И именно по этому у него достаточно узкая аудитория.

>Поскольку в Java класс String является immutable, то сравнивать модифицируемые плюсовые строчки стоит не с ним, а, скажем, со StringBuffer'ом. Хотя, конечно, для данной задачи mutable-объекты часто излишество,

Разговор ниачем, т.к изменение ключа прямо в std::map-е это undefined behavior - надо удалить старый ключ и засунуть новый. Никакой оптимизации алгоритма для const-ключей там не производится.

>и можно обойтись чем-то более быстрым, начиная с const std::string

Это типичное плюсофильское теоретическое рассуждение. Квалификатор const на перформанс может влиять только в теории, на практике это работает максимум как статический assert для самопроверки. Квалификатор restrict из c99, говорят, работает лучше.

>и заканчивая, где это возможно и разумно, специализированными строчными объектами,

А перефасовка в std::string на границе модуля сожрет весь профит.

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

Темплейтовый движок из C++ стринговые литералы не умеет парсить.

>ТОЛСТО. http://www.sgi.com/tech/stl/Map.html : "Map is a Sorted Associative Container". Давайте хеши сравнивать с хешами.

Сбалансированное дерево для плюсовых стрингов в принципе может работать лучше чем std::tr1::unordered*, т.к в подавляющем большинстве случаев там будут сравниваться один или два первых символа в стринге. А в хешевом варианте он будет хешировать каждую строку перед тем как начать поиск в хеше. Можно, конечно, добавить поле с хешем непосредственно в std::string, но ведь пользователь может предоставлять свою хеш-функцию в качестве темплейтного аргумента так что мимо.

> Разговор ниачем, т.к изменение ключа прямо в std::map-е это undefined behavior

Речь про то, что java.util.String имеет полное право насчитывать этот хэш один раз, чуть ни прямо при создании, а std::string, вообще говоря, нет. Так что, поэтому и предлагалось сравнивать яблоки с яблоками.

Насчёт const - оно по-всякому бывает, но, вероятно, да, при засовывании в map/hash_map выигрыша не будет. По крайней мере, "на обычных порошках".

> А перефасовка в std::string на границе модуля сожрет весь профит

Это, реально, зависит. Моё первое утверждение по теме звучало как "оптимизировать надо в масштабах проекта".

> Темплейтовый движок из C++ стринговые литералы не умеет парсить.

А это здесь при чём? :) Если строчки фиксированы в момент компиляции, то скормить их прямо там какому-нибудь PerfectHash'у - не бог весть какая магия. Верьте мне, я делал нечто подобное...

>>lyx это wysiwyg редактор

> Нет, он WYSIWY_M_ редактор. И именно по этому у него достаточно узкая аудитория.

Ты не процитировал очень важное слово "фактически". _M_ я прекрасно знаю.

> Нет, он WYSIWY_M_ редактор. И именно по этому у него достаточно узкая аудитория.

Ну так давай сравним именно wysiwigG-ность ooo-math и lyx на примере набора формул с матрицами и дробями. (а _М_ -- это бесплатный бонус)

* wysiwyG-ность

>Ну так давай сравним именно wysiwigG-ность ooo-math и lyx на примере набора формул

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

>ooo-math

Что это? в ОО формулы набираются на техоподобном языке. без всякого WYSIWYG. за что я его и люблю.

> А что, набор формул - это такой очень коммон юзкейз? Там, где они превалируют - достаточно узкая область.

Предложи свою область.

З.Ы. Жирный шрифт, размер шрифта, списки, таблицы -- это lyx-е wysiwyg-но.

З.Ы.Ы. html-формы в lyx-e никак не реализованы, но я собственно и предлагал его допилить.

> ОО формулы набираются на техоподобном языке. без всякого WYSIWYG. за что я его и люблю.

Подозреваю, что юзер-дефайнд макросов у него нет. Тогда зачем он сдался? И еще и не WYSIWYG.

>Подозреваю, что юзер-дефайнд макросов у него нет.

Формулы полюбому так вводить удобнее. И без макросов. Тем более после теха.

>Предложи свою область.

Простой текст с картинками и простым форматированием. В Lyx я не вижу разбиения на страницы, картинки отображаются не так, как будут на листе. Это не удобно.

>таблицы -- это lyx-е wysiwyg-но.

Таблицы - нет.

Согласитесь - по вот этому

http://picasaweb.google.com/lh/photo/zlzLyYKF4OqDuiaxnnXJZg?feat=directlink

вот это -

http://picasaweb.google.com/lh/photo/zcWzoKBvuvfrVB67qW-oXg?feat=directlink

угадать сложно.

я считаю что Oracle надо переделать под FOSS

> угадать сложно.

Претензия того же типа "Сноски там тоже показываются внутри текста, и ее расположение внизу страницы угадать сложно".

s/ее/их/

Так что не соглашусь. Тот, кому сложно угадать, видимо не знает float alingment.

Ага. А как я должен был угадать, что картинка не влезет на страницу? libastral?

Да не нужен мне ваш флоат алгнмент. Мне картинку вставить надо. При чём именно в это конкретное место - так текст смотриться лучше. ;)

>Претензия того же типа "Сноски там тоже показываются внутри текста, и ее расположение внизу страницы угадать сложно".

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

> lyx это НЕ редактор LaTeX. Фактически lyx это wysiwyg редактор -- например, таблица это прямогольник из клеточек (а не клизма из макр теха), можно удалить строку, вставить столбец.

Ну это всё понятно, там кое-что действительно удобно. Например, те же таблицы. А вот формулы, мне кажется, так неудобно набирать. Если бы они в другом окне отображались и обновлялись по запросу, было бы лучше (кстати, так в OOMath сделано, но там набирать сложную или объемную математику ужасно).

Тут другое. Можно ли вообще делать структурную разметку, не оформляя текст структурно? Не поэтому ли до сих пор нет приличных конвертеров LaTeX-ODT?

Да и потом, сложнее всего как раз не писать в соответствии с готовым стилем, а менять сам стиль.

> А вот формулы, мне кажется, так неудобно набирать. Если бы они в другом окне отображались и обновлялись по запросу, было бы лучше (кстати, так в OOMath сделано, но там набирать сложную или объемную математику ужасно).

?

формулы ты можешь набирать как визивгно, так и *печатая* \ln^5 x_3

> формулы ты можешь набирать как визивгно, так и *печатая* \ln^5 x_3

То есть можно печатать формулу, а она через n секунд бездействия с моей стороны или по нажатию клавиатурной комбинации/кнопки отобразится as-is в другом окне? То есть так, как в Kile, но чтобы мне не надо было выделять формулу (отображается одна строчка или вся выключная формула).

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

> То есть можно печатать формулу, а она через n секунд бездействия с моей стороны или по нажатию клавиатурной комбинации/кнопки отобразится as-is в другом окне?

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