[image]

[Конкурс] Транслятор языка

 
1 7 8 9 10 11 12 13
EE Татарин #20.08.2008 15:15
+
-
edit
 

Татарин

координатор
★★★★★
Кстати, Роман, разве ты не член комиссии? Где твои выводы-то?
   
CA tarasv #20.08.2008 16:21  @Реконструктор#20.08.2008 10:14
+
-
edit
 

tarasv

аксакал

tarasv>> А не хотите строчечку где определен m_pOperators общественности показать, очень познавательно выглядит и прекрасно характеризует вас как профессионала.
Реконструктор> Тоесть?

#define OP_COUNT 100
...
IOperator* m_pOperators[OP_COUNT];

То что есть - входная программа в 100 и более операторов отправляет ваш интерпретатор исполнять мусор из памяти. Программа в которой больше 256ти переменных затирает их значениями область памяти где у вас хранятся константы, а уж если, не дай бог, констант будет больше 256 (ну или переменных больше 512) то наступает полный коллапс управления переменными. И у вас хватает смелости публиковать такой код и поучать Сергея как надо проектировать? Может вы для начала банально кодировать научитесь?
   
BG Реконструктор #20.08.2008 16:56
+
-
edit
 
Разумеется. Задумка была под конец развертывать "программу" в списочно-линейный или индексно-линейный вид, что приведет к вымираню многих временных вещей, в т.ч. и этой декларации.
А сейчас, домашнее задание: Почему мусор из памяти выполнятся не будет, и что конкретно произойдет, если напишем m_pOperators[OP_COUNT+1]->Execute()?
   
CA tarasv #20.08.2008 17:03  @Сергей-4030#20.08.2008 11:14
+
-
edit
 

tarasv

аксакал

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

Когдато, лет так 15 назад, Visual C++ был прорывом, но сейчас это очень заурядная среда разработки. Не пробовал Eclips для C++ поэтому сказать сложно, но удобство работы во многом зависит от языка, в той-же студии поддержка разработки для C# намного удобней чем то что там есть для C++. Когда в С++ просишь перейдти с точки использования метода в коде на его определение или реализацию студия с грехом пополам но обычно их находит но обратная задача (найдти все точки использования) решается фактически grep-ом да еще далеко не по всем файлам которые будут в сборке. C++ действительно очень запутанный и реализовать в IDE поддержку разработки для него гораздо сложнее чем для C# или Java. Хотя некоторые убеждены что Микрософт сознательно забил на развитие найтивного С++ в студии, чтобы пересадить всех на .NET.
   
+
-
edit
 

Kernel3

аксакал

tarasv> Когда в С++ просишь перейдти с точки использования метода в коде на его определение или реализацию студия с грехом пополам но обычно их находит...
Visual Assist помогает. Но не во всех случаях :)
tarasv> но обратная задача (найдти все точки использования) решается фактически grep-ом да еще далеко не по всем файлам которые будут в сборке.
Гм. Оно медленно, но таки по всем файлам проекта :) Если не включать используемые в сборке файлы в состав проекта, то, конечно, будут проблемы, да :):)
   
US Сергей-4030 #20.08.2008 17:53  @Balancer#20.08.2008 13:49
+
-
edit
 

Сергей-4030

исключающий третье
★★
Balancer> Я сравнивал JVM с Mono ( Производительность языков. Объектный Фибоначчи :) ) и пришёл к выводу, что виртуальная машина от Sun немного быстрее Mono (и, скорее всего сопоставима по скорости с MS .NET, но его тестировать не на чем), но на .net получаются более эффективные трансляторы других языков. А это ему большой плюс.

Джаву сильно тормозит ее схема безопасности. Собственно, поэтому в байт-код Java сейчас транслируется, по большому счету, только сама Java. А у MS - не только C#. Хорошо ли это или плохо, я не знаю, время покажет. Эффективность важна, но защищенность важна тоже.
   
US Сергей-4030 #20.08.2008 17:57  @Реконструктор#20.08.2008 16:56
+
-
edit
 

Сергей-4030

исключающий третье
★★
Реконструктор> А сейчас, домашнее задание: Почему мусор из памяти выполнятся не будет, и что конкретно произойдет, если напишем m_pOperators[OP_COUNT+1]->Execute()?

Реконструктор, надоели твои понты, честное слово. Поругались и хватит. Давай уже хоть что-то работающее роди.
   
US Сергей-4030 #20.08.2008 18:00  @Татарин#20.08.2008 15:13
+
-
edit
 

Сергей-4030

исключающий третье
★★
Татарин>>> Скажем, на данном этапе ничего напрямую сравнимого ASP .NET у явщиков, вроде, нет.
Balancer>> Я почти не в курсе, что там есть в ASP, но если учитывать ту малость, что я представляю, то разве не являются аналогами Tomcat, Resin, JBoss, etc...?
Татарин> Ага. Являются. Но они покрывают лишь малую часть, не всегда удобно сочетаются и т.д.
Татарин> В том-то и фишка, что напрямую сравнить это с платформой от МС - нельзя.

Ну, а зачем напрямую сравнивать? У Java есть все инструменты J2EE. Ее критикуют за сложность использования, но вроде в отсутствии функциональности никто не обвиняет.
   
BG Реконструктор #20.08.2008 18:06  @Сергей-4030#20.08.2008 17:53
+
-
edit
 
Сергей-4030> Джаву сильно тормозит ее схема безопасности. Собственно, поэтому в байт-код Java сейчас транслируется, по большому счету, только сама Java. А у MS - не только C#. Хорошо ли это или плохо, я не знаю, время покажет. Эффективность важна, но защищенность важна тоже.

Виндовс крашнуть может только драйвер. А потребителю пофиг как умрет программа - с GPF или с Runtime Error.
   
+
-
edit
 

tarasv

аксакал

tarasv>> но обратная задача (найдти все точки использования) решается фактически grep-ом да еще далеко не по всем файлам которые будут в сборке.
Kernel3> Гм. Оно медленно, но таки по всем файлам проекта :) Если не включать используемые в сборке файлы в состав проекта, то, конечно, будут проблемы, да :):)

Да это я погорячился - проблемы будут в том случае если сдуру назвал поля разных классов одинаково ;)
   
US Сергей-4030 #20.08.2008 19:22  @Реконструктор#20.08.2008 18:06
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Джаву сильно тормозит ее схема безопасности. Собственно, поэтому в байт-код Java сейчас транслируется, по большому счету, только сама Java. А у MS - не только C#. Хорошо ли это или плохо, я не знаю, время покажет. Эффективность важна, но защищенность важна тоже.
Реконструктор> Виндовс крашнуть может только драйвер. А потребителю пофиг как умрет программа - с GPF или с Runtime Error.

Да ну? Представляю, как обрадуется DataCenter у нас в Атланте, если какой-нибудь сервис умрет по GPF. Уж так обрадуется, так уж обрадуется... По цепочке дойдет радость до нашего менеджера. А уж он то как обрадуется...
   
RU Balancer #20.08.2008 20:04  @Татарин#20.08.2008 15:10
+
-
edit
 

Balancer

администратор
★★★★★
Татарин> Уфф... опять ты упираешься в скорость. :)
Татарин> А практика показывает, что скорость (особенно - выигрыш меньше чем в пару раз) сейчас далеко не самое важное.

Ты не понял :) Речь идёт о сравнении виртуальных машин. Для них я вижу следующие важные характеристики:

- Переносимость
- Производительность
- Удобство реализации тех или иных языков

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

Про второй я отметил, что JVM выглядит в случае Linux лучше. Но:

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

А тебе показалось, что я на один только второй пункт смотрю :D Как говорит один участник форума, «учитесь читать» :)

Татарин> Пока время реагирования проги укладывается в приемлимое пользователем, ему по-большому счёту плевать, сколько микро- или миллисекунд было потрачено на операцию и насколько был загружен процессор.

Угу. И тут у Java, кстати, как раз не всё шоколадно. Почему я и написал выше, что для написания под десктоп выбрал бы себе DotNet. Приложения, GUI которых написан на Java на массовых машинах имеют весьма ощутимую латентность. Для среднего человека GUI перестаёт тормозить, когда время реакции интерфейса меньше минимального времени реакции человека на событие, а это обычно <0,1сек. И если DotNet приложения в Mono под Linux выглядят в этом случае совершенно как нативные, т.е. имеют крайне малую латентность, то даже Экслипсовские библиотеки, являющиеся сегодня под Java эталоном скорости GUI, этим уже похвастаться не могут. Замедленная реакция вполне заметна. А если говорить о родных для Java SWT или, там паче, Swing - тут ситуация ещё хуже...

Татарин> Скажем, многие пользуют ОО, многие МСО, но лишь немногие заявляют что причина их сознательного выбора - скорость продукта (хотя для ОО серьёзное отличие есть, и оно иногда даже ощутимо для рядового пользователя).

OOo и MSO имеют различия много более существенные, чем скорость GUI :) Поэтому на скорость смотрят не в первую очередь. Это уже другая история.

Татарин> Ещё больше рулит удобство написания и разнообразие хорошо сочетаемых удобных инструментов.

В этом плане DotNet практически не уступает по средствам разработки (Eclipse vs MonoDevelop в случае свободных IDE) и превосходит по выбору языков: http://www.dotnetpowered.com/languages.aspx

Боюсь, выбор языков под JVM на порядок поменьше будет :)

Татарин> А у кого оно НЕ буксует? :D
Татарин> В смысле, покажи мне более успешную в этом плане контору, и тогда я с тобой соглашусь. :)

Хм. Я, вроде, вполне однозначно утверждаю, что MS сегодня начинает буксовать, а не то, что кто-то есть более успешный :) Одно никак не связано с другим...
   
RU Balancer #20.08.2008 20:11  @Татарин#20.08.2008 15:15
+
-
edit
 

Balancer

администратор
★★★★★
Татарин> Кстати, Роман, разве ты не член комиссии? Где твои выводы-то?

Пока нет времени серьёзно изучать результаты. Кроме того, я в коммисию официально не вызывался ;)

(А ещё думаю через недельку поэкспериментировать с D на эту тему, написав свой вариант, вне конкурса, чисто для себя, но пока не напишу, не хочу смотреть в чужие варианты решения, так что даже Сергеевы файлы присланные ещё не распаковывал)
   
RU Balancer #20.08.2008 20:16  @Сергей-4030#20.08.2008 17:53
+
-
edit
 

Balancer

администратор
★★★★★
Сергей-4030> Джаву сильно тормозит ее схема безопасности.

Возможно. Хотя, вроде, те, кто анализировал, говорят, что в dotnet система безопасности более гибкая, есть вещи по разделению ресурсов, которые JVM не умеет. Но тут я не копенгаген, испорченный телефон с чужих слов :)

Сергей-4030> Собственно, поэтому в байт-код Java сейчас транслируется, по большому счету, только сама Java.

Разве это имеет какое-то отношение к безопасности? Я, присматриваясь к путям развития JBForth, как раз изучал работу с байткодом. Препятствий в плане безопасности не встретил никаких. Проблемы только с раздельными стеками, отсутствием invoke dynamic вызовов и т.п. Первое лечится модификацияси Форт-синтаксиса, второе, увы, только статикой + рефлексией.

Правда, не в курсе, как дело обстоит с invoke dynamic в dotnet...
   
US Сергей-4030 #20.08.2008 20:45
+
-
edit
 

Сергей-4030

исключающий третье
★★
Блин, просто болезнь какая-то. :) Вместо обеда опять правил код. Вставил кой-какую оптимизацию минимальную. Теперь timetest.ct выполняется в средем за 1030 тиков. Последний Реконструкторов вариант на той же машине выполняется за 968 секунд. Однако, я даже не ожидал. ;)
   
US Сергей-4030 #20.08.2008 20:51  @Balancer#20.08.2008 20:04
+
-
edit
 

Сергей-4030

исключающий третье
★★
Balancer> И если DotNet приложения в Mono под Linux выглядят в этом случае совершенно как нативные, т.е. имеют крайне малую латентность, то даже Экслипсовские библиотеки, являющиеся сегодня под Java эталоном скорости GUI, этим уже похвастаться не могут. Замедленная реакция вполне заметна. А если говорить о родных для Java SWT или, там паче, Swing - тут ситуация ещё хуже...

Не замечаю. В том же Эклипсе контролы просто нативные, чем Эклипсяне и гордятся. Свинговские приложения использую - не замечаю задержек. Вернее, можно, конечно, написать с тормозами, но это где хошь можно.

ЗЫ SWT как раз родной для Эклипса.
   
RU Balancer #20.08.2008 20:59  @Сергей-4030#20.08.2008 20:45
+
-
edit
 

Balancer

администратор
★★★★★
Сергей-4030> Вместо обеда опять правил код.

Вот потому я и не сажусь пока :) Как засядешь - минимум день вон. А мне к 7 утра надо подготовить сайт один к показу :)
   
+
-
edit
 

Kernel3

аксакал

Гм. Да. Жесть. Ну так вот :)
Быстренько сваяв 6 тривиальных, но разнотипных тестов, обнаружил, что на варианте Реконструктора выполняются только 2. После этого взял готовые тесты Сергея, не содержащие избыточные по отношению к спецификации фичи (их нашёл 8: 1, 2, alg, indexed, simple, compare, nums, test1) и попробовал. Результат: аварийное завершение интерпретатора Реконструктора во всех случаях, кроме simple (который, однако всё равно не работает) ЖР Таким образом, по правилу "отсутствие функциональности = нулевому быстродействию" получаем 2/14, округляя до целых - 0. Ноооо! (вдыхает) Учитывая, что code_test Реконструктора после модификации для соответствия спеке (все "%" заменены на "^") выполняется на моей машине аж почти в полтора раза быстрее, чем на интерпретаторе Сергея (687 мсек против 1031), считаю возможным поставить Реконструктору за быстродействие 1 балл. 4, соответственно, идут Сергею.
Так же он получает 3 балла за скорость написания :)
По внутренней эстетике кода: после уже указанных весёлостей не считаю возможным поставить Реконструктору ни одного балла. У Сергея же особенно придраться не к чему. Ну, разве что к именам переменных большими буквами и с подчёркиванием в начале. Но это уже чистая вкусовщина :) В общем, ещё +2 балла Сергею.
Итого: 9:1 в пользу Сергея. Не flawless victory, но вполне себе fatality :):)

ЗЫ вообще, не подразумевалось, что сумма оценок обоих участников должна быть 10, просто мне так проще :):):)
   
RU Balancer #20.08.2008 21:02  @Сергей-4030#20.08.2008 20:51
+
-
edit
 

Balancer

администратор
★★★★★
Сергей-4030> Не замечаю. В том же Эклипсе контролы просто нативные, чем Эклипсяне и гордятся.

Под Windows - не знаю. Под Linux - нет :D Часть элементов вообще просто не имеет аналогов в GTK. Всякие, там, скошенные табы и т.п.
   
US Сергей-4030 #20.08.2008 21:11  @Balancer#20.08.2008 21:02
+
-
edit
 

Сергей-4030

исключающий третье
★★
Сергей-4030>> Не замечаю. В том же Эклипсе контролы просто нативные, чем Эклипсяне и гордятся.
Balancer> Под Windows - не знаю. Под Linux - нет :D Часть элементов вообще просто не имеет аналогов в GTK. Всякие, там, скошенные табы и т.п.

Тех, которых нет - те саморендеренные. Те, какие есть - нативные. Это ж и есть самая большая фишка SWT, они этим типа гордятся. У них библиотека Джавовских интерфейсов к нативным контролам.
   
EE Татарин #20.08.2008 21:12  @Balancer#20.08.2008 20:04
+
-
edit
 

Татарин

координатор
★★★★★
Татарин>> Уфф... опять ты упираешься в скорость. :)
Татарин>> А практика показывает, что скорость (особенно - выигрыш меньше чем в пару раз) сейчас далеко не самое важное.
Balancer> Ты не понял :) Речь идёт о сравнении виртуальных машин.
А, в этом смысле. Просто изначально мы сравнивали платформы.
Наличие для них хороших ВМ - очень важно, но всё-таки ещё далеко не всё.

Balancer> А тебе показалось, что я на один только второй пункт смотрю :D Как говорит один участник форума, «учитесь читать» :)
Ну, таков был контекст. :)

Balancer> Угу. И тут у Java, кстати, как раз не всё шоколадно.
Ну, могло быть лучше. Но и сейчас приемлимо. Не шоколадно, но приемлимо.

Balancer> OOo и MSO имеют различия много более существенные, чем скорость GUI :) Поэтому на скорость смотрят не в первую очередь. Это уже другая история.
Если бы мы имели продукты, которые сходились бы во всём на 100% и отличались бы только скоростью, тогда бы люди смотрели на скорость. :) ИМХО, это очевидно.
Но тут важны другие отличия.

Татарин>> Ещё больше рулит удобство написания и разнообразие хорошо сочетаемых удобных инструментов.
Balancer> В этом плане DotNet практически не уступает по средствам разработки (Eclipse vs MonoDevelop в случае свободных IDE) и превосходит по выбору языков: http://www.dotnetpowered.com/languages.aspx
Balancer> Боюсь, выбор языков под JVM на порядок поменьше будет :)
Не надо бояться. :)

Татарин>> А у кого оно НЕ буксует? :D
Татарин>> В смысле, покажи мне более успешную в этом плане контору, и тогда я с тобой соглашусь. :)
Balancer> Хм. Я, вроде, вполне однозначно утверждаю, что MS сегодня начинает буксовать, а не то, что кто-то есть более успешный :) Одно никак не связано с другим...
Если бы проталкивание просто бы ничего не давало - я б тебя понял. Но поскольку давление МС результаты таки даёт, и заметные, значит речь о теорможении сравнительном...
Вот я и спрашиваю, с чем сравниваем?
С тем же Микрософтом, но в прошлом? :)
   
US Сергей-4030 #20.08.2008 21:13  @Kernel3#20.08.2008 20:59
+
-
edit
 

Сергей-4030

исключающий третье
★★
Kernel3> Итого: 9:1 в пользу Сергея. Не flawless victory, но вполне себе fatality :):)

Служу Советскому Союзу! :)
   
RU Balancer #20.08.2008 21:16  @Сергей-4030#20.08.2008 21:11
+
-
edit
 

Balancer

администратор
★★★★★
Сергей-4030> Тех, которых нет - те саморендеренные. Те, какие есть - нативные.

Видимо, перед обработкой нативных виджетов, всё же, какая-то прослойка стоит. Ибо более тормозная работа интерфейса видна невооружённым глазом :) В противоположность этому DotNet приложения под Mono внешне и по скорости от нативных неотличимы.
   
RU Balancer #20.08.2008 21:21  @Татарин#20.08.2008 21:12
+
-
edit
 

Balancer

администратор
★★★★★
Татарин> Если бы проталкивание просто бы ничего не давало - я б тебя понял. Но поскольку давление МС результаты таки даёт, и заметные, значит речь о теорможении сравнительном...

Фиг его знает. Я сижу в другом курятнике, и тут давление MS напрямую незаметно. Но DotNet у нас есть. Так, вот, прикол в том, что он с Windows никак не соотносится. Т.е. Windows-приложения .NET под Linux не идут из-за неаккуратность программистов (используют массу вызовов, характерных только для Windows, кстати, у Java тут получше отчасти будет ситуация), Linux-приложения под .NET под Windows неакутальны, т.к. есть выбор более аутентичных нативных... Так что, как бы, и непонятно, зачем .NET под Linux :) Однако он набирает популярность. И конкретные реализации достаточно удобны. По крайней мере с .NET-приложениями под Linux работаешь также, как с нативными, в противоположность Java.
   
+
-
edit
 

tarasv

аксакал

Balancer>Так что, как бы, и непонятно, зачем .NET под Linux :) Однако он набирает популярность. И конкретные реализации достаточно удобны. По крайней мере с .NET-приложениями под Linux работаешь также, как с нативными, в противоположность Java.

А кстати как поживает под Linux IDEA? Под виндой она смотрится очень даже ничего, почти не хуже найтивных по скорости, но далеко впереди по удобству и как по мне она поудобней Eclipse.
   
1 7 8 9 10 11 12 13

в начало страницы | новое
 
Поиск
Поддержка
Поддержи форум!
ЯндексЯндекс. ДеньгиХочу такую же кнопку
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru