Здравствуйте, silverwolf, Вы писали:
H>>Я правильно понял что это именно лямбды с замыканиями замедляют компиялицю в Scala и именно лямбды с замыканиями так сильно сказываются на производительности? S>Нет, это всего лишь один из факторов.
Это совсем не тот фактор который сказывается на скорости компиляции. Тот же csc.exe молниеносно компилирует код изобилующий лямбдами. Производительность при частом использовании лямбд конечно проседает, но там где она важна их просто не используют.
S>Вы про замыкания и лямбды? Если да, то да
Тогда выглядит очень забавным (если не смешным) как вы защищаете javac от появления в нем лямбд.
Здравствуйте, hardcase, Вы писали:
H>Это совсем не тот фактор который сказывается на скорости компиляции.
Один из! Далеко не главный, но "копієчка до копієчки" (c)
H>Тогда выглядит очень забавным (если не смешным) как вы защищаете javac от появления в нем лямбд.
Если честно, я не вижу очень большой необходимости в том чтобы расширять то что уже есть (хотя местами это было бы удобно, но при этом не необходимо), те кому это надо было уже научились пользоваться той реализацией что есть (лично меня не очень напрягают +2 строки).
Второй момент. Я не защищаю "javac от появления в нем лямбд", я лишь назвал возможные сложности при использовании такого же подхода для реализации ФП-фишечек как в scala (собственно риск получить скалу ). Возвращаясь к теме ВМов, было бы куда интереснее если бы поддержка ФП была на уровне ВМа, но это куда более сложный путь.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, hardcase, Вы писали:
H>>Незачем сюда VM приплетать. Речь идет о фичах языка. LINQ появился в C#3 и никак не повлиял на бинарную совместимость кода — .NET 3.5 оставался надстройкой над .NET 2.0. Все необходимое язык Java имеет уже сейчас — от анонимных классов до замыканий ровно один шаг, и поддержка рантайма тут не нужна, реализация генераторов (yield-ов) также не составляет труда и опять же не требует поддержки рантайма.
K>Да сколько можно повторять! Замыкания в Java есть! Чего в Java нет, так это лямбд. Кстати, обещают в Java 8
Здравствуйте, Jack128, Вы писали:
J>В C# из ФП только замыкания.
Замыкания как раз таки вовсе не ФП, хотя в основном в ФП языках присутствуют. Причем в Джаве некая вариация на тему замыканий в виде inner классов была изначально.
ФП это функциональный тип (ака делегат), лямбды.
J>Ну и LINQ aka сахар для монад, которыми(монадами) мало кто пользуется.
Смешно.
... << RSDN@Home 1.2.0 alpha 5 rev. 16 on Windows 7 6.1.7601.65536>>
Здравствуйте, alexeiz, Вы писали:
>> Пример Python и Perl как бы говорит нам, что "сколько бы ни было >> написано, а совместимость ломать можно и нужно". A>Пример Python и Perl как бы говорит нам совсем обратное. A>С перлом таже история. Perl 6 — сломали совместимость (вообще, A>положили на совместимость с прибором).
Perl 5 и Perl 6 — вообще разные языки, а не разные версии одного языка, хоть изначально и задумывалось иначе. Ни о какой поломке совместимости в этом случае речи не идёт. Ну и кроме того в Perl 6 можно выполнять код Perl 5.
Здравствуйте, Nuzhny, Вы писали:
N>>>На Яве написано больше, так просто совместимость не сломать. W>>Пример Python и Perl как бы говорит нам, что "сколько бы ни было написано, а совместимость ломать можно и нужно". N>"Пример Python и Perl как бы говорит нам", что на них написано кода гораздо меньше.
И сколько же кода написано на Java? В строчках кода, к примеру.
Тот же csc.exe молниеносно компилирует код изобилующий лямбдами. Производительность при частом использовании лямбд конечно проседает, но там где она важна их просто не используют.
