Техническая статья Sun «Делаем Java быстрее чем С, используя LRWP»

> Это произошло из-за его стремления быть синтаксически совместимым с С

O_O

Ключевое слово operator в Си отсуствует.

>> слизывание дизайна с микрософта в пропорции 1:1 в идеологически весьма простой проге приводит к тормозам в 10-20 раз, что ты мне предлагаешь думать о яве?

> Кто тебе сказал, что OOBase на Яве? AFAIK, на Си++ оно.

Кто лучше меня знает -- пусть поправит.

Но: Требует явы. Запускает яву. Перерисовывает окна в стиле явы.

>> Это произошло из-за его стремления быть синтаксически совместимым с С

> O_O Ключевое слово operator в Си отсуствует.

Это не аргумент. Там много новых ключевых слов. Я думаю сыграло роль то, что позволив объявлять свои операторы типа ++++ мы столкнемся с тем, что а++++ из сишного кода даст ошибку "оператор ++++" не определен", а ему хотелось чтоб оно скомпилилось.

>Я думаю сыграло роль то, что позволив объявлять свои операторы типа ++++ мы столкнемся с тем, что а++++ из сишного кода даст ошибку "оператор ++++" не определен", а ему хотелось чтоб оно скомпилилось.

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

>> O_O Ключевое слово operator в Си отсуствует.

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

Это аргумент не хуже твоего. Что, если в старом Си-коде есть слова типа new, virtual или overload? Старый Си-код, который не переносили на Си++, полагалось (и полагается) компилировать Си-компилятором.

> Это аргумент не хуже твоего. Что, если в старом Си-коде есть слова типа new, virtual или overload? Старый Си-код, который не переносили на Си++, полагалось (и полагается) компилировать Си-компилятором.

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

> Я не плюсотрах,

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

Но если в плюсах это через жопу, то в яве это вообще никак.

> вместо прямого написания синтаксических макросов

кстати, ты уже написал нормальный макропроцессор для Си?

>> вместо прямого написания синтаксических макросов

> кстати, ты уже написал нормальный макропроцессор для Си?

Я пока что собираю идеи и пожелания. Из того, что я еще не изучил, и обязательно надо перед написанием -- это система шаблонов в Д.

> Из того, что я еще не изучил, и обязательно надо перед написанием -- это система шаблонов в Д.

Ну то есть макросы Немерля ты уже асилил?

И для начала (хотя бы первые версии) он будет макропроцессить в С++, а не С.

> Ну то есть макросы Немерля ты уже асилил?

Я с ними знаком, но не настолько, чтобы уверенно спорить с кем-то.

>> Я не плюсотрах,

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

Ну в D с помошью макросов можно генерировать не только код, но и 3D сцены с помощью трассировки лучей, выводя результирующий битмэп через прагму пишущую raw-байты в скомпилированный код. Оно?

>> Из того, что я еще не изучил, и обязательно надо перед написанием -- это система шаблонов в Д.

> Ну то есть макросы Немерля ты уже асилил?

Да и вообще то, что имело бы максимальное отношение результат/затраты -- это resyntaxed C++, но resyntaxed очень сильно. И по крайней мере в начале жуткая модульность препроцессора не обязательна.

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

Не сильно ли много гемора? Оно того стоит? Кстати огласите название этого замечательного языка :)

> через прагму пишущую raw-байты в скомпилированный код. Оно?

Да, это нужно. Чаще всего -- для компиляции регулярных выражений.

> Не сильно ли много гемора? Оно того стоит?

1. Программисты достойны иметь хороший язык.

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

> Кстати огласите название этого замечательного языка :)

Он либо мной не найден, либо я его не создал :-)

>> через прагму пишущую raw-байты в скомпилированный код. Оно?

>Да, это нужно. Чаще всего -- для компиляции регулярных выражений.

2 my mind сомнительный бенефит. Концептуально красиво, но компиляцию замедляет. Выигрыш по перформансу тоже скорее всего несерьезный. Избавление от позднего связываения дает плюс, однако увеличение объемов кода дает минус из-за уменьшения попаданий в кэш.

>> Из того, что я еще не изучил, и обязательно надо перед написанием -- это система шаблонов в Д.

> Ну то есть макросы Немерля ты уже асилил?

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

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

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

Нескомпиленая регулярка -- это кусок нескомпиленого исходника!!!

> плюсам нехватает малости -- возможности запрещать/перегружать оператор взятия адреса и *, и может еще чего-то в том же духе. Поэтому меня больше интересуют именно решения а-ля шаблоны.

Печально.

> Выигрыш по перформансу тоже скорее всего несерьезный.

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

> Печально.

Что печально?

> Что печально?

Что ты даже не попытаешься написать общеполезный инструмент.

> Что ты даже не попытаешься написать общеполезный инструмент.

Я то как раз думаю написать именно _общеполезный_ инструмент... правда у меня могут быть другое понимание этого слова. Как его понимаешь ты?

Желательно максимально развернутая и вовсе не обязательно строгая (т.е. вовсе необязательно доказуемая во флейме) формулировка.

> думаю написать именно _общеполезный_ инструмент... правда у меня могут быть другое понимание этого слова. Как его понимаешь ты?

Чтобы я мог использовать его в нужных точках кода. Чтобы не нужно было писать на другом языке, пусть даже очень похожем на Си (?). А ты, как я понимаю, хочешь сделать что-то вроде Cfront.

Моя аська 335157744 -- через аську мне кажется легче будет.

> Чтобы не нужно было писать на другом языке, пусть даже очень похожем на Си (?).

Как я уже говорил, мне больше всего нравится семантически С++ с СОВСЕМ другим синтаксисом.

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

Я имел в виду "если бы это можно было (и препроцессор обрабоатывал), как ты в С записал бы вызов функции с именованными параметрами?"

> Моя аська 335157744 -- через аську мне кажется легче будет.

А жабера у тебя нет?

> как ты например в С сделаешь функции с именованными параметрами?

Я и делать не стану - для этого нужен транслятор, а не макропроцессор. А вот pattern matching, guarded-блок или там каналы в стиле Occam можно сделать на продвинутом макропроцессоре, мне кажется. Примерно как в Nemerle.

>Расскажете, пожалуйста, какие программы на Java вы используете в быту(не программирование).

muCommander, Azureus

> Как я уже говорил, мне больше всего нравится семантически С++ с СОВСЕМ другим синтаксисом.

Потому что в С++ можно вложить почти любую семантику, только вид может быть устрашающий. Кое-что конечно не вкладывается, это надо добавить (если оно идейно близко), или игнорировать (если идейно далеко).

Вон некоторые на яве программят вообще без препроцессора -- и рады. Другая крайность -- "нет компилятора, есть препроцессор + оптимизатор" (но это уме мне кажется почти то что надо).

Кроме того, препроцессор может быть монолитный и заточенный под задачу (быстро пишется). А может быть модульный -- Сделай_Сам. Последний вариант кажется хорошем, но можно утонуть в попытках сделать хороший АПИ и так и не дойти до практически полезной вещи.

В общем -- имеем как всегда спектр возможностей. Вопрос -- что тебе кажется обоснованным.

А жабера у тебя нет?

list.ru.list.ru собака gmail.com

java там используется для hsqldb (http://hsqldb.org/) - базы данных.

> java там используется для hsqldb (http://hsqldb.org/) - базы данных.

Да. Но формочки рисуются в OOo Writer, и в нем все это сохраняется и безумно тормозит.

> Я и делать не стану - для этого нужен транслятор, а не макропроцессор.

> guarded-блок

Это типа как явовская syncronized ?

Еще раз повторю: предположим, я взялся написать даже и транслятор, но ты как синтаксически оформишь (проще говоря, как запишешь) syncronized функцию, чтобы это осталось С, а не стало "каким-то другим, хотя и похожим, языком" ?

Можно например поставить задачу так:

Написать транслятор с С, включащий в себя портированный синтаксический макропроцессор Немерле. В качестве выходного языка разрешается использовать не LLVM, а С.

И в общем это вполне решаемая задача.

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

> И в общем это вполне решаемая задача.

... если НЕ ВСЕ ошибки ловить своим транслятором -- т.е. проявляться они будут при компиляции сгенереного С кода ...

... конечно, можно кое-какие такие ошибки автоматически транслировать "назад", в непрепроцещенный исходник...

>> guarded-блок

> Это типа как явовская syncronized ?

Нет, это try-except-finally

> как синтаксически оформишь (проще говоря, как запишешь) syncronized функцию, чтобы это осталось С, а не стало "каким-то другим, хотя и похожим, языком" ?

Оформлю как sychronized-блок в Яве. Здесь важно то, что препроцессор вставил свое слово на месте "synchronized {" и "}", а весь остальной код гарантированно не трогал. То есть мне нужна программируемая замена текста (или AST?).

> Написать транслятор с С, включащий в себя портированный синтаксический макропроцессор Немерле. В качестве выходного языка разрешается использовать не LLVM, а С.

> И в общем это вполне решаемая задача.

В принципе. На практике, компилятор с Си, который будет транслировать реальные программы - вещь неподъемная (если не заниматься этим профессионально и fulltime).

>плюсам нехватает малости -- возможности запрещать/перегружать оператор взятия адреса и *, и может еще чего-то в том же духе.

И то и другое в плюсах есть. Перегрузка * используется для смарт-указателей и прочей подобной мутотени типа итераторов. Оператор & тоже перегружается. По моему даже видел в каком-то параноидальном синглетоне у которого невозможно было взять адрес, т.к оператор & был помещен в private секцию.

> В принципе. На практике, компилятор с Си, который будет транслировать реальные программы - вещь неподъемная (если не заниматься этим профессионально и fulltime).

Ты читай хотя бы мои уточнения, которые я пощу, иначе ОПЯТЬ НИФИГА НЕ ПОЙМЕШЬ, или вылезай в аську. Я не такой дебил, чтобы думать, что подниму _полностью_ С компилятор!!! Естественно, надо будет срезать углы!!! Это само собой разумелось!!! Речь как раз идет где и как их срезать.

или в джаббер

>Оформлю как sychronized-блок в Яве. Здесь важно то, что препроцессор вставил свое слово на месте "synchronized {" и "}", а весь остальной код гарантированно не трогал. То есть мне нужна программируемая замена текста (или AST?).

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

Если при этом надо иметь возможность "транслировать назад" ошибки, то будет совсем комфортно.

Проектирование препроцессора надо начинать с тест-кейсов. Т.е. нарисовать: слева -- исходник с sycronized, справа -- сишный код, и подумать, какие ошибки ловить (и ловить ли) препроцессору, и как о них сообщать.

Я тоже отрисовал кучу таких картинок, но только синтаксис у меня совсем не сишный.

>Почему пишете письма из броузера ниписанного на C++ а не используете написанный на Java?(такие существеют)

через несколько месяцев webkit на java портируют, можно будет и пользоваться ;) (http://weblogs.java.net/blog/ixmal/archive/2008/05/introducing_jwe.html)

> Перегрузка * используется для смарт-указателей и прочей подобной мутотени типа итераторов. Оператор & тоже перегружается.

Ты где такое видел ??? !!! пожалуста ссылки.

> через несколько месяцев webkit на java портируют, можно будет и пользоваться ;)

Если правда портируют, можно будет сравнить. Я думаю тормозить будет раза в 3. Но в любом случае от этого ГОРАЗДО больше пользы по тестированию явы, чем считать суммы от 0 до 1 000 000 000.

Может под Д такое и сделали. Но под С++ явно какие-то проблемы были... может new не мог возвращать shared_ptr<MyClass>.

> Ты читай хотя бы мои уточнения, которые я пощу, иначе ОПЯТЬ НИФИГА НЕ ПОЙМЕШЬ

Не кричи. Я читаю всё, что ты пишешшь.

> Естественно, надо будет срезать углы!!!

Это ты про компиляцию не в LLVM, а в Си? Я это читал, и с учетом этого говорил.

Что-то твой жабер не отвечает.