Здравствуйте, Pavel Dvorkin, Вы писали:
PD>То, что C# вышел из Java — несомненно. PD>То, что дальше они развивались в одном и том же направлении до поры до времени — тоже. И дженерики, и аннотации (атрибуты) появились и там и здесь (пусть и есть отличия в деталях). Кто ввел раньше, кто позже — не в этом суть.
PD>А вот дальше — стоп. C# полез в ФП, а Java — нет.
PD>Почему ?
Здравствуйте, silverwolf, Вы писали:
S>И тут важна поддержка разных ВМов: нельзя просто добавить фичу и сказать что те кто пользуются ИБМовской джавой идут лесом.
Незачем сюда VM приплетать. Речь идет о фичах языка. LINQ появился в C#3 и никак не повлиял на бинарную совместимость кода — .NET 3.5 оставался надстройкой над .NET 2.0. Все необходимое язык Java имеет уже сейчас — от анонимных классов до замыканий ровно один шаг, и поддержка рантайма тут не нужна, реализация генераторов (yield-ов) также не составляет труда и опять же не требует поддержки рантайма.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот дальше — стоп. C# полез в ФП, а Java — нет.
Тут скорее не "полез в ФП", а "добавили модных фишечек" (типа маркетинг). PD>Почему ? PD>Основная ниша-то у них общая есть — серверное программирование. Пусть есть и другие ниши, но их роль все равно меньше.
ИМХО, тут играет роль ни столько ниша как серверное/клиентское ПО, сколько степень "энтерпрайзности". Java -- это во многом большие энтерпрайзы (как правило очень консервативные, есть проекты еще на 1.4 ), при том они не всегда используют Сановскую (Оракловую) джаву, часто это Websphere с ИБМовской джавой. И тут важна поддержка разных ВМов: нельзя просто добавить фичу и сказать что те кто пользуются ИБМовской джавой идут лесом. У C# такой проблемы нет, он по факту разрабатывается одной конторой и МСу нет необходимости согласовывать реализации с другими вендорами.
Плавно переходим к следующему пункту. Спецификации Java разрабатывает так же сообщество, а C# -- та же одна компания что и делает реализацию. Такой расклад существенно тормозит скорость развития (Когда начали в джаве говорить про "лямбды"?).
PD>>Почему ? N>На Яве написано больше, так просто совместимость не сломать.
Пример Python и Perl как бы говорит нам, что "сколько бы ни было написано, а совместимость ломать можно и нужно".
[off] N>А вот свежий пример переписывания с C# на Java.
О, благородный дон пытается толсто троллить Любой имеющий мозг да прочтет, что причина переписывания продукта — покупка разработчика, а не что-либо иное
[/off]
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, silverwolf, Вы писали:
S>>Не совсем. Существуют способы реализовать эти фичи без переделки генерируемого кода и ВМа. Но не факт что эти способы наиболее подходящие.
K>И какие же способы существуют с переделкой VM'а?
Вроде, предлагали переделать поддержу методов как объектов на уровне ВМа. K>И почему все эти фичи прекрасно реализованы в Scala, которая работает на той же VM?
Прекрасный пример. А теперь вспомните про скорость компиляции Scala. И про скорость генерируемого кода, многие сталкиваются с проблемой: если активно использовать фичи скалы все тормозит, но если писать на "джава с синтаксисом скалы" то все ок.
Вопрос: Кому такое счастье надо?
То, что C# вышел из Java — несомненно.
То, что дальше они развивались в одном и том же направлении до поры до времени — тоже. И дженерики, и аннотации (атрибуты) появились и там и здесь (пусть и есть отличия в деталях). Кто ввел раньше, кто позже — не в этом суть.
А вот дальше — стоп. C# полез в ФП, а Java — нет.
Почему ?
Основная ниша-то у них общая есть — серверное программирование. Пусть есть и другие ниши, но их роль все равно меньше.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>То, что C# вышел из Java — несомненно. PD>То, что дальше они развивались в одном и том же направлении до поры до времени — тоже. И дженерики, и аннотации (атрибуты) появились и там и здесь (пусть и есть отличия в деталях). Кто ввел раньше, кто позже — не в этом суть.
PD>А вот дальше — стоп. C# полез в ФП, а Java — нет.
PD>Почему ?
В C# из ФП только замыкания.
Ну и LINQ aka сахар для монад, которыми(монадами) мало кто пользуется.
Ну на счет линка глухо, но замыкания в Java вроде собираются вводить. Так что отличие только в том, что шарп быстрее развивается, а Sun/Oracle тормозит.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Основная ниша-то у них общая есть — серверное программирование.
Вообще-то оно на Java и .NET весьма по разное в подходах.
На Java и сами сервера приложений и пр написаны, а вот на C# дописывается нечто к функциональности нативных серверов.
PD> C# полез в ФП, а Java — нет. Почему ?
Потому что Java достигла успеха без ФП. И за счет — простоты (до убогости), и жесточайшим самоограничениям ради совместимости бинарного кода.
Не нужно короче ФП в Jave, вот его и нет там. Кому нужно — пользуют Scala, или Clojure какой.
ФП конечно модная тема для обсуждения на форумах. В самом деле, сколько можно работу то обсуждать, давайте ж наконец "о женщинах"
Здравствуйте, Nuzhny, Вы писали:
PD>>Почему ? N>На Яве написано больше, так просто совместимость не сломать.
Пример Python и Perl как бы говорит нам, что "сколько бы ни было написано, а совместимость ломать можно и нужно".
[off] N>А вот свежий пример переписывания с C# на Java.
О, благородный дон пытается толсто троллить Любой имеющий мозг да прочтет, что приина переписывания продукта — покупка конмании, а не что-либо иное
[/off]
Здравствуйте, Wolverrum, Вы писали:
N>>На Яве написано больше, так просто совместимость не сломать. W>Пример Python и Perl как бы говорит нам, что "сколько бы ни было написано, а совместимость ломать можно и нужно".
"Пример Python и Perl как бы говорит нам", что на них написано кода гораздо меньше.
N>>А вот свежий пример переписывания с C# на Java. W>О, благородный дон пытается толсто троллить Любой имеющий мозг да прочтет, что приина переписывания продукта — покупка конмании, а не что-либо иное
Я не пытаюсь, а привёл только голый факт без высказывания своего мнения о нём. Факты не могут троллить, они просто существуют. И, кстати, ничего не говорил о причине переписывания. Любой имеющий мозг это бы уловил.
Здравствуйте, Wolverrum, Вы писали:
N>>На Яве написано больше, так просто совместимость не сломать. W>Пример Python и Perl как бы говорит нам, что "сколько бы ни было написано, а совместимость ломать можно и нужно".
Кстати! Пример Python ещё показывает, что многим не понравилась ломка совместимости при переходе на третью версию.
А пример С++ показывает, что совместимость с С была важным фактором в широком распространении языка.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, silverwolf, Вы писали:
S>>И тут важна поддержка разных ВМов: нельзя просто добавить фичу и сказать что те кто пользуются ИБМовской джавой идут лесом.
H>Незачем сюда VM приплетать. Речь идет о фичах языка. LINQ появился в C#3 и никак не повлиял на бинарную совместимость кода — .NET 3.5 оставался надстройкой над .NET 2.0. Все необходимое язык Java имеет уже сейчас — от анонимных классов до замыканий ровно один шаг, и поддержка рантайма тут не нужна, реализация генераторов (yield-ов) также не составляет труда и опять же не требует поддержки рантайма.
Не совсем. Существуют способы реализовать эти фичи без переделки генерируемого кода и ВМа. Но не факт что эти способы наиболее подходящие.
Второй момент: S>>Спецификации Java разрабатывает так же сообщество, а C# -- та же одна компания что и делает реализацию.
Тех же замыканий было несколько вариантов синтаксиса.
PD>А вот дальше — стоп. C# полез в ФП, а Java — нет.
PD>Почему ?
Для ФП есть соответственно Scala и F#. А то что говорите вы — это скорее мелкие добавки синтаксического сахара в языки. Происходит это везде, даже в таких фундаментальных языках как C++, но везде с разной скоростью. В C# обновления идут пожалуй быстрее всех, вполне понятно почему.
PD>Основная ниша-то у них общая есть — серверное программирование. Пусть есть и другие ниши, но их роль все равно меньше.
Смотря что вы имеете в виду под серверным программированием. Если включаете сюда миллионы тупых формочек клиентского софта из клиент-серверных корпоративных приложений, то тогда это высказывание ещё может быть похожим на правду.
Здравствуйте, hardcase, Вы писали:
H>Незачем сюда VM приплетать. Речь идет о фичах языка. LINQ появился в C#3 и никак не повлиял на бинарную совместимость кода — .NET 3.5 оставался надстройкой над .NET 2.0. Все необходимое язык Java имеет уже сейчас — от анонимных классов до замыканий ровно один шаг, и поддержка рантайма тут не нужна, реализация генераторов (yield-ов) также не составляет труда и опять же не требует поддержки рантайма.
Да сколько можно повторять! Замыкания в Java есть! Чего в Java нет, так это лямбд. Кстати, обещают в Java 8
Здравствуйте, silverwolf, Вы писали:
S>Не совсем. Существуют способы реализовать эти фичи без переделки генерируемого кода и ВМа. Но не факт что эти способы наиболее подходящие.
И какие же способы существуют с переделкой VM'а? Вот почему инженеры MS выбрали способы без переделки? И почему все эти фичи прекрасно реализованы в Scala, которая работает на той же VM?
Wolverrum said:
> Пример Python и Perl как бы говорит нам, что "сколько бы ни было > написано, а совместимость ломать можно и нужно".
Пример Python и Perl как бы говорит нам совсем обратное.
Python 3.0, который по большому счету немного несовместим с 2.6, вышел
в 2008 году. 4 года спустя многие библиотеки еще не портировали на
Python 3. Поэтому продолжает развиваться ветка Python 2.
С перлом таже история. Perl 6 — сломали совместимость (вообще,
положили на совместимость с прибором). Можно смело сказать, что
огромное количество кода библиотек Perl 5 никто никогда не будет
переписывать на Perl 6. Следовательно, продолжают пилить (и очень
активно) Perl 5.
Здравствуйте, silverwolf, Вы писали:
K>>И почему все эти фичи прекрасно реализованы в Scala, которая работает на той же VM? S>Прекрасный пример. А теперь вспомните про скорость компиляции Scala. И про скорость генерируемого кода, многие сталкиваются с проблемой: если активно использовать фичи скалы все тормозит, но если писать на "джава с синтаксисом скалы" то все ок. S>Вопрос: Кому такое счастье надо?
Я правильно понял что это именно лямбды с замыканиями замедляют компиялицю в Scala и именно лямбды с замыканиями так сильно сказываются на производительности?
Можно личный вопрос — вы хоть раз пользовались этими фичами на практике в любом другом языке?
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, silverwolf, Вы писали:
K>>>И почему все эти фичи прекрасно реализованы в Scala, которая работает на той же VM? S>>Прекрасный пример. А теперь вспомните про скорость компиляции Scala. И про скорость генерируемого кода, многие сталкиваются с проблемой: если активно использовать фичи скалы все тормозит, но если писать на "джава с синтаксисом скалы" то все ок. S>>Вопрос: Кому такое счастье надо?
H>Я правильно понял что это именно лямбды с замыканиями замедляют компиялицю в Scala и именно лямбды с замыканиями так сильно сказываются на производительности?
Нет, это всего лишь один из факторов. Кроме того Scala, как раз, хорошо демонстрирует тот подход о котором говорил konsoletyper, то есть преобразование "синтаксического сахара" в уже существующие конструкции, например SMI.
Само по себе такое преобразование занимает время и в некоторых случаях может занимать много времени, а одно из преимуществ javac — это его скорость и то что он не занимается оптимизациями.
На скорость выполняемого кода скорее влияет не сам факт генерации доп кода, а то что довольно сложные структуры (создание промежуточных классов, например) скрыты от программиста. Таким образом увеличивается вероятность ошибки в плане производительность, типа: "я ж ничего такого не написал, откуда тут 100500 вложенных вызовов". H>Можно личный вопрос — вы хоть раз пользовались этими фичами на практике в любом другом языке?
Вы про замыкания и лямбды? Если да, то да Java (насколько это возможно), javascript (без этого там сложно), по мелочи (у меня нет большого опыта в последующих языках) в ruby, groovy, scala.
Здравствуйте, hardcase, Вы писали:
H>Я правильно понял что это именно лямбды с замыканиями замедляют компиялицю в Scala и именно лямбды с замыканиями так сильно сказываются на производительности?
Нет, неправильно. В скале куча разных фич, которые могут сказаться на производительности. И лямбда — это совсем-совсем простой случай. Там, например, очень много фич в системе типов, которые явно выливаются в чёрти какое нагромождение классов.
H>Можно личный вопрос — вы хоть раз пользовались этими фичами на практике в любом другом языке?
Да постоянно. В Java. Только в случае Java — не анонимными функциями с замыканиями, а анонимными классами с замыканиями. Ну а по-другому — это явно написать именованный класс и передать ему в конструкторе параметры. Ну да, создание объекта и инициализация его полей — это накладные расходы. А по-другому — никак.
Здравствуйте, 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? В строчках кода, к примеру.
), при том они не всегда используют Сановскую (Оракловую) джаву, часто это Websphere с ИБМовской джавой. И тут важна поддержка разных ВМов: нельзя просто добавить фичу и сказать что те кто пользуются ИБМовской джавой идут лесом. У C# такой проблемы нет, он по факту разрабатывается одной конторой и МСу нет необходимости согласовывать реализации с другими вендорами.
