Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 123
Java никуда не денется еще очень долго. Слишком много на ней написано.
Но, как мне кажется, будущее за функциональными языками.
Но, как мне кажется, будущее за функциональными языками.
Продолжите мысль? Запускать функциональные языки каким-то образом на JVM?
будущее за гибридными языками
> будущее за функциональными языками.
Почему?
Почему функциональное программирование вдруг лучше чем императивное и/или объектно ориентированное? (Почему LISP еще не захватил мир?)
Почему?
Почему функциональное программирование вдруг лучше чем императивное и/или объектно ориентированное? (Почему LISP еще не захватил мир?)
Да понятно почему. Я не уверен конечно что будущее за ФЯ, но почему к ним вернулся интерес совершенно понятно. Главный тренд сейчас в том, что мы уперлись в вертикальное масштабирование и активно начали развивать горизонтальное. Завтра вам придется запускать приложение так, чтобы оно легко масштабировалось на сотни ядер. Готового и простого решения как это делать у мейнстримных императивных и ООП языков нет. У функциональных с этим проще.
Кто придумает в этом направлении конфетку и протолкнет ее, тот и получит рынок.
Кто придумает в этом направлении конфетку и протолкнет ее, тот и получит рынок.
Серверное многопоточное ПО и так масштабируется на сотни ядер, тут ничего придумывать не надо. Десктопное ПО, как правило, масштабировать нет нужды, либо хватает тех же потоков. А для вычислительных задач наверное нужны функциональные или какие другие языки, но явно не ява. Но это довольно узкая ниша и рынок на нём не получишь.
У каждого подхода есть свои плюсы и минусы, и вы это должны знать. И я ни в коем случае не говорю, что функциональный подход в итоге самый лучший или он всех победит.
Я говорю лишь, что скорее всего нас ждет перерождение или новая жизнь функциональных языков. Собственно, вы это разве сейчас не наблюдаете — F#, Linq(отчасти) в .net, python.
Я на практике наблюдаю как достаточно много математических расчетов проходят в Haskell и затем результаты переводят в ООП-язык. Читать и поддерживать такой код одно удовольствие.
Я говорю лишь, что скорее всего нас ждет перерождение или новая жизнь функциональных языков. Собственно, вы это разве сейчас не наблюдаете — F#, Linq(отчасти) в .net, python.
Я на практике наблюдаю как достаточно много математических расчетов проходят в Haskell и затем результаты переводят в ООП-язык. Читать и поддерживать такой код одно удовольствие.
«Мы ориентировались не на Lisp-программистов, нет; нашей целью были С++-программисты. Нам удалось протащить их на полпути ближе к Лиспу». (Guy Steele о разработке языка Java)
Посмотрите на последние тенденции в разработке новых языков. Посмотрите на Python, Ruby, новые версии C#, посмотрите на концепции вроде сборки мусора, замыканий, разработку eDSL-ей. Однажды вы проснетесь утром и поймете, что язык, на котором вы пишете — это Common Lisp с немного измененным синтаксисом.
Посмотрите на последние тенденции в разработке новых языков. Посмотрите на Python, Ruby, новые версии C#, посмотрите на концепции вроде сборки мусора, замыканий, разработку eDSL-ей. Однажды вы проснетесь утром и поймете, что язык, на котором вы пишете — это Common Lisp с немного измененным синтаксисом.
Возможно. Но пока ничего особо привлекательного в Питоне и Руби не вижу.
Но вы работаете с Java, а следовательно используете garbage collection, который тоже 30 лет назад считался в широких кругах «бесполезной и глупой затеей».
Garbage collection делает программирование проще и сильно уменьшает вероятность багов, в т.ч. весьма трудообнаруживаемых (как и многие другие вещи в Java кстати).
Функциональное же программирование не упростит жизнь программистам, а иногда возможно и наоборот — весьма усложнит.
В LISP был гарбадж коллекшн и что? И ничего.
Функциональное же программирование не упростит жизнь программистам, а иногда возможно и наоборот — весьма усложнит.
В LISP был гарбадж коллекшн и что? И ничего.
>> Функциональное же программирование не упростит жизнь программистам, а иногда возможно и наоборот — весьма усложнит.
Это вы на основе каких-то исследований утверждаете? Может ссылки приведете?
>> В LISP был гарбадж коллекшн и что? И ничего.
И не поспоришь.
Это вы на основе каких-то исследований утверждаете? Может ссылки приведете?
>> В LISP был гарбадж коллекшн и что? И ничего.
И не поспоришь.
> Это вы на основе каких-то исследований утверждаете? Может ссылки приведете?
А нужны целые исследования чтобы понять что императивное программирование для человеков интуитивнее чем функциональное? Тоесть это моё IMO конечно, но, скажем так, IMNSHO.
Да и процессоры пока что выполняют последовательности команд, потому императивное программирование ближе к железеной «реальности». От последовательного выполнения никуда не денешься, при том же дебаге например, не так ли? Значит так или иначе приходится представлять себе что и в какой последовательности программа будет делать, и с императивными языками это попроще будет чем с функциональными.
Кстати русская википедия еще такое заявляет «Для преодоления недостатков функциональных программ уже первые языки функционального программирования включали не только чисто функциональные средства, но и механизмы императивного программирования (присваивание, цикл, «неявный PROGN» были уже в LISPе)», вроде как близко к нашей теме.
А нужны целые исследования чтобы понять что императивное программирование для человеков интуитивнее чем функциональное? Тоесть это моё IMO конечно, но, скажем так, IMNSHO.
Да и процессоры пока что выполняют последовательности команд, потому императивное программирование ближе к железеной «реальности». От последовательного выполнения никуда не денешься, при том же дебаге например, не так ли? Значит так или иначе приходится представлять себе что и в какой последовательности программа будет делать, и с императивными языками это попроще будет чем с функциональными.
Кстати русская википедия еще такое заявляет «Для преодоления недостатков функциональных программ уже первые языки функционального программирования включали не только чисто функциональные средства, но и механизмы императивного программирования (присваивание, цикл, «неявный PROGN» были уже в LISPе)», вроде как близко к нашей теме.
>> А нужны целые исследования чтобы понять что императивное программирование для человеков интуитивнее чем функциональное?
А нужны целые исследования чтобы понять что функциональное программирование для человеков интуитивнее чем императивное? Чем ваше заявление аргументированее моего? Я бы сказал наоборот. Я использую оба подхода, вы — только один.
>> Да и процессоры… императивное программирование ближе…
При чем тут это? Мы говорили об удобстве для человека, а не для процессора.
>> при том же дебаге
При отладке функционального кода не нужен дебагер.
>> русская википедия… заявляет…
Простите, но это столь же далеко от нашей темы, сколь ваша обознаность в ней. Дружески предлагаю (вы конечно сейчас можете сказать, чтобы я не указывал вам что делать, ваше право) освоить для общего развития один язык, поддерживающий функциональную парадигму (ту же Скалу, например — минимальные отличия от Java), и после этого продолжить нашу дискуссию, когда вы станете более подкованы во всех этих вопросах.
А нужны целые исследования чтобы понять что функциональное программирование для человеков интуитивнее чем императивное? Чем ваше заявление аргументированее моего? Я бы сказал наоборот. Я использую оба подхода, вы — только один.
>> Да и процессоры… императивное программирование ближе…
При чем тут это? Мы говорили об удобстве для человека, а не для процессора.
>> при том же дебаге
При отладке функционального кода не нужен дебагер.
>> русская википедия… заявляет…
Простите, но это столь же далеко от нашей темы, сколь ваша обознаность в ней. Дружески предлагаю (вы конечно сейчас можете сказать, чтобы я не указывал вам что делать, ваше право) освоить для общего развития один язык, поддерживающий функциональную парадигму (ту же Скалу, например — минимальные отличия от Java), и после этого продолжить нашу дискуссию, когда вы станете более подкованы во всех этих вопросах.
> Я использую оба подхода, вы — только один.
Вот он — аргумент всех ФПшников, какбы доказывающий их какбы превосходство — радуясь своей малочисленности они всех остальных полагают некомпетентными в вопросе выбора концепций программирования.
Однако не всем обязательно ломать ногу чтобы знать что такое перелом ноги.
> При чем тут это? Мы говорили об удобстве для человека, а не для процессора.
Именно о нём — т.к. программа всё равно будет исполнена последовательно человеку, чтоб понять что будет происходить, прийдётся представить себе последовательность. И ему это удобнее делать на основе императивного «кода». Про «удобство» для процессора речь не шла разумеется.
> При отладке функционального кода не нужен дебагер.
Почему? А что нужно чтоб понять как произойдёт выполнение программы в том или ином use case?
Вот он — аргумент всех ФПшников, какбы доказывающий их какбы превосходство — радуясь своей малочисленности они всех остальных полагают некомпетентными в вопросе выбора концепций программирования.
Однако не всем обязательно ломать ногу чтобы знать что такое перелом ноги.
> При чем тут это? Мы говорили об удобстве для человека, а не для процессора.
Именно о нём — т.к. программа всё равно будет исполнена последовательно человеку, чтоб понять что будет происходить, прийдётся представить себе последовательность. И ему это удобнее делать на основе императивного «кода». Про «удобство» для процессора речь не шла разумеется.
> При отладке функционального кода не нужен дебагер.
Почему? А что нужно чтоб понять как произойдёт выполнение программы в том или ином use case?
>> Однако не всем обязательно ломать ногу чтобы знать что такое перелом ноги.
Вот он — аргумент всех недалеких личностей, гордящихся своей неосведомленностью и делающих на ее основе те или иные выводы.
По вашей аналогии, вы не просто не ломали ногу, вы никогда не открывали ни одной книжки по анатомии.
Я поражаюсь не вашим уровнем некомпетентности, нет — в конце концов, никто не знает всего. Меня поражает уверенность, с который вы говорите о вещах, о которых не имеете ни малейшего представления.
Вот он — аргумент всех недалеких личностей, гордящихся своей неосведомленностью и делающих на ее основе те или иные выводы.
По вашей аналогии, вы не просто не ломали ногу, вы никогда не открывали ни одной книжки по анатомии.
Я поражаюсь не вашим уровнем некомпетентности, нет — в конце концов, никто не знает всего. Меня поражает уверенность, с который вы говорите о вещах, о которых не имеете ни малейшего представления.
Java никуда не денется еще очень долго. Слишком много на ней написано.В принципе, так же как и COBOL — на нем ведь тоже очень многое написано. Тем не менее, сейчас не особо много желающих найдется писать новый софт на Коболе :)
Думаю, та же участь ждет и Java.
Исправьте название языка, он называется Clojure, а не Closure.
[sarcasm] Будущее за Vala! [/sarcasm]
>_<
>_<
Отвязали бы его от GTK — цены бы не было.
Vala никогда не была привязана к Gtk. Вот к GLib — да.
Я не особо хорошо разбираюсь в хитросплетениях всего этого, просто помню, что GLib в рамках гнома пилится.
Тогда уж к GObject.
Но сам GObject уж очень тормозной. В рассылке совсем недавно обсуждалось то что создание GObject объектов требует много раз больше CPU чем создание C++ объектов. Тоже самое с сигналами и другими фишками GLib.
Именно поэтому Йорг (один из core developers) работает над dova — замена GObject которую можете использовать если вам не нужна привязка к GLib.
Но сам GObject уж очень тормозной. В рассылке совсем недавно обсуждалось то что создание GObject объектов требует много раз больше CPU чем создание C++ объектов. Тоже самое с сигналами и другими фишками GLib.
Именно поэтому Йорг (один из core developers) работает над dova — замена GObject которую можете использовать если вам не нужна привязка к GLib.
Зря все Java хоронят. Я как C# программист уверен, что Java еще лет так 20 не куда не денется. Не потому, что я ее люблю, а просто это очень распространенный язык и на ней написано столько, что всему .net сообществу еще портировать лет 5-6. В общем скорее авторы статей про смерть java сгинут, чем java.
Я извините, отнюдь не предсказываю смерть java, и уж тем более не хочу ее. Я сам, как написал, на ней пишу, люблю ее, и еще больше люблю деньги, которые на ней зарабатываю. А пост — это мои размышления о том, почему Sun/ Oracle придерживаются именно текущей стратегии.
тут еще один не маловажный факт, что портировать незачем потому что и так работает и часто работает на каком нибудь мамонте с AIX, вместо которого Windows серверов сильно много ставить прийдется. Про mono тут рассказывать не надо под него никто в здравой памяти продакшен приложение такого уровня разворачивать не будет.
В первую очередь хочу поблагодарить за заметку — это очень похоже и на мои мысли. Мне также кажется, что Java — это очень стабильная платформа и говорить о ее закате по меньшей мере глупо. Я тоже считаю, что она чрезвычайно консервативна и разработку альтернативных языков также считаю единственным выходом из создавшейся ситуации.
Наиболее серьезной угрозой для Java платформы как основной платформы для энтерпрайза, я считаю запрет ораклом разработки альтернативных Java-машин (поправьте, если я ошибаюсь — я из .NET стека).
Наиболее серьезной угрозой для Java платформы как основной платформы для энтерпрайза, я считаю запрет ораклом разработки альтернативных Java-машин (поправьте, если я ошибаюсь — я из .NET стека).
Наиболее серьезной угрозой для Java платформы как основной платформы для энтерпрайза, я считаю запрет ораклом разработки альтернативных Java-машин (поправьте, если я ошибаюсь — я из .NET стека).Эм...? Как вообще могут запретить? Чуть ли не поощряют, Там и спецификации открыты и альтернативных машин просто целая куча.
blogs.apache.org/foundation/entry/the_asf_resigns_from_the а что относительно этого? я что-то неверно понял?
Внесу свои пять копеек.
Почему так тормозится развитие Джавы и так летит вперёд.НЕТ? Одна из важнейших причин — обратная совместимость. Код, скомпилированный в Джаве 1.6 скорее всего беспричинно запустится в рантайме 1.5. Поэтому дженерики в.НЕТ — рантайм, а в Джаве — времени компиляции.
ИМХО, если не со следующей версии, то с послеследующей надо делать переход без обратной совместимости, как это было при переходе с Джава 1 на Джава 2.
Почему так тормозится развитие Джавы и так летит вперёд.НЕТ? Одна из важнейших причин — обратная совместимость. Код, скомпилированный в Джаве 1.6 скорее всего беспричинно запустится в рантайме 1.5. Поэтому дженерики в.НЕТ — рантайм, а в Джаве — времени компиляции.
ИМХО, если не со следующей версии, то с послеследующей надо делать переход без обратной совместимости, как это было при переходе с Джава 1 на Джава 2.
Сам джавист, но поработал полтора года на C#.
C# гораздо вкуснее в плане синтаксиса языка.
Так неуютно в Java без свойств, замыканий, событий, да и по LINQ тоже скучаю. Ощущения будто снова пересел с Java 1.5 на Java 1.4
C# гораздо вкуснее в плане синтаксиса языка.
Так неуютно в Java без свойств, замыканий, событий, да и по LINQ тоже скучаю. Ощущения будто снова пересел с Java 1.5 на Java 1.4
Ну свойства это чисто сахар, думаю какая нибудь IDE спокойно может по переменным сгенерить get; set; методы, чтоб ручками не писать.
Linq to Object аналога в java не знаю, а вот по теме linq to SQL — есть такая штука в jpa 2.0 — JPQL
en.wikipedia.org/wiki/Java_Persistence_Query_Language
Есть ещё jaque — code.google.com/p/jaque/
Но хотелось бы конечно всё это иметь из коробки.
Или вы имели ввиду в целом Linq со всеми его providers? тогда да)
Linq to Object аналога в java не знаю, а вот по теме linq to SQL — есть такая штука в jpa 2.0 — JPQL
en.wikipedia.org/wiki/Java_Persistence_Query_Language
Есть ещё jaque — code.google.com/p/jaque/
Но хотелось бы конечно всё это иметь из коробки.
Или вы имели ввиду в целом Linq со всеми его providers? тогда да)
Таки попробуйте Scala. Свойства, замыкания и события там как бы и есть, но при этом «без лишних сущностей», LINQ — сами понимаете, в общем всё на месте «и на вкус приятная», IMHO.
Вместо LINQ действительно есть JPA с JPQL причем там еще в наличии NativeQuery и описание ORM через аннотации, что в Entity Framework появилось только вот вот, недавно насколько помню на хабре писали про это. Ну а замыкания и свойства это сильно на любителя.
Использование аттрибутов, которые позже появились в Java как аннотации, использовалось в EF с самого начала его существования, как и в Linq2SQL.
Можно мне ссылку на MSDN? Вот я в свое время искал как в Entity Framework вместо xml описания ORM использовать атрибуты. Т.е. чтобы ORM настройка содержала только информацию о источнике данных. Остальное должно браться из атрибутов и позволять настраивать вид ключей и колонок.
Если вы имеете в виду POCO, то да, они появились только в четвертом EF, хотя в NHibernate были уже давно. Если вас не они интересуют, то думаю эта ссылка будет полезной: msdn.microsoft.com/en-us/library/bb347884.aspx
п.с. можете еще POCO генератор на Т4 залить, он доступен в лайв темплейтах 10 студии
п.с. можете еще POCO генератор на Т4 залить, он доступен в лайв темплейтах 10 студии
Не тешьте себя иллюзиями. Свойства, в отличие от синхронизованных методов (в данном случае — связанных сеттеров в Java) не обеспечивают атомарности изменения состояния объекта.
Код, скомпилированный под 1.6, не запустится на 1.5. А вот наоборот почти всегда получается.
А почему тогда каждый Java Update отдельно ставится, вместо того чтобы просто себя проапдейтить?
Залог существования джавы — аскетичность, однозначность решения, железный порядок, поддерживаемый во всем, начиная от именования методов и кончая javadoc. Возможность делать «что угодно» не всем кажется привлекательной. Синтаксис не должен быть пересахаренным.
Абсолютно согласен, меня дико порой дико раздражает возможность в том же руби сделать одно и то же двумя-тремя разными способами, я имею ввиду чисто синтаксически. Приходится вводить не только конвенции именования и стиля кода, но и конвенции на использование одинакового синтаксиса.
Вы правы в том смысле, что Java как язык нет смысла перегружать кучей сахара.
С другой стороны, добавление в JVM тех же замыканий пойдет на пользу многим языкам для JVM. Например, Clojure теряет значительную долю производительности из-за повсеместной генерации анонимных классов там, где используются лямбды.
С другой стороны, добавление в JVM тех же замыканий пойдет на пользу многим языкам для JVM. Например, Clojure теряет значительную долю производительности из-за повсеместной генерации анонимных классов там, где используются лямбды.
нюню… я думаю что может случиться тоже самое что с коболом. Он вроди и как бы жив, но и в то же время мертв.
Если Оракакл продолжит свою политику, то от явы как платформы отвернуться. И будет ява жить только в банках, как сейчас кобол на мейнфреймах.
Если Оракакл продолжит свою политику, то от явы как платформы отвернуться. И будет ява жить только в банках, как сейчас кобол на мейнфреймах.
> Если Оракакл продолжит свою политику, то от явы как платформы отвернуться.
какую политику? ускорение JSR да так, что один в этом году, один в следующем? Со всеми вкусностями, что коммьюнити ждало годами?
Полноценная поддержка и развитие?
Что именно не нравится в политике Оракла?
какую политику? ускорение JSR да так, что один в этом году, один в следующем? Со всеми вкусностями, что коммьюнити ждало годами?
Полноценная поддержка и развитие?
Что именно не нравится в политике Оракла?
как вы хорошо ведетесь на подачки и крохи, а то что поставщики альтернативной реализации явы, явасервера и аппсервера потихоньку чмыряться и ограничиваются — это фигня.
> как вы хорошо ведетесь на подачки и крохи
угу, JSR и развиие языка — это такая подачка и крохи, ага. И вообще полноценное развитие языка — это крохи, ага :))) Ну, с таким альтернативно одаренным мышлением даже спорить бесполезно.
> поставщики альтернативной реализации явы, явасервера и аппсервера потихоньку чмыряться и ограничиваются
prooflink или не было
угу, JSR и развиие языка — это такая подачка и крохи, ага. И вообще полноценное развитие языка — это крохи, ага :))) Ну, с таким альтернативно одаренным мышлением даже спорить бесполезно.
> поставщики альтернативной реализации явы, явасервера и аппсервера потихоньку чмыряться и ограничиваются
prooflink или не было
> Oracle will deliver two Java Development Kit (JDK) based on the OpenJDK project — one free and the other paid.
Не читайте перед завтраком советских газет. Даже на хабре это уже обсуждео, и не раз.
> Oracle, meanwhile, is converging its JRockit Virtual Machine and the Hotspot JVM from Sun Microsystems. The converged JVM will be released under the OpenJDK project.
Круто же
> On December 7, 2010, by a vote of 12 YES and 3 NO votes, the EC approved the Java 7 and Java 8 JSRs and TCKs
Круто же. То, что Sun и базар © не могли сделать на протяжении скольки? 6 лет?
> under license terms which are fundamentally incompatible with open source.
All code in OpenJDK is released under GPLv2 with the same restrictions and grants as any other GPLv2 licensed software. In addition, Oracle provides a free TCK to any OpenJDK-derived implementation without Field-of-Use restrictions.
Перевод: когда Опенсорс лицензирует свои продукты, как хочет, все молчат. Но Оракл — это злозлозлозлозлозлозлозлозло, потому что они лицензируют свои продукты, как хотят.
Самое смешное, что Oracle просто повторили то, что делали Sun.
Ну и т.д. и т.п.
Не читайте перед завтраком советских газет. Даже на хабре это уже обсуждео, и не раз.
> Oracle, meanwhile, is converging its JRockit Virtual Machine and the Hotspot JVM from Sun Microsystems. The converged JVM will be released under the OpenJDK project.
Круто же
> On December 7, 2010, by a vote of 12 YES and 3 NO votes, the EC approved the Java 7 and Java 8 JSRs and TCKs
Круто же. То, что Sun и базар © не могли сделать на протяжении скольки? 6 лет?
> under license terms which are fundamentally incompatible with open source.
All code in OpenJDK is released under GPLv2 with the same restrictions and grants as any other GPLv2 licensed software. In addition, Oracle provides a free TCK to any OpenJDK-derived implementation without Field-of-Use restrictions.
Перевод: когда Опенсорс лицензирует свои продукты, как хочет, все молчат. Но Оракл — это злозлозлозлозлозлозлозлозло, потому что они лицензируют свои продукты, как хотят.
Самое смешное, что Oracle просто повторили то, что делали Sun.
Ну и т.д. и т.п.
Да и вообще сначала Оракл закрывает проекты, потом под давлением сообщества возвращает.
Я всё понимаю, но действовать как проститутка не стоит.
Та же ситуация с MySQL и InnoDB, когда они убрали его из поставки, а после поднятого хая, вернули в последней стабильной версии.
Я всё понимаю, но действовать как проститутка не стоит.
Та же ситуация с MySQL и InnoDB, когда они убрали его из поставки, а после поднятого хая, вернули в последней стабильной версии.
> Да и вообще сначала Оракл закрывает проекты, потом под давлением сообщества возвращает.
пруфлинк или не было
> Та же ситуация с MySQL и InnoDB, когда они убрали его из поставки, а после поднятого хая, вернули в последней стабильной версии.
www.readwriteweb.com/cloud/2010/11/oracle-drops-innodb-from-mysql.php
InnoDB is still available for free on the MySQL Community edition. Ведь нас именно бесплатные сыры интересуют? В Community Edition InnoDB никуда не девался. А в любых других продуктах Oracle волен делать все, что его душе угодно.
пруфлинк или не было
> Та же ситуация с MySQL и InnoDB, когда они убрали его из поставки, а после поднятого хая, вернули в последней стабильной версии.
www.readwriteweb.com/cloud/2010/11/oracle-drops-innodb-from-mysql.php
InnoDB is still available for free on the MySQL Community edition. Ведь нас именно бесплатные сыры интересуют? В Community Edition InnoDB никуда не девался. А в любых других продуктах Oracle волен делать все, что его душе угодно.
Забейте, не кормите) Зачем снова и снова повторять одно и то же для людей, которые даже соседние комментарии прочитать не могут. Они просто «где-то слышали», нафиг им ваши ссылки :) Это всё на хабре ни по разу обсуждалось, там были кучи ссылок (в том числе от меня) на официальные источники, опровергающие каждый из этих истеричных топиков про оракл/джаву, короче, неблагодарное это дело.
Даже если Oracle, что маловероятно, вообще свернёт Java, то есть OpenJDK и большое сообщество людей, готовых работать над развитием этой технологии, и никаких резонов «отворачиваться от платформы» я не наблюдаю.
Mono can be run on Android, BSD, iOS, Linux, Mac OS X, Windows, Solaris, and Unix operating systems as well as some game console operating systems such as the ones for the PlayStation 3, Wii, and Xbox 360.
враки. Берем Paint net и запускаем. Если работает, я не прав, если нет — Вы.
При чем тут официальный или нет? Mono по большей части это реализация стандарта ECMA.
При том, что и в СССР изготавливали ЭВМ. Вы их видите? Я нет. Есть понятие «в теории», а есть практика. Запустится SPB Wallet или Paint NET. Значит Да, работает .NET (пусть заменитель MONO). Нет? Значит нет. Вон народ на 100 метров ныряет, но это не значит что человек может нырять на 100 метров. Специально обученный, да. Обычный нет. Так, что говорить о каких-то призрачных программах под .NET не на платформе Windows преждевременно. Поэтому его как-бы и нет.
Я вам еще раз повторяю — Mono это реализация стандартов ECMA (на С#, CLR и т.д.), а не «альтернативная» среда для запуска .NET приложений в линуксе. И Mono — кросплатформенное решение, потому как предоставляет СВОЙ рантайм для поддерживаемых платформ, включая и Win — чувствуете разницу? И то, что .NET и Mono реализуют общие стандарты на CLR в частности позволяет запускать хеловорды и там и там.
Так дело не в хэлловордах. Можно полноценную, более-менее сложную, нормально (грамотно) написанную программу на C# запустить на Mono без допиливания? Я не знаю.
Hello World'ы — да. Но не «wrote and run anywhere». Приходится вставлять костыли, чтобы под моно программы начали работать. + ко всему наблюдается спад производительности работы программы под Mono. Под рукой нет сейчас дистрибутива линукса, но думаю вы и сами сможете найти примеры.
В Ubuntu дефолтовый менеджер фотографий F-Spot работает как-раз под Mongo. Но он распостраняется только под *nix. О возможность портирования в Win/Mac ничего не знаю. Возможно она слишком сложна.
А я и не говорил про «wrote and run anywhere». Более того, я как раз и пытаюсь опровергнуть расхожее заблуждение о том, что Mono «это такой .NET для линукса». Но если вы будете изначально писать на Mono, и будете запускать свое ПО на его же рантайме (под Win, Lin, Mac — не важно) — у вас будет кросплатформенное решение.
Ну вот мы и сравниваем Java которая работает. И .NET который windows only. Это как сравнивать что больше 10 или красный цвет. В RGB представлении может и красный цвет больше 10, я не знаю. Для написания софта? .NET народу нравится C# за его плюшки. Народу нравится Java за то, что он выучил ее 10 лет назад и с тех пор просто работает. Не меряется генериками и прочим. А просто пишет софт и получает за это свои деньги. И что софт написанный 5 лет назад продолжает приносить деньги и просто работать.
Никогда Моно ни до чего не дорастёт если МС не поменяет свою стратегию (а они не поменяют, разве что совсем продажи упадут и будут пытаться продавать хоть что-то). А стратегия у МС — винды и виндозавязанные решения во всём. .NET автоматически означает Винды, IIS, VisualStudio, и какбы подразумевает MS SQL, не так ли? МС нужно именно это, чтоб всё это покупали у них и МС получал profit. Кроссплатформенность им даром не нужна — им нужны Винды в каждом доме и на каждом сервере.
Кто-нибудь возмётся серьёзный коммерческий проект разрабатывать на линухах под Моно и запускать в продакшне под Моно? На даный момент ну очень очень маловероятно.
В случае с Java единственная реальная опасность — попытка такой же коммерциализации от Oracle. Тоесть что будут вещи завязанные на JDeveloper, WebLogic, подразумевающие Oracle RDBMS и т.п.
Но какбы понятно что Ораклу и за 10 лет даже при наличии дичайшего желания (которого не будет потому как коммюнити обламается) до такого уровня взаимозависимости частей как у МС не дойти.
Есть такой джавишный подкаст Javapossee, там в одном из эпизодов товарищ, недавно перешедший в Оракл, рассказывал, что Оракл очень зависит от «экосистемы», потому как у них кроме RDBMS почти всё на Java, у них несколько тысяч джава программистов. И если они распугают и испортят коммюнити то им же первым будет плохо даже в том смысле что негде будет кадры брать. Не говоря уже о том чтоб переписать все решения с Java на что-то другое — это практически невозможно. Поэтому Oracle меньше всех заинтересован в смерти Java (что логично — она ведь ему принадлежит).
Кто-нибудь возмётся серьёзный коммерческий проект разрабатывать на линухах под Моно и запускать в продакшне под Моно? На даный момент ну очень очень маловероятно.
В случае с Java единственная реальная опасность — попытка такой же коммерциализации от Oracle. Тоесть что будут вещи завязанные на JDeveloper, WebLogic, подразумевающие Oracle RDBMS и т.п.
Но какбы понятно что Ораклу и за 10 лет даже при наличии дичайшего желания (которого не будет потому как коммюнити обламается) до такого уровня взаимозависимости частей как у МС не дойти.
Есть такой джавишный подкаст Javapossee, там в одном из эпизодов товарищ, недавно перешедший в Оракл, рассказывал, что Оракл очень зависит от «экосистемы», потому как у них кроме RDBMS почти всё на Java, у них несколько тысяч джава программистов. И если они распугают и испортят коммюнити то им же первым будет плохо даже в том смысле что негде будет кадры брать. Не говоря уже о том чтоб переписать все решения с Java на что-то другое — это практически невозможно. Поэтому Oracle меньше всех заинтересован в смерти Java (что логично — она ведь ему принадлежит).
Попробуйте Mono. Но особо я на него не расчитывал бы. Все таки .NET позиционирует себя как windows-платформа.
P.S. Сам заядлый .NET программист
P.S. Сам заядлый .NET программист
Вот эти языки умеют компилироваться в байткод JVM.
>не предоставляет языковой поддержки для замыканий, лямбд,
Да, они кстати появятся в jdk 8 (конец 2012 года)
>работы с коллекциями, регулярными выражениями
Что имеется ввиду?
>MSSQL сервер так же умеет хостить CLR и поддерживает,
>насколько я знаю, написание хранимых процедур на нем.
Oracle еще до покупки Sun поддерживает написание хранимых процедур на Java
Но в целом я согласен с автором, поддержка новых языков был бы сильный ход со стороны Oracle/Sun.
>не предоставляет языковой поддержки для замыканий, лямбд,
Да, они кстати появятся в jdk 8 (конец 2012 года)
>работы с коллекциями, регулярными выражениями
Что имеется ввиду?
>MSSQL сервер так же умеет хостить CLR и поддерживает,
>насколько я знаю, написание хранимых процедур на нем.
Oracle еще до покупки Sun поддерживает написание хранимых процедур на Java
Но в целом я согласен с автором, поддержка новых языков был бы сильный ход со стороны Oracle/Sun.
ага или вот: www.postgresql.org/about/ Тут нет ни C#, ни F#. Зато Java есть.
>работы с коллекциями, регулярными выражениями
Что имеется ввиду?
Имеется в виду работа с ними на уровне языка. Как в Питоне или Groovy.
С коллекциями это например так: groovy.codehaus.org/Collections
А с регулярками например, так: mantonov.blogspot.com/2011/01/groovy.html Когда вы работаете с паттернами, матчерами и прочим на уровне синтаксиса, когда есть операторы для этого. Определить паттерн, проверить матчинг и прочее.
Что имеется ввиду?
Имеется в виду работа с ними на уровне языка. Как в Питоне или Groovy.
С коллекциями это например так: groovy.codehaus.org/Collections
А с регулярками например, так: mantonov.blogspot.com/2011/01/groovy.html Когда вы работаете с паттернами, матчерами и прочим на уровне синтаксиса, когда есть операторы для этого. Определить паттерн, проверить матчинг и прочее.
>Да, они кстати появятся в jdk 8 (конец 2012 года)
Вот это и грустно — раньше все говорили что С# — копия Java, а теперь выходит что Java догоняет С#.
Кстати то же самое с «генериками» — для меня это был самым большим ударом, когда я увидел как они реализовали (я говорю про то, что после компиляции вся информация о генерик-типах пропадает и List становится List'ом) в то время, как в С# 2.0 полноценно реализовали (кстати, вопрос к тем кто следит за тем, что будет в 8-ой версии — решились все-таки на сохранение типов генериков в байт-коде или нет? Насколько я знаю, это было сделано для совместимости с 1.4).
Вот это и грустно — раньше все говорили что С# — копия Java, а теперь выходит что Java догоняет С#.
Кстати то же самое с «генериками» — для меня это был самым большим ударом, когда я увидел как они реализовали (я говорю про то, что после компиляции вся информация о генерик-типах пропадает и List становится List'ом) в то время, как в С# 2.0 полноценно реализовали (кстати, вопрос к тем кто следит за тем, что будет в 8-ой версии — решились все-таки на сохранение типов генериков в байт-коде или нет? Насколько я знаю, это было сделано для совместимости с 1.4).
а теперь выходит что Java догоняет С#.Тише едешь — дальше будешь)
Дженерики первыми появились в Java 5.0, и только потом их внедрили в C#.Net 2.0. У разработчиков Microsoft просто был карт-бланш на то, чтобы сделать их лучше, чем в Java.
я думаю с выходом Java 7 станет понятно что вообще происходит :)
Ну давайте подумаем про предприятие. Берем например то, где работаю я. Сервера 8-шт Linux + 1 Windows 2003.
И где мне гонять .NET? Купленный хостинг тоже не Windows.
Будет .NET под OpenBSD, FreeBSD, Mac OS X. Будет .NET под Simbian под Android, MeeGO. Тогда есть о чем говорить. В противном случае я даже не знаю о его преимуществах по сравнению с Java. Он просто не работает. (Mono не предлагайте, вот когда на нем будет запускаться 90% .NET программ не написанных для него специально будем говорить.)
И где мне гонять .NET? Купленный хостинг тоже не Windows.
Будет .NET под OpenBSD, FreeBSD, Mac OS X. Будет .NET под Simbian под Android, MeeGO. Тогда есть о чем говорить. В противном случае я даже не знаю о его преимуществах по сравнению с Java. Он просто не работает. (Mono не предлагайте, вот когда на нем будет запускаться 90% .NET программ не написанных для него специально будем говорить.)
извиняюсь, но на FreeBSD и OpenBSD _официальной_ java нет ) есть неофициальная, но никем серьёзно не поддерживаемая.
Весь вопрос не в магическом «поддерживается» А в том работает или нет. Mono поддерживается. Java работает.
Я бы лично не рассчитывал на 99.9999%, что с java у freebsd всё в порядке. Куда проще использовать линукс и не иметь непознанных проблем вида «чего-то оно ошибку выдаёт».
Поддерживаю предыдущего комментатора, на BSD нередко встречаются проблемы с Java. Но обычно какими-нибудь шаманствами так или иначе всё решается своими силами (и силами комьюнити нашего продукта).
А как на BSD с .NET? Расскажите
Нет, вот это я не расскажу уже) Ибо статистикой не располагаю. И под .net практически не пишу, не больше какой-нибудь заклёпки под готовый проект на mono. Но думаю, в рамках mono всё должно работать, ибо BSD заявлена как поддерживаемая система, но, повторюсь, ничего не знаю достоверно о статистике и подводных камнях. Зато про Java могу сказать точно, ибо на BSD ставят нашу систему, а пишем мы на Java.
Java всё так же будет оставаться COBOL'ом XXI века. .NET всё так же будет перспективной и возлагающими большие надежды.
Эх, я просто процитирую Джеймса Гослинга (создателя Java), который ушел из Sun после покупки Oracle: «Just about anything I could say that would be accurate and honest would do more harm than good.”
Простите, но если создатель Java говорит так, что перспективы Java мне кажутся слишком смутными.
Лично мое мнение такое: сейчас назрел момент, когда должно появится что-то, что станет потомком идеи Java (и JVM), но не будет связанно патентными ограничениями и лицензиями как .NET и Oracle Java. ИМХО именно этого сейчас ожидают очень многие, и возможно уже где-то есть хорошее решение, которое просто еще недостаточно известное.
Что бы не говорили холиварщики, но и .NET хорош (а иногда просто отличен — гляньте то, насколько динамично он развивается: уже на носу .NET 5 с асинками), но и Java (в виде до покупки Oracle) очень интересен для Enterprise-решений (включая уже упомянутую концепцию „write once, run anywhere“).
В общем… я очень надеюсь на сильного конкурента .NET-у, и мне очень и очень жаль Java — ну слишком уж агрессивны Oracle.
Простите, но если создатель Java говорит так, что перспективы Java мне кажутся слишком смутными.
Лично мое мнение такое: сейчас назрел момент, когда должно появится что-то, что станет потомком идеи Java (и JVM), но не будет связанно патентными ограничениями и лицензиями как .NET и Oracle Java. ИМХО именно этого сейчас ожидают очень многие, и возможно уже где-то есть хорошее решение, которое просто еще недостаточно известное.
Что бы не говорили холиварщики, но и .NET хорош (а иногда просто отличен — гляньте то, насколько динамично он развивается: уже на носу .NET 5 с асинками), но и Java (в виде до покупки Oracle) очень интересен для Enterprise-решений (включая уже упомянутую концепцию „write once, run anywhere“).
В общем… я очень надеюсь на сильного конкурента .NET-у, и мне очень и очень жаль Java — ну слишком уж агрессивны Oracle.
Perl6? :o)
Если это было серьезное предположение, то лично я думаю что нет. Проблема перла — его мульти-парадигмость… Есть и ООП в какой-то мере, и ФП… а по сути он начинал как обычный итеративный язык. Ентерпрайзу нужна строгость, которую даже «use strict» плохо обеспечивает.
В общем, честно говоря, я думаю тут гадать и спорить бесполезно — рынок покажет. Тут главное следить за тенденциями.
В общем, честно говоря, я думаю тут гадать и спорить бесполезно — рынок покажет. Тут главное следить за тенденциями.
Вы не в теме и вспоминаете про Perl5. А я вам про www.parrot.org/
Помойму вы немного путаете для чего в современном мире используется Java. Сейчас java прежде всего используется в enterprise решениях, а так же в серверных backend'ах. А тут самое важное быстродействие и стабильность, в принципе если посмотреть, что происходит с java от 1.5 до 1.7, то по факту добавились библиотеки для concurrent и быстродействия как в целом JVM, так и Garbage collector. Плюс в 1.7 обновиться NIO, что опять же важно только в серверных решениях(к примеру большое количество коннекций на одном сервере, лично писал сервер с 40000 одновременных соединений, и все летало весьма шустро). К примеру под .net нету серьезных серверных приложений(хотя тут понятно, мало кто хочет иметь backend на платформе windows).
Вообщем мое мнение такое, если вы хотите красивый, удобный язык для десктопных приложений, то можете использовать любой язык, как существующий так и создавать новые языки, но пока нету альтернативы java для enterprise и backend'a. Как бы не развивался .net, но пока его среда только десктоп, и возможно веб, да и то на счет веба не уверен, т.к. у java благодаря google есть отличный вариант в виде GWT, чего опять же нету у .net'a.
P.S. под .net почти ничего не писал, и мои знания формируются из общения со знакомыми кто пишет на .net и новостей, статей из интернета.
Вообщем мое мнение такое, если вы хотите красивый, удобный язык для десктопных приложений, то можете использовать любой язык, как существующий так и создавать новые языки, но пока нету альтернативы java для enterprise и backend'a. Как бы не развивался .net, но пока его среда только десктоп, и возможно веб, да и то на счет веба не уверен, т.к. у java благодаря google есть отличный вариант в виде GWT, чего опять же нету у .net'a.
P.S. под .net почти ничего не писал, и мои знания формируются из общения со знакомыми кто пишет на .net и новостей, статей из интернета.
Мне всё же кажется, что первичны языки. Java стала популярной не только из-за ее кросс-платформенности, но и поскольку это был простой и красивый язык, позволяющий сосредоточиться на том, что нужно сделать.
Опять-таки, сообщества, как мне кажется, возникают более активно вокруг языков, нежели вокруг платформ.
Опять-таки, сообщества, как мне кажется, возникают более активно вокруг языков, нежели вокруг платформ.
> При этом эти языки написаны и отлаживаются либо группами комьюнити (например, Groovy разрабатывается SpringSource комьюнити)
Что за «SpringSource комьюнити»? SpringSource — компания, в которой где-то 5 человек занимаются фул-тайм разработкой Groovy & Grails. Плюс плагин для Eclipse, который лежит в основе Grails пишут тоже люди из VmWare/SpringSource.
Так же 3 разработчиков JRuby работают в EngineYard, им тоже платят за работу на JRuby. Rhino(JavaScript on JVM) разрабатывается Mozilla & Google. Ментейнер Jython работает в Canonical.
Java — это экосистема и комньюнити, Oracle хоть теперь и является разработчиком референсной реализации платформы, вовсе не обязан браться за всё. Microsoft кстати перевёл разработчиков IronRuby & IronPython на другие проекты, а сами их отдал сообществу. Так что я бы не был столь категоричен о том, что будущее настолько сильно зависит Multi-language VM.
Что за «SpringSource комьюнити»? SpringSource — компания, в которой где-то 5 человек занимаются фул-тайм разработкой Groovy & Grails. Плюс плагин для Eclipse, который лежит в основе Grails пишут тоже люди из VmWare/SpringSource.
Так же 3 разработчиков JRuby работают в EngineYard, им тоже платят за работу на JRuby. Rhino(JavaScript on JVM) разрабатывается Mozilla & Google. Ментейнер Jython работает в Canonical.
Java — это экосистема и комньюнити, Oracle хоть теперь и является разработчиком референсной реализации платформы, вовсе не обязан браться за всё. Microsoft кстати перевёл разработчиков IronRuby & IronPython на другие проекты, а сами их отдал сообществу. Так что я бы не был столь категоричен о том, что будущее настолько сильно зависит Multi-language VM.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного мыслей о будущем платформы Java