Сегодня пришла рекламка от db4o — показались интересным две новости:
"Sharpen" Translates your Java Application Sources to C#
*db4o opens its "secret tool" so that everyone can benefit from a super smart db4o created "cross-platform" Java-to-.NET translator. To learn more, and to find the repository, documentation and bug tracking for "Sharpen" read this blog post.
*Get started on how to use "Sharpen" with a sample application and short startup guide.
*You are all invited to enhance and augment to fit your needs. Please give us your feedback in the Sharpen forum.
Ну о подобных системах слышал, правда юзать не юзал. Не было надобности. Но теоретически Java на шарп переносить несложно(кроме некоторых вещей типа выгрузки классов). Обратно немного сложнее.
db4objects is Leading a Community Effort to Promote LINQ for Java
* LINQ for Java follows db4objects approach of Native Queries. To know more about this initiative read Carl's blog.
* Having a common interface on .NET and Java that is natively supported would create a easy to use, efficient standard for database developers.
* To read along or participate in this effort join the JLINQ group.
Вот я абсолютно не понял... Невозможное возможно? Язык будут менять, и дорабатывать? Доработка то будет кардинальная.
GZ>"Sharpen" Translates your Java Application Sources to C#
Меня терзают смутные сомнения (с)
Как допустим перенести код который использует метод из стандартной джавовской библиотеки, но у которого нет аналога на дот нете ? по крайней мере однозначного. и как быть с несколькими версиями ферймворка...
[skipped] GZ>Вот я абсолютно не понял... Невозможное возможно? Язык будут менять, и дорабатывать? Доработка то будет кардинальная.
Чего не посмотрели блог помянутого в новости Карла Розенберга? Цитирую:
If you think that LINQ for Java is a great idea, please add your +1 vote to this thread.
I have also posted an outline with the principle plan:
1. Collect supporters in the LINQ-for-Java group
2. Start the LINQ-for-Java Open Source project (probably using the Google Code hosting system)
3. Implement a free (as in freedom) prototype
4. Promote LINQ-for-Java with key industry players
5. File a Java JSR
6. Create a reference implementation
7. Promote LINQ-for-Java as the standard database access layer for Java
If you are in for this plan, please help.
Карлу ставлю, пожалуй, -1. Во-первых, каким образом он собирается в Java вводить LINQ в том виде, в котором он сейчас представлен в .NET, в то время как в Java нет полноценных замыканий — бежит со своей маленькой хотелкой впереди паровоза? Во-вторых, честно говоря, несмотря на общий ажиотаж от MS-рекламы, не считаю, что LINQ на данный момент дал нечто существенно новое в отношении работы с РБД. В Java community длинная история использования ORM-ов, в которых потребность в инструментах подобных LINQ, безусловно, все равно присутствует, но не настолько остро, чтобы все бросать и бежать менять язык программирования ради того — там есть свои аналогичные (но не настолько удобные, конечно) инструменты, ну а запросы вручную (на т.н. именованном языке запросов к persistent objects) вообще пишутся достаточно редко.
Здравствуйте, rsn81, Вы писали:
R>If you are in for this plan, please help.[/q]Карлу ставлю, пожалуй, -1. Во-первых, каким образом он собирается в Java вводить LINQ в том виде, в котором он сейчас представлен в .NET, в то время как в Java нет полноценных замыканий — бежит со своей маленькой хотелкой впереди паровоза?
Ну судя по всему — будет. И замыкания, и extension методы, и вывод типов. Java7. Только сейчас посмотрел — доработки языка действительно намечаются кардинальные. Жалко разобраться — времени совсем нет.
Здравствуйте, GlebZ, Вы писали:
GZ>Ну судя по всему — будет. И замыкания, и extension методы, и вывод типов. Java7. Только сейчас посмотрел — доработки языка действительно намечаются кардинальные. Жалко разобраться — времени совсем нет.
Ага, будет... когда-нибудь.
JSR-а по замыканиям пока даже нет, там только план хотелки (JSR Proposal: Closures for Java) без присвоенного номера.
Поверьте, LINQ — не самая приоритетная вещь, которой не хватает и о которой мечтают Java-программисты. Было бы неплохо, но лучше бы сделали: closures, runtime generics, OSGi, вывод типов. Немного забавно, что .NET-программисты так сопереживают за своих коллег по мейнстриму, быть может даже жалеют Java-программистов, которым, беднягам, как-то приходится общаться с РБД без поддержки LINQ. Тоже... нашли за что жалеть.
Здравствуйте, GlebZ, Вы писали:
GZ>Ну судя по всему — будет. И замыкания, и extension методы, и вывод типов. Java7. Только сейчас посмотрел — доработки языка действительно намечаются кардинальные. Жалко разобраться — времени совсем нет.
То что кто-то где-то обсуждает closures ещё не значит что их включат в Java 7. И я уже даже сильно подозреваю что не включат. Тоже относится ко многим другим фичам.
Здравствуйте, rsn81, Вы писали:
R>Ага, будет... когда-нибудь. R>JSR-а по замыканиям пока даже нет, там только план хотелки (JSR Proposal: Closures for Java) без присвоенного номера.
После появления C# — Java быстро развивается. Конкуренция, однака. Так что загадывать не стоит.
R>Поверьте, LINQ — не самая приоритетная вещь, которой не хватает и о которой мечтают Java-программисты. Было бы неплохо, но лучше бы сделали: closures, runtime generics, OSGi, вывод типов.
Ну кроме OSGi — приведенные тобой вещи нужны для реализации Linq. R>Немного забавно, что .NET-программисты так сопереживают за своих коллег по мейнстриму, быть может даже жалеют Java-программистов, которым, беднягам, как-то приходится общаться с РБД без поддержки LINQ. Тоже... нашли за что жалеть.
1. Я не являюсь большим фанатом ни одного языка. Язык — всего лишь инструмент для достижения цели. Мне по фиг на чем писать, С#, Java, С++ или вообще assembler. Главное чтобы этот инструмент был оптимален для решения данной цели.
2. У тебя неверное представление о Linq. Linq — дает очень полезный инструмент работы с коллекциями. Linq — это часть языка С# который позволяет использовать некоторую функциональщину при работе с коллекциями. Очень удобная фича. То что можно также достучаться до БД или XML или Hibernate — это уже не фича языка. Это фича библиотеки. Жить без него можно, но при наличии лямбд жизнь становится слаще.
3. К сожалению развитие Java все время обходило стороной функциональный стиль. Рано или поздно придется предоставить некоторые подобные средства. Иначе он будет устаревать. Может время пришло?
Здравствуйте, GlebZ, Вы писали:
GZ>3. К сожалению развитие Java все время обходило стороной функциональный стиль. Рано или поздно придется предоставить некоторые подобные средства. Иначе он будет устаревать. Может время пришло?
Получится Scala?
Здравствуйте, Blazkowicz, Вы писали:
GZ>>3. К сожалению развитие Java все время обходило стороной функциональный стиль. Рано или поздно придется предоставить некоторые подобные средства. Иначе он будет устаревать. Может время пришло? B>Получится Scala?
Не дай бог! Индийцы пишущие на Scala?
У Скала и Java — разная целевая аудитория.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
R>>в то время как в Java нет полноценных замыканий ANS>"полноценные" это какие?
Вероятно подразумевается что анонимные классы это и есть неполноценные замыкания, которые уже есть в Java.
Здравствуйте, Blazkowicz, Вы писали:
R>>>в то время как в Java нет полноценных замыканий ANS>>"полноценные" это какие? B>Вероятно подразумевается что анонимные классы это и есть неполноценные замыкания, которые уже есть в Java.
перефразирую вопрос. Чем именно, то что есть в java, неполноценные замыкания?
Здравствуйте, Blazkowicz, Вы писали:
B>То что кто-то где-то обсуждает closures ещё не значит что их включат в Java 7. И я уже даже сильно подозреваю что не включат. Тоже относится ко многим другим фичам. здесь
Очевидно под полноценным closures имелось ввиду:
o closure literals (sometimes called lambda expressions)
GlebZ,
GZ>>>3. К сожалению развитие Java все время обходило стороной функциональный стиль. Рано или поздно придется предоставить некоторые подобные средства. Иначе он будет устаревать. Может время пришло? B>>Получится Scala? GZ>Не дай бог! Индийцы пишущие на Scala? GZ>У Скала и Java — разная целевая аудитория.
Твой тезис всё же не мешало бы пояснить. В Скале конечно есть жосткие языковые конструкции, но они в-основном нужны для написания библиотек максимальной степени универсальности. Юзеры (=индийцы) будут просто наследовать от нужных типов, создавать нужные инстансы и вызывать нужные методы. Нет?
Здравствуйте, GlebZ, Вы писали:
GZ>После появления C# — Java быстро развивается. Конкуренция, однака. Так что загадывать не стоит. GZ>1. Я не являюсь большим фанатом ни одного языка. Язык — всего лишь инструмент для достижения цели. Мне по фиг на чем писать, С#, Java, С++ или вообще assembler. Главное чтобы этот инструмент был оптимален для решения данной цели.
Аналогично. Мечтаю все бросить: C# и Java — и писать на Scala.
GZ>2. У тебя неверное представление о Linq. Linq — дает очень полезный инструмент работы с коллекциями. Linq — это часть языка С# который позволяет использовать некоторую функциональщину при работе с коллекциями. Очень удобная фича. То что можно также достучаться до БД или XML или Hibernate — это уже не фича языка. Это фича библиотеки. Жить без него можно, но при наличии лямбд жизнь становится слаще.
Во-первых, представление о LINQ у меня вполне сносное: если бы вы внимательно читали меня, то обратили внимание, что я везде писал только о LINQ в отношении работы с реляционными данными. Волнует это, понимаете ли, меня по работе, а то что LINQ — это язык работы с множествами... ну я рад за него. Во-вторых, до объектов отображения NHibernate LINQ-ом не достучаться — это заблуждение: библиотека LINQ2NHibernate не готова. В-третьих, на данный момент при наличии ORM-а жизнь с РБД намного слаще, чем сожительство с той же РБД без ORM, но c LINQ.
GZ>3. К сожалению развитие Java все время обходило стороной функциональный стиль. Рано или поздно придется предоставить некоторые подобные средства. Иначе он будет устаревать. Может время пришло?
Мне кажется, Java продолжит придерживаться консерватизма.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>перефразирую вопрос. Чем именно, то что есть в java, неполноценные замыкания?
Анонимные локальные (объявленные внутри метода) классы Java имеют только доступ по чтению к final-переменным и чтению-записи членов родительского класса по this, а нужен только полный доступ ко всем локальным переменным в соответствующей области видимости.
Здравствуйте, rsn81, Вы писали:
R>Карлу ставлю, пожалуй, -1. Во-первых, каким образом он собирается в Java вводить LINQ в том виде, в котором он сейчас представлен в .NET, в то время как в Java нет полноценных замыканий — бежит со своей маленькой хотелкой впереди паровоза?
В JDK7 они с большой вероятностью будут. А JSR, в любом случае, удовольствие на несколько лет...
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
GZ>>У Скала и Java — разная целевая аудитория. LCR>Твой тезис всё же не мешало бы пояснить. В Скале конечно есть жосткие языковые конструкции, но они в-основном нужны для написания библиотек максимальной степени универсальности. Юзеры (=индийцы) будут просто наследовать от нужных типов, создавать нужные инстансы и вызывать нужные методы. Нет?
1. IMHO Я не большой спец в Java среде, но система типов Scala на порядок мощнее чем система типов Java. Таким образом бесшовно это пройти не может. В Net есть понятия CLS совместимости — совместимости по типам. Но все же она используется значительно редко в силу второй причины.
2. Очень плохо иметь два стандартных языка. Теряется взаимозаменяемость, и понятие кода как документация(дополнительная, или основная). А фактически, это добровольное выращивание программистов — священных коров, которых будет значительно тяжелее заменить в процессе проекта. Все таки стандарт кодирования должен быть один — Java, или Scala или ... rsn81 — прав. Язык — это инструмент. Вещь важная — но есть вещи более важные для успешной реализации проектов.
Здравствуйте, rsn81, Вы писали:
R>Во-первых, представление о LINQ у меня вполне сносное: если бы вы внимательно читали меня, то обратили внимание, что я везде писал только о LINQ в отношении работы с реляционными данными. Волнует это, понимаете ли, меня по работе, а то что LINQ — это язык работы с множествами... ну я рад за него.
Да, но мы говорим о фичах языка, а не фичах библиотек.
R>Во-вторых, до объектов отображения NHibernate LINQ-ом не достучаться — это заблуждение: библиотека LINQ2NHibernate не готова.
Maybe. Не пытался, поэтому не знаю. Не удивлюсь если это останется рекламной компанией Microsoft.
R>В-третьих, на данный момент при наличии ORM-а жизнь с РБД намного слаще, чем сожительство с той же РБД без ORM, но c LINQ.
Это опять вопрос библиотек. Хибернейт — не единственный ORM для доступа к РБД. Есть например iBatis.
Тут дело даже не в Linq как языка запросов, а в инструментах при этом предоставленных. lambda, extension methods, type inference — очень упрощают жизнь и делает язык более доступным для прототипирования. Когда волнует не то как будет сделано, а что должно быть сделано — эти инструменты очень востребованы.
R>Мне кажется, Java продолжит придерживаться консерватизма.
В последнее время это было незаметно.
Здравствуйте, GlebZ, Вы писали:
GZ>Да, но мы говорим о фичах языка, а не фичах библиотек.
Не знаю, значит я оффтоп завел: говорю лишь о практической применимости.
GZ>Maybe. Не пытался, поэтому не знаю. Не удивлюсь если это останется рекламной компанией Microsoft. Re: NHiberniate = (Generic + что-то дополнительно) ?
GZ>Это опять вопрос библиотек. Хибернейт — не единственный ORM для доступа к РБД. Есть например iBatis. GZ>Тут дело даже не в Linq как языка запросов, а в инструментах при этом предоставленных. lambda, extension methods, type inference — очень упрощают жизнь и делает язык более доступным для прототипирования. Когда волнует не то как будет сделано, а что должно быть сделано — эти инструменты очень востребованы.
Да кто спорит...
GZ>В последнее время это было незаметно.
Эт вы о чем? Застой же полный...
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
