То, что 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 какой.
ФП конечно модная тема для обсуждения на форумах. В самом деле, сколько можно работу то обсуждать, давайте ж наконец "о женщинах"
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот дальше — стоп. C# полез в ФП, а Java — нет.
Тут скорее не "полез в ФП", а "добавили модных фишечек" (типа маркетинг). PD>Почему ? PD>Основная ниша-то у них общая есть — серверное программирование. Пусть есть и другие ниши, но их роль все равно меньше.
ИМХО, тут играет роль ни столько ниша как серверное/клиентское ПО, сколько степень "энтерпрайзности". Java -- это во многом большие энтерпрайзы (как правило очень консервативные, есть проекты еще на 1.4 ), при том они не всегда используют Сановскую (Оракловую) джаву, часто это Websphere с ИБМовской джавой. И тут важна поддержка разных ВМов: нельзя просто добавить фичу и сказать что те кто пользуются ИБМовской джавой идут лесом. У C# такой проблемы нет, он по факту разрабатывается одной конторой и МСу нет необходимости согласовывать реализации с другими вендорами.
Плавно переходим к следующему пункту. Спецификации Java разрабатывает так же сообщество, а C# -- та же одна компания что и делает реализацию. Такой расклад существенно тормозит скорость развития (Когда начали в джаве говорить про "лямбды"?).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>То, что C# вышел из Java — несомненно. PD>То, что дальше они развивались в одном и том же направлении до поры до времени — тоже. И дженерики, и аннотации (атрибуты) появились и там и здесь (пусть и есть отличия в деталях). Кто ввел раньше, кто позже — не в этом суть.
PD>А вот дальше — стоп. C# полез в ФП, а Java — нет.
PD>Почему ?
Здравствуйте, Nuzhny, Вы писали:
PD>>Почему ? N>На Яве написано больше, так просто совместимость не сломать.
Пример Python и Perl как бы говорит нам, что "сколько бы ни было написано, а совместимость ломать можно и нужно".
[off] N>А вот свежий пример переписывания с C# на Java.
О, благородный дон пытается толсто троллить Любой имеющий мозг да прочтет, что приина переписывания продукта — покупка конмании, а не что-либо иное
[/off]
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 ещё показывает, что многим не понравилась ломка совместимости при переходе на третью версию.
А пример С++ показывает, что совместимость с С была важным фактором в широком распространении языка.
Здравствуйте, silverwolf, Вы писали:
S>И тут важна поддержка разных ВМов: нельзя просто добавить фичу и сказать что те кто пользуются ИБМовской джавой идут лесом.
Незачем сюда VM приплетать. Речь идет о фичах языка. LINQ появился в C#3 и никак не повлиял на бинарную совместимость кода — .NET 3.5 оставался надстройкой над .NET 2.0. Все необходимое язык Java имеет уже сейчас — от анонимных классов до замыканий ровно один шаг, и поддержка рантайма тут не нужна, реализация генераторов (yield-ов) также не составляет труда и опять же не требует поддержки рантайма.
Здравствуйте, 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?
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, silverwolf, Вы писали:
S>>Не совсем. Существуют способы реализовать эти фичи без переделки генерируемого кода и ВМа. Но не факт что эти способы наиболее подходящие.
K>И какие же способы существуют с переделкой VM'а?
Вроде, предлагали переделать поддержу методов как объектов на уровне ВМа. K>И почему все эти фичи прекрасно реализованы в Scala, которая работает на той же VM?
Прекрасный пример. А теперь вспомните про скорость компиляции Scala. И про скорость генерируемого кода, многие сталкиваются с проблемой: если активно использовать фичи скалы все тормозит, но если писать на "джава с синтаксисом скалы" то все ок.
Вопрос: Кому такое счастье надо?
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 — не анонимными функциями с замыканиями, а анонимными классами с замыканиями. Ну а по-другому — это явно написать именованный класс и передать ему в конструкторе параметры. Ну да, создание объекта и инициализация его полей — это накладные расходы. А по-другому — никак.
