Сегодня пришла рекламка от 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.

Вот я абсолютно не понял... Невозможное возможно? Язык будут менять, и дорабатывать? Доработка то будет кардинальная.

Здравствуйте, GlebZ, Вы писали:

GZ>

GZ>"Sharpen" Translates your Java Application Sources to C#

Меня терзают смутные сомнения (с)
Как допустим перенести код который использует метод из стандартной джавовской библиотеки, но у которого нет аналога на дот нете ? по крайней мере однозначного. и как быть с несколькими версиями ферймворка...

Здравствуйте, GlebZ, Вы писали:

[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) вообще пишутся достаточно редко.

По поводу JLINQ, возможно, речь про продукт IBM — pureQuery: Understanding pureQuery, Part 1: pureQuery: IBM's new paradigm for writing Java database applications. Save time, write little code, run everywhere. Опять же по сути просто ORM.

Здравствуйте, 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 — разная целевая аудитория.

Здравствуйте, rsn81, Вы писали:

R>в то время как в 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 + что-то дополнительно) ?

Автор: rsn81
Дата: 16.05.08

GZ>Это опять вопрос библиотек. Хибернейт — не единственный ORM для доступа к РБД. Есть например iBatis.
GZ>Тут дело даже не в Linq как языка запросов, а в инструментах при этом предоставленных. lambda, extension methods, type inference — очень упрощают жизнь и делает язык более доступным для прототипирования. Когда волнует не то как будет сделано, а что должно быть сделано — эти инструменты очень востребованы.
Да кто спорит...

GZ>В последнее время это было незаметно.
Эт вы о чем? Застой же полный...

Здравствуйте, GlebZ, Вы писали:

GZ>1. IMHO Я не большой спец в Java среде, но система типов Scala на порядок мощнее чем система типов Java. Таким образом бесшовно это пройти не может. В Net есть понятия CLS совместимости — совместимости по типам. Но все же она используется значительно редко в силу второй причины.
Scala замечательно интероперирует с Java. Вызовы Java из Скалы абсолютно прозрачны, с обратными вызовами тоже особых проблем нет.

GZ>2. Очень плохо иметь два стандартных языка. Теряется взаимозаменяемость, и понятие кода как документация(дополнительная, или основная). А фактически, это добровольное выращивание программистов — священных коров, которых будет значительно тяжелее заменить в процессе проекта.
Можно сравнить ситуацию с C# и VB.NET. Java постепенно становится этаким VB.NET'ом, а Scala имеет все шансы стать аналогом C#.

Тем более, что IntelliJ анонсировали поддержку Scala в следующей IDEA.

Здравствуйте, rsn81, Вы писали:

ANS>>перефразирую вопрос. Чем именно, то что есть в java, неполноценные замыкания?
R>Анонимные локальные (объявленные внутри метода) классы Java имеют только доступ по чтению к final-переменным и чтению-записи членов родительского класса по this, а нужен только полный доступ ко всем локальным переменным в соответствующей области видимости.

Всё это суета. "Полный доступ" это синтаксический сахар к тому, что сейчас есть. Литеральный синтаксис — тоже.

Имхо, через неявное создание одноэлементного массива и сделан "полный доступ" из замыкания в VW ST. Так что это мелкая синтаксическая неприятность. А вот изначально в ST-80 были неполноценные замыкания. Это выражалось в том, что недо-замыкания созданные в одной лексической точке разделяли между собой слоты для входных и временных параметров. Вот это и есть "недо".

Здравствуйте, rsn81, Вы писали:

R>В-третьих, на данный момент при наличии ORM-а жизнь с РБД намного слаще, чем сожительство с той же РБД без ORM, но c LINQ.

Ну его нафиг такую сладость

Автор: Andrei N.Sobchuck
Дата: 08.01.08

. Для толстого клиента конечно можно ипользовать ORM. Тут ни память ни проц — не ресурс А на сервере любая разновидность библиотеки для работы с реляционной алгеброй (будь то ST, или C# LINQ) гораздо полезнее.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Ну его нафиг такую сладость

Автор: Andrei N.Sobchuck
Дата: 08.01.08

. Для толстого клиента конечно можно ипользовать ORM. Тут ни память ни проц — не ресурс А на сервере любая разновидность библиотеки для работы с реляционной алгеброй (будь то ST, или C# LINQ) гораздо полезнее.
Вы там по ссылке правильно написали, что каждое блюдо надо просто уметь правильно приготовить.

Здравствуйте, GlebZ, Вы писали:

После чтения этого сообщения у меня один вопрос появился.

А возможно ли в будущем слияние Java и C# в некий единый язык ?

И если да — желательно ли ?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А возможно ли в будущем слияние Java и C# в некий единый язык ?
PD>И если да — желательно ли ?
Возможно всё. .NET CLR и JVM очень похожи друг на друга.

Но смысла особого мало.

Здравствуйте, Cyberax, Вы писали:

C>Возможно всё. .NET CLR и JVM очень похожи друг на друга.
C>Но смысла особого мало.
Ага. Возможно, что и все страны мира когда-нибудь объединяться, ведь все мы, человеки, очень похожи друг на друга. Но смысла особого мало.

"Товарищ, верь,
Взойдет она,
Звезда пленительного счастья..." © А. С. Пушкин

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>А возможно ли в будущем слияние Java и C# в некий единый язык ?
PD>>И если да — желательно ли ?
C>Возможно всё. .NET CLR и JVM очень похожи друг на друга.

C>Но смысла особого мало.

Мне что-то ситуация с .Net и Java напоминает противоречия между троцкистами и сталинистами. В чем они заключались — бог знает, многие считают, что Сталин реализовал программу Троцкого. Но бились они насмерть.
Вообще известно, что самые заклятые враги получаются из тех, чьи позиции почти совпадают с твоими. Почти!

Здравствуйте, Pavel Dvorkin, Вы писали:

C>>Но смысла особого мало.
PD>Мне что-то ситуация с .Net и Java напоминает противоречия между троцкистами и сталинистами. В чем они заключались — бог знает, многие считают, что Сталин реализовал программу Троцкого. Но бились они насмерть.
Нет, у .NET и Java во многом разные идеологии к подходам разработки. Технически они похожи настолько, что есть автоматические трансляторы .NET CLR <-> JVM.

Здравствуйте, Cyberax, Вы писали:

C>Нет, у .NET и Java во многом разные идеологии к подходам разработки. Технически они похожи настолько, что есть автоматические трансляторы .NET CLR <-> JVM.
А можно про разные идеологии подходов к разработке чуть подробнее?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>И если да — желательно ли ?
Нежелательно. Пока есть борьба противоречий (Microsoft vs Sun и К), среды развиваются семимильными шагами. Лучше так, чем аморфный, но счастливый, застой.

Здравствуйте, rsn81, Вы писали:

C>>Нет, у .NET и Java во многом разные идеологии к подходам разработки. Технически они похожи настолько, что есть автоматические трансляторы .NET CLR <-> JVM.
R>А можно про разные идеологии подходов к разработке чуть подробнее?
В Java предпочитают более красивые и стройные решения, а в .NET — по большей части то, что легко использовать 90% новичков.

Здравствуйте, Cyberax, Вы писали:

C>В Java предпочитают более красивые и стройные решения, а в .NET — по большей части то, что легко использовать 90% новичков.
Согласен. Но это одна сторона монеты, есть другая: в сравнении флагманских языков платформ именно Java ориентируется на дятлов: Re[8]: [офф] небольшой вопрос по LINQ

Автор: rsn81
Дата: 01.11.07

.

Здравствуйте, rsn81, Вы писали:

C>>В Java предпочитают более красивые и стройные решения, а в .NET — по большей части то, что легко использовать 90% новичков.
R>Согласен. Но это одна сторона монеты, есть другая: в сравнении флагманских языков платформ именно Java ориентируется на дятлов: Re[8]: [офф] небольшой вопрос по LINQ

Автор: rsn81
Дата: 01.11.07

.
Да, в самом языке именно такая ситуация. В основном из-за того, что сам язык развивает только солнцевская братва, а технологии развивает, в основном, сommunity.

Здравствуйте, Cyberax, Вы писали:

R>>А можно про разные идеологии подходов к разработке чуть подробнее?
C>В Java предпочитают более красивые и стройные решения, а в .NET — по большей части то, что легко использовать 90% новичков.
Интересно, почему люди не согласны?

Здравствуйте, Cyberax, Вы писали:

C>В Java предпочитают более красивые и стройные решения,

Непонятное утверждение. Что, дженерики времени компиляции, без поддержки рантайма — это стройное и красивое решение?

Здравствуйте, nikov, Вы писали:

C>>В Java предпочитают более красивые и стройные решения,
N>Непонятное утверждение. Что, дженерики времени компиляции, без поддержки рантайма — это стройное и красивое решение?
Я же написал, что кроме языкового уровня.

В Java более красивые библиотеки. Сравни SWING и WinForms, например.

Здравствуйте, Cyberax, Вы писали:

C>В Java более красивые библиотеки. Сравни SWING и WinForms, например.
Есть примеры и получше. Сложно закрыть глаза на то, сколько архитектурных решений .NET достаточно нагло передрал (не преобразовал, а практически тупо 1 в 1 преобразовал на уровне кода) у Java: NUnit, NHibernate, log4net, NFop и т.п — все родом из Java.

Здравствуйте, nikov, Вы писали:

N>Непонятное утверждение. Что, дженерики времени компиляции, без поддержки рантайма — это стройное и красивое решение?
Аллокация генерик-типа рефлектором в .NET — а это, тоже красивое-стройное решение?

Здравствуйте, Cyberax, Вы писали:

C>>В Java предпочитают более красивые и стройные решения, а в .NET — по большей части то, что легко использовать 90% новичков.
C>Интересно, почему люди не согласны?
Скорее всего потому что работают по жизни только на MS-технологиях и потому что уже давно не новички.

Cyberax,

R>>А можно про разные идеологии подходов к разработке чуть подробнее?
C>В Java предпочитают более красивые и стройные решения, а в .NET — по большей части то, что легко использовать 90% новичков.

Оригинальное видение, однако.

Здравствуйте, Cyberax, Вы писали:

C>Интересно, почему люди не согласны?
Потому что "красивые и стройные" решения отдают конкретным овердизайном, а местами просто кривые. =)

Здравствуйте, Cyberax, Вы писали:

C>В Java более красивые библиотеки. Сравни SWING и WinForms, например.
Ты лучше с WPF сравни..

Здравствуйте, IB, Вы писали:

C>>В Java более красивые библиотеки. Сравни SWING и WinForms, например.
IB>Ты лучше с WPF сравни..
Наш ответ Чемберлену — это JavaFX

Здравствуйте, IB, Вы писали:

C>>Интересно, почему люди не согласны?
IB>Потому что "красивые и стройные" решения отдают конкретным овердизайном, а местами просто кривые. =)
Овердизайн — это к официальным стандартам от Sun. А произведения community, как раз, почти всегда очень практичны.

Здравствуйте, Cyberax, Вы писали:

C>В Java более красивые библиотеки. Сравни SWING и WinForms, например.

А почему не с WPF?

Здравствуйте, Lloyd, Вы писали:

C>>В Java более красивые библиотеки. Сравни SWING и WinForms, например.
L>А почему не с WPF?
WinForms появился раньше. Это как раз современник Swing'а.

Здравствуйте, Cyberax, Вы писали:

C>WinForms появился раньше. Это как раз современник Swing'а.
Не, я конечно понимаю твое стремление на груди рубаху порвать, но ты все-таки аккуратнее, а то совсем голый останешься... =)
"... first released on December 16, 1996." (с) википедия. WinForms тогда еще в проекте не было. При этом в Яве с самого начала был AWT, а вовсе не Swing, вот его еще можно как-то с WinForms сравнивать.
К моменту появления WinForms Swing-у уже было больше пяти лет, WinForms — же разрабатывался вообще с нуля, для абсолютно новой платформы.
Так что иди теперь и с WPF-ом меряйся, а то придумал тут, маленьких обижать...

Здравствуйте, IB, Вы писали:

C>>WinForms появился раньше. Это как раз современник Swing'а.
IB>Не, я конечно понимаю твое стремление на груди рубаху порвать, но ты все-таки аккуратнее, а то совсем голый останешься... =)
Ну я ещё могу вспоминть Spring, Log4Java, Ant, Maven. Hibernate вспоминать не буду — у тебя на неё аллергия.

IB>"... first released on December 16, 1996." (с) википедия. WinForms тогда еще в проекте не было. При этом в Яве с самого начала был AWT, а вовсе не Swing, вот его еще можно как-то с WinForms сравнивать.
AWT задумывался с другими целями — обеспечить "наименьший общий знаменатель" для всех платформ, отсюда и дизайн.

WinForms начали разрабатываться где-то в 99 году, как я понимаю. Так что они вполне современники, разница всего где-то в два года.

IB>К моменту появления WinForms Swing-у уже было больше пяти лет, WinForms — же разрабатывался вообще с нуля, для абсолютно новой платформы.
Вот смысл в том, что у WinForms получилось архитектурно хуже.

IB>Так что иди теперь и с WPF-ом меряйся, а то придумал тут, маленьких обижать...
Жду JavaFX, а там можно и меряться будет

Здравствуйте, Cyberax, Вы писали:

C>Ну я ещё могу вспоминть Spring, Log4Java, Ant, Maven.
ObjectBuilder, WCF, WWF, CAB, да вообще весь EL, там этих красивых архитектурных решений на все случаи жизни, хоть попой ешь, начиная от лога и заканчивая обработкой исключений. MSBuild, наконец, раз уж ты Ant вспомнил..

C>AWT задумывался с другими целями — обеспечить "наименьший общий знаменатель" для всех платформ, отсюда и дизайн.
"С рождения" были AWT и WinForms вот их и сравнивай.

C>WinForms начали разрабатываться где-то в 99 году, как я понимаю. Так что они вполне современники, разница всего где-то в два года.
Если из 99 вычесть 96 то два не получается никак. При этом ты сравниваешь публичный релиз и начало разработки. Не устал еще передергивать? =)

C>Вот смысл в том, что у WinForms получилось архитектурно хуже.
В бакграунде у свинга была ява, AWT и четкое понимание что и для чего делается, у WinForms-а не было ничего, даже платформы.

C>Жду JavaFX, а там можно и меряться будет
А сейчас типа слабо? Ну и не вылезайте тогда со своей "архитектурой"..
В яве, поглядев на AWT разработали Swing — честно передрав идею со смоллтолка, в Net посмотрев на WinForms разработали WPF. Аналогия ясна, что с чем сравнивать надо?

Здравствуйте, rsn81, Вы писали:

R>Есть примеры и получше. Сложно закрыть глаза на то, сколько архитектурных решений .NET достаточно нагло передрал (не преобразовал, а практически тупо 1 в 1 преобразовал на уровне кода) у Java: NUnit, NHibernate, log4net, NFop и т.п — все родом из Java.

IMHO, после истории с ява-машиной от M$ обсуждать кто у кого там что передрал как-то поздно...

Здравствуйте, IB, Вы писали:

C>>Ну я ещё могу вспоминть Spring, Log4Java, Ant, Maven.
IB>ObjectBuilder
Появился полтора года назад. Spring'у уже более 5 лет, и до него ещё были предшественники.

IB>WCF, WWF, CAB, да вообще весь EL, там этих красивых архитектурных решений на все случаи жизни, хоть попой ешь, начиная от лога и заканчивая обработкой исключений.
WCF/WWF — красивые игрушки.

IB>MSBuild, наконец, раз уж ты Ant вспомнил..
MSBuild как раз сдирали с Ant'а. А пока сдирали — появился Maven, аналога для которого в .NET нет.

C>>AWT задумывался с другими целями — обеспечить "наименьший общий знаменатель" для всех платформ, отсюда и дизайн.
IB>"С рождения" были AWT и WinForms вот их и сравнивай.
Т.е. авторы WinForms даже не смотрели на то как дела в Java были?

C>>WinForms начали разрабатываться где-то в 99 году, как я понимаю. Так что они вполне современники, разница всего где-то в два года.
IB>Если из 99 вычесть 96 то два не получается никак. При этом ты сравниваешь публичный релиз и начало разработки. Не устал еще передергивать? =)
Первый Swing накатали за год, как библиотеку над AWT (его вообще можно было скачать в виде одного jar'а). Ладно, пусть будет три года.

C>>Вот смысл в том, что у WinForms получилось архитектурно хуже.
IB>В бакграунде у свинга была ява, AWT и четкое понимание что и для чего делается, у WinForms-а не было ничего, даже платформы.
Ой, да ну. И даже опыта Delphi не было? Так что ты тоже передёргиванием заканчивай заниматься.

C>>Жду JavaFX, а там можно и меряться будет
IB>А сейчас типа слабо? Ну и не вылезайте тогда со своей "архитектурой"..
Не слабо, релиз планируют этим летом.

IB>В яве, поглядев на AWT разработали Swing — честно передрав идею со смоллтолка, в Net посмотрев на WinForms разработали WPF. Аналогия ясна, что с чем сравнивать надо?
Swing со Smalltalk'а не делался, его с чистого листа начинали. Там вообще с ним отдельная интересная история была.

Здравствуйте, Cyberax, Вы писали:

C>Появился полтора года назад. Spring'у уже более 5 лет, и до него ещё были предшественники.
Ну и что? Ява вообще раньше появилась, толку-то. Если тебе предшественники нужны, то вон Winsdor есть..

C>WCF/WWF — красивые
Ну а мы здесь о чем говорим? =) Ты хотел примеров красивой и стройной архитектуры — на, кушай.. Ява до такого еще не доросла.. )

C> игрушки.
"Ну, вот это ты со зла.." Это ява твоя — игрушка, плюшевая.. =) Не разбираешься — не лезь.. ))

C>А пока сдирали — появился Maven, аналога для которого в .NET нет.
Как нет, а TFS ? =)

C>Т.е. авторы WinForms даже не смотрели на то как дела в Java были?
WinForms решал почти те же задачи, что стояли перед AWT. Вот их можешь и по сравнивать...

C>Первый Swing накатали за год, как библиотеку над AWT (его вообще можно было скачать в виде одного jar'а). Ладно, пусть будет три года.
Ты упорно сравниваешь время выпуска релиза и время начала разработки. При этом, не очень понятно причем тут вообще время, сравнивать конечный результат надо.
Я вот сейчас тоже первый релиз явы с четвертым шарпом посравниваю, знаешь как забавно будет? =)

C>Ой, да ну. И даже опыта Delphi не было?
Ну вот по второй VCL и получили, на первом этапе, все закономерно.

C>Не слабо, релиз планируют этим летом.
То есть слабо. =)

C>Swing со Smalltalk'а не делался, его с чистого листа начинали. Там вообще с ним отдельная интересная история была.
Да-да-да. Россия — родина слонов.. ))

Здравствуйте, IB, Вы писали:

C>>Появился полтора года назад. Spring'у уже более 5 лет, и до него ещё были предшественники.
IB>Ну и что? Ява вообще раньше появилась, толку-то. Если тебе предшественники нужны, то вон Winsdor есть..
Первая ревизия была закоммичена 2004-10-20, а сколь-либо реальный код появился в 2006-м и релизом 1.0rc3 в сентябре прошлого года. Для сравнения, Spring появился в 2003 с релизом 1.0 в 2004 году.

При этом Spring далеко не первым DI-контейнером был. Он был первым контейнером, с которым синтегрировали ВСЁ.

C>>WCF/WWF — красивые
IB>Ну а мы здесь о чем говорим? =) Ты хотел примеров красивой и стройной архитектуры — на, кушай.. Ява до такого еще не доросла.. )
До WCF — доросла и обошла. См. Spring Remoting, например.

C>> игрушки.
IB>"Ну, вот это ты со зла.." Это ява твоя — игрушка, плюшевая.. =) Не разбираешься — не лезь.. ))
А .NET — её бледная имитация.

C>>А пока сдирали — появился Maven, аналога для которого в .NET нет.
IB>Как нет, а TFS ? =)
А где: http://repo1.maven.org/maven2/ ?

Чтоб я мог написать:

            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring</artifactId>
                <version>2.0.3</version>
            </dependency>

И оно мне само бы всё из репозитория достало, сделало проект для IDE (любой, на выбор), подтянуло исходники с документацией и подключила в эту IDE. Аналоги TFS — это IDEA TeamCity + друзья.

Только не надо показывать на NMaven

C>>Т.е. авторы WinForms даже не смотрели на то как дела в Java были?
IB>WinForms решал почти те же задачи, что стояли перед AWT. Вот их можешь и по сравнивать...
Перед WinForms не стояла задача наименьшего общего знаменателя между кучей платформ. Ей нужно было только добиться совместимости со старым Win32 API.

C>>Первый Swing накатали за год, как библиотеку над AWT (его вообще можно было скачать в виде одного jar'а). Ладно, пусть будет три года.
IB>Ты упорно сравниваешь время выпуска релиза и время начала разработки. При этом, не очень понятно причем тут вообще время, сравнивать конечный результат надо.
C# начали разрабатывать в 99 году, и WinForms где-то в то же время.

C>>Ой, да ну. И даже опыта Delphi не было?
IB>Ну вот по второй VCL и получили, на первом этапе, все закономерно.
Так и пишем: "Не умеют учитывать опыт предыдущих проектов".

Что, собственно, я и говорил — в Java, как только появилась возможность, сделали архитектурно красивый Swing, а в C# — просто повторили VCL.

C>>Не слабо, релиз планируют этим летом.
IB>То есть слабо. =)
Ну я могу показать пререлизные демки с JavaOne.

C>>Swing со Smalltalk'а не делался, его с чистого листа начинали. Там вообще с ним отдельная интересная история была.
IB>Да-да-да. Россия — родина слонов.. ))
Что "да-да-да"?

Здравствуйте, Cyberax, Вы писали:

C>При этом Spring далеко не первым DI-контейнером был. Он был первым контейнером, с которым синтегрировали ВСЁ.
"Да, да и рентген тоже на нас запишите..." =)
Ява в принципе на много лет раньше появлиась, очевидно и библиотеки под нее раньше писались, что вовсе не говорит в пользу их качества.

C>До WCF — доросла и обошла. См. Spring Remoting, например.
Спринговскому ремотингу еще ползти и ползти до WCF.. )

C>А .NET — её бледная имитация.
О, яж говорю — не разбираешься =))

C>И оно мне само бы всё из репозитория достало, сделало проект для IDE (любой, на выбор), подтянуло исходники с документацией и подключила в эту IDE.
Нафига козе баян? Если IDE одна и сама в TFS интегрирована — это у вас все от бедности..

C> Ей нужно было только добиться совместимости со старым Win32 API.
И она этого с успехом добилась, какие претензии?

C>C# начали разрабатывать в 99 году, и WinForms где-то в то же время.
В двадцатый раз спрашиваю, почему ты сравниваешь время начала разработки одного продукта и время релиза другого? Сравнивать надо конечный результат.

C>Так и пишем: "Не умеют учитывать опыт предыдущих проектов".
Вот уж чего-чего, а учитывать опыт предыдущих лучше MS не умеет никто..

C>Что, собственно, я и говорил — в Java, как только появилась возможность, сделали архитектурно красивый Swing, а в C# — просто повторили VCL.
Нееет родной. В Net, ка ктолько появилась возможность сделали WPF.
Почему ты считаешь, что в яве с самого начала не было возможности, а в Net была? Передергиваешь.

C>Ну я могу показать пререлизные демки с JavaOne.
Пусть сначала до релиза доживет и будет хотя бы в половину настолько удачно сделано как WPF. =)
А пока слабо. Так что не лезь меряться раньше времени..

C>Что "да-да-да"?
Ну, что, по итогу, в Net стройных и красивых архитектурных решений больше чем в яве, и Net-у удалось избежать части явовских косяков, что вообщем-то закономерно, и не может не радовать..

Здравствуйте, IB, Вы писали:

C>>Так и пишем: "Не умеют учитывать опыт предыдущих проектов".
IB>Вот уж чего-чего, а учитывать опыт предыдущих лучше MS не умеет никто..
Это точно.
Вроде баян и тем не менее:

История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!

Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.

Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через браузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).

Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции «System File Protection», исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java — её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.

Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.

К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс- релизов. Главное, что нужно очень четко понимать — .NET исключает DLL Hell.

В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.

© Windows Development Journal, Рон Бурк

Здравствуйте, IB, Вы писали:

C>>И оно мне само бы всё из репозитория достало, сделало проект для IDE (любой, на выбор), подтянуло исходники с документацией и подключила в эту IDE.
IB>Нафига козе баян? Если IDE одна и сама в TFS интегрирована — это у вас все от бедности..

начну придираться к словам с другой стороны — "IDE одна", раз одна — нет конкуренции, нет конкуренции — остановка развития и сдирание трех шкур с клиента, т.е. ты признаешься что переплачиваешь за посредственный товар, так что это еще надо посмотреть кто быстрее беднеет лана, вернемся к платному ТФС, смотрю триал на сайте производителя, завернутый в имадж для виртуальной машины: Download Size до 5 Гб, Processor 2.0 GHz Pentium III+ (странно, всегда думал, что линейка Pentium III закончилась на 1.4 ГГц), Disk Space не менее 11.5 GB, RAM 1.5 GB. В общем какой-то тихий ужас по сравнению с мавен: Download Size меньше 2 Мб (поправьте если я ошибся), память, диск, ос — все No minimum requirement, требование процессора вообще нет. Короче не знаю что еще тут можно говорить...

C>> Ей нужно было только добиться совместимости со старым Win32 API.
IB>И она этого с успехом добилась, какие претензии?

никаких собсно, просто у джавы задача стояла охватить немного больше операционок чем win
все остальное не комментирую ибо просто поток каких-то негативных эмоций, пора в СВ переносить

Здравствуйте, rsn81, Вы писали:

R>Здравствуйте, IB, Вы писали:

C>>>Так и пишем: "Не умеют учитывать опыт предыдущих проектов".
IB>>Вот уж чего-чего, а учитывать опыт предыдущих лучше MS не умеет никто..
R>Это точно.
R>Вроде баян и тем не менее:

Бред

[]

Здравствуйте, goorov, Вы писали:

G>Короче не знаю что еще тут можно говорить...
Действительно, к чему ты это вообще сказал?

G>никаких собсно, просто у джавы задача стояла охватить немного больше операционок чем win
Это проблемы исключительно явы, почему .Net должен из-за этого страдать?..

IB пишет:
> Здравствуйте, goorov, Вы писали:
>
> G>Короче не знаю что еще тут можно говорить...
> Действительно, к чему ты это вообще сказал?
>
> G>никаких собсно, просто у джавы задача стояла охватить немного больше
> операционок чем win
> Это проблемы исключительно явы, почему .Net должен из-за этого страдать?..

Это проблемы исключительно разработчика, почему разработчик должен из–за
.NET страдать?..

--
ISO/IEC 8652:1995/Amd 1:2007

Здравствуйте, OCTAGRAM, Вы писали:

OCT>Это проблемы исключительно разработчика,
Какие у разработчика-то проблемы? =) Если только в голове...

OCT>почему разработчик должен из–за .NET страдать?..
Из-за .Net разработчики не страдают, они им наслаждаются..

IB пишет:
> Здравствуйте, OCTAGRAM, Вы писали:
>
> OCT>Это проблемы исключительно разработчика,
> Какие у разработчика-то проблемы? =) Если только в голове...
Если кроссплатформенность приложения — проблема в голове, то точно не в
голове разработчика.


--
ISO/IEC 8652:1995/Amd 1:2007

Здравствуйте, goorov, Вы писали:

G>начну придираться к словам с другой стороны — "IDE одна", раз одна — нет конкуренции, нет конкуренции — остановка развития и сдирание трех шкур с клиента, т.е. ты признаешься что переплачиваешь за посредственный товар, так что это еще надо посмотреть кто быстрее беднеет лана, вернемся к платному ТФС, смотрю триал на сайте производителя, завернутый в имадж для виртуальной машины: Download Size до 5 Гб, Processor 2.0 GHz Pentium III+ (странно, всегда думал, что линейка Pentium III закончилась на 1.4 ГГц), Disk Space не менее 11.5 GB, RAM 1.5 GB. В общем какой-то тихий ужас по сравнению с мавен: Download Size меньше 2 Мб (поправьте если я ошибся), память, диск, ос — все No minimum requirement, требование процессора вообще нет. Короче не знаю что еще тут можно говорить...
Можно говорить о том, что ты не понимаешь, что такое TFS и что такое Virtual Appliance. Хинт: Virtual Appliance для Maven+SVN+Bugzilla+JUnit+... будет весить примерно столько же, а работать чуть медленнее, чем TFS.

Здравствуйте, Sinclair, Вы писали:

S>Можно говорить о том, что ты не понимаешь, что такое TFS и что такое Virtual Appliance. Хинт: Virtual Appliance для Maven+SVN+Bugzilla+JUnit+... будет весить примерно столько же, а работать чуть медленнее, чем TFS.

скорее это не понимает товарищ IB, здесь

Автор: IB
Дата: 02.06.08

:

C>А пока сдирали — появился Maven, аналога для которого в .NET нет.
Как нет, а TFS ? =)

Здравствуйте, goorov, Вы писали:

G>

C>>А пока сдирали — появился Maven, аналога для которого в .NET нет.
G>Как нет, а TFS ? =)

Это он просто сразу из главного калибра выпалил. Потому как есть более легковесные аналоги Maven — TeamCity, и прочие.

Здравствуйте, Sinclair, Вы писали:

S>Можно говорить о том, что ты не понимаешь, что такое TFS и что такое Virtual Appliance. Хинт: Virtual Appliance для Maven+SVN+Bugzilla+JUnit+... будет весить примерно столько же, а работать чуть медленнее, чем TFS.
Хмм.. Для интереса попробовал собрать на основе своего MinDebian. Получилось 400Мб. Что я делаю не так?

В него входит:
1) Почти минимальный Debian.
2) Sun JVM 1.6.
3) JetBrains TeamCity.
4) Apache+SVN
5) Tomcat + Jira + Confluence.
Я ничего не настраивал, конечно, а просто побросал вместе распакованые дистрибутивы.

И можно ещё мегабайт 100 при желании убрать.

Здравствуйте, IB, Вы писали:

C>>При этом Spring далеко не первым DI-контейнером был. Он был первым контейнером, с которым синтегрировали ВСЁ.
IB>"Да, да и рентген тоже на нас запишите..." =)
IB>Ява в принципе на много лет раньше появлиась, очевидно и библиотеки под нее раньше писались, что вовсе не говорит в пользу их качества.
Зато .NET писался с опытом Microsoft Java, COM, VCL и др.

C>>До WCF — доросла и обошла. См. Spring Remoting, например.
IB>Спринговскому ремотингу еще ползти и ползти до WCF.. )
Куда? У него вот таких проблем: http://rsdn.ru/forum/message/2973510.1.aspx

Автор: anj78
Дата: 02.06.08

, по крайней мере, нет.

C>>А .NET — её бледная имитация.
IB>О, яж говорю — не разбираешься =))
Аналогично

C>>И оно мне само бы всё из репозитория достало, сделало проект для IDE (любой, на выбор), подтянуло исходники с документацией и подключила в эту IDE.
IB>Нафига козе баян? Если IDE одна и сама в TFS интегрирована — это у вас все от бедности..
Я на TFS смотрел. Лично мне там многие вещи неудобны (например, их система контроля версий). Как заменить? А никак.

C>> Ей нужно было только добиться совместимости со старым Win32 API.
IB>И она этого с успехом добилась, какие претензии?
Можно было красивее всё сделать. См.: htmlayout, например.

C>>C# начали разрабатывать в 99 году, и WinForms где-то в то же время.
IB>В двадцатый раз спрашиваю, почему ты сравниваешь время начала разработки одного продукта и время релиза другого? Сравнивать надо конечный результат.
Ну ладно, смотрим на WinForms образца 2006 года и SWING. Что лучше архитектурно?

C>>Так и пишем: "Не умеют учитывать опыт предыдущих проектов".
IB>Вот уж чего-чего, а учитывать опыт предыдущих лучше MS не умеет никто..
Точно, совершенно согласен. Например, они очень хорошо учитывают опыт обещания наличия семантической файловой системы в следующем релизе. Т.е. они каждый раз это обещают, начиная с начала 90-х, и каждый раз отменяют.

C>>Что, собственно, я и говорил — в Java, как только появилась возможность, сделали архитектурно красивый Swing, а в C# — просто повторили VCL.
IB>Нееет родной. В Net, ка ктолько появилась возможность сделали WPF.
Не "как только", а когда это было модным.

IB>Почему ты считаешь, что в яве с самого начала не было возможности, а в Net была? Передергиваешь.
Java 1.0 банально по ресурсам не могла бы держать не-нативный GUI. .NET вполне мог это делать и в начале 2000-х.

C>>Ну я могу показать пререлизные демки с JavaOne.
IB>Пусть сначала до релиза доживет и будет хотя бы в половину настолько удачно сделано как WPF. =)
IB>А пока слабо. Так что не лезь меряться раньше времени..
До релиза там уже ничего существенного не поменяется.

C>>Что "да-да-да"?
IB>Ну, что, по итогу, в Net стройных и красивых архитектурных решений больше чем в яве, и Net-у удалось избежать части явовских косяков, что вообщем-то закономерно, и не может не радовать..
Угу. Один сериализатор словарей в .NET чего стоит. Так "красиво" сделать его нужно было очень долго стараться.

Здравствуйте, Sinclair, Вы писали:

S> Это он просто сразу из главного калибра выпалил. Потому как есть более легковесные аналоги Maven — TeamCity, и прочие.
TeamCity — это не то. Это система continuous integration с кучей других полезных фич.

Maven — это система для постройки проекта, где я декларативно описываю сам проект и его зависимости, а Maven сам мне их потом скачивает из нужного репозитория (включая центральный с огромным количеством OpenSource-проектов) и линкует в проект.

Аналога на .NET для такого нет (точнее, есть NMaven, но он пока маленький и хилый).

Здравствуйте, OCTAGRAM, Вы писали:

OCT>Если кроссплатформенность приложения — проблема в голове, то точно не в
OCT>голове разработчика.
Ну, иными совами разработчик тут не причем.. ЧТД. Ты что сказать-то хотел? )

Здравствуйте, Cyberax, Вы писали:

C>Зато .NET писался с опытом Microsoft Java, COM, VCL и др.
Ну и получили в итоге намного более удачную конструкцию, что вообщем закономерно..

C>Куда?
До немерянной WCF-овской крутизны и красоты архитектуры — ты же ее алчешь.. =)

C>Аналогично
Вот видишь, ты же сам согласен, что нифига не разбираешься, чего шумишь тогда?

C>Я на TFS смотрел. Лично мне там многие вещи неудобны (например, их система контроля версий). Как заменить? А никак.
А и не надо, потомучто удобны.. =) Это у тебя идиосинкразия на продукты MS, а большинству разработчиков просто прикладную задачу решать надо, для них это достаточно удобный инструмент..

C>Можно было красивее всё сделать. См.: htmlayout, например.
Ну так и AWT, тоже, прямо скажем, не вершина совершенства, равно как и свинг. В чем претензия-то?

C>Ну ладно, смотрим на WinForms образца 2006 года и SWING. Что лучше архитектурно?
WPF конечно. =)

C>Точно, совершенно согласен. Например, они очень хорошо учитывают опыт обещания наличия семантической файловой системы в следующем релизе. Т.е. они каждый раз это обещают, начиная с начала 90-х, и каждый раз отменяют.
Ну что ты все с темы съезжаешь как маленький? =) Я знаю, у тебя MS во всем виноват, но это исключительно твое горе.

C>Не "как только", а когда это было модным.
Ах, так это мода виновата.. Не, ну прелесть, оказывается MS может сделать приличные вещи только если это модно, забавная трактовка...
Ну пусть хоть так. =)

C>Java 1.0 банально по ресурсам не могла бы держать не-нативный GUI. .NET вполне мог это делать и в начале 2000-х.
По ресурсам явовский GUI и в 2008 — не тянет, так что не аргумент.

C>До релиза там уже ничего существенного не поменяется.
работайте-работайте..

C>Угу. Один сериализатор словарей в .NET чего стоит. Так "красиво" сделать его нужно было очень долго стараться.
Хорошо, сериализатор дарю тебе, призовая игра.

Здравствуйте, Cyberax, Вы писали:

C>Maven — это система для постройки проекта, где я декларативно описываю сам проект и его зависимости, а Maven сам мне их потом скачивает из нужного репозитория (включая центральный с огромным количеством OpenSource-проектов) и линкует в проект.
Агрохренительная конструкция, а главное, жизненно необходимая.
Скачать из нужного репозитория и MSBuild умеет.. =)

C>Аналога на .NET для такого нет (точнее, есть NMaven, но он пока маленький и хилый).
Это как неуловимый Джо... Конечно нет.

Здравствуйте, IB, Вы писали:

IB>Агрохренительная конструкция, а главное, жизненно необходимая.
Ну в мире .NET, где ненавидят OpenSource — да, бессмысленно. А у меня, лично, в проекте используется что-то около 60 разных OpenSource-библиотек.

И что самое главное — мне пофиг какие там у них зависимости. Я их подключаю — и оно мне всё само скачивает, а потом пакует всё нужное в архив web-приложения и GUI-клиента.

IB>Скачать из нужного репозитория и MSBuild умеет.. =)
С транзитивными зависимостями? Можно увидеть пример?

C>>Аналога на .NET для такого нет (точнее, есть NMaven, но он пока маленький и хилый).
IB>Это как неуловимый Джо... Конечно нет.
Ещё бы. Не способны вы на такое.

Здравствуйте, Cyberax, Вы писали:

IB>>Это как неуловимый Джо... Конечно нет.
C>Ещё бы. Не способны вы на такое.
Дык если платить надо за библиотеки, то как-то стрёмно грузить "что загрузится", потому, что уже не пофиг...
В принципе, если тебе и на качество конечного продукта не пофиг, то тоже грузить "что загрузится" как-то стрёмно, да и с отладкой и разделением зон ответственности тема как-то не раскрыта...

Здравствуйте, IB, Вы писали:

C>>Зато .NET писался с опытом Microsoft Java, COM, VCL и др.
IB>Ну и получили в итоге намного более удачную конструкцию, что вообщем закономерно..
Но с предпочтением на фичи, которые удобны начинающим, но не особо архитектурно красивы.

C>>Куда?
IB>До немерянной WCF-овской крутизны и красоты архитектуры — ты же ее алчешь.. =)
Ну мне сам WCF, кстати, тоже не особо нравится. Но это детали...

C>>Аналогично
IB>Вот видишь, ты же сам согласен, что нифига не разбираешься, чего шумишь тогда?
Нет, я говорю, что ты тоже плохо разбираешься в Java

IB>А и не надо, потомучто удобны.. =) Это у тебя идиосинкразия на продукты MS, а большинству разработчиков просто прикладную задачу решать надо, для них это достаточно удобный инструмент..
TFS мне неудобен по вполне объективным критериям: нет встроеной поддержки для Линукса, и нет распределённой работы (да и вообще работа через медленные соединения с ним очень болезненная).

C>>Можно было красивее всё сделать. См.: htmlayout, например.
IB>Ну так и AWT, тоже, прямо скажем, не вершина совершенства, равно как и свинг. В чем претензия-то?
В том, что MS сделала не особо красивое решение изначально, хотя возможности были.

C>>Ну ладно, смотрим на WinForms образца 2006 года и SWING. Что лучше архитектурно?
IB>WPF конечно. =)
В 2006 его не было.

C>>Точно, совершенно согласен. Например, они очень хорошо учитывают опыт обещания наличия семантической файловой системы в следующем релизе. Т.е. они каждый раз это обещают, начиная с начала 90-х, и каждый раз отменяют.
IB>Ну что ты все с темы съезжаешь как маленький? =) Я знаю, у тебя MS во всем виноват, но это исключительно твое горе.
Ну не во всём. Например, у убийству президента Кеннеди, скорее всего, MS непричастен.

C>>Не "как только", а когда это было модным.
IB>Ах, так это мода виновата.. Не, ну прелесть, оказывается MS может сделать приличные вещи только если это модно, забавная трактовка...
IB>Ну пусть хоть так. =)

C>>Java 1.0 банально по ресурсам не могла бы держать не-нативный GUI. .NET вполне мог это делать и в начале 2000-х.
IB>По ресурсам явовский GUI и в 2008 — не тянет, так что не аргумент.
Ты видел IntelliJ IDEA? Так вот первая версия вполне успешно работала в начале 2000-х на SWINGе.

Здравствуйте, Cyberax, Вы писали:

C>Ну в мире .NET, где ненавидят OpenSource — да, бессмысленно.
Не, за ненавистью это не к нам. Это у OS какие-то нездоровые наклонности.. )

C>С транзитивными зависимостями? Можно увидеть пример?
Поставь, да посмотри. .)

C>Ещё бы. Не способны вы на такое.
=)))) Вот до чего ненависть доводит..

Здравствуйте, IB, Вы писали:

C>>Ну в мире .NET, где ненавидят OpenSource — да, бессмысленно.
IB>Не, за ненавистью это не к нам. Это у OS какие-то нездоровые наклонности.. )
Да, предпочитают открытые системы. Вот ведь ненормальные!

C>>С транзитивными зависимостями? Можно увидеть пример?
IB>Поставь, да посмотри. .)
Поставил, смотрю. Не вижу.

C>>Ещё бы. Не способны вы на такое.
IB>=)))) Вот до чего ненависть доводит..
Да, точно

Здравствуйте, Cyberax, Вы писали:

C>Но с предпочтением на фичи, которые удобны начинающим, но не особо архитектурно красивы.
Как мы только что убедились — это всего лишь твое заблуждение..

C>Ну мне сам WCF, кстати, тоже не особо нравится. Но это детали...
Это не делает архитектуру WCF менее стройной и красивой.

C>Нет, я говорю, что ты тоже плохо разбираешься в Java
Какой смысл возиться с устаревшими технологиями? Для того чтобы понять их ущербность мне знаний хватает..

C>В том, что MS сделала не особо красивое решение изначально, хотя возможности были.
Сдается мне, что ты не очень хорошо себе представляешь, что такое платформу с нуля собрать, пусть даже и силами MS.

C>В 2006 его не было.
Ну, так и мы не в 2006-м.

Здравствуйте, Cyberax, Вы писали:

C>Да, предпочитают открытые системы. Вот ведь ненормальные!
Вот, яж говорю — открытые системы разрушают мозг.. ))

C>Поставил, смотрю. Не вижу.
Ну, я тебе не доктор. .

C>Да, точно
Осознал? Первый шаг к выздоровлению. .

Здравствуйте, Cyberax, Вы писали:

C>Scala замечательно интероперирует с Java. Вызовы Java из Скалы абсолютно прозрачны, с обратными вызовами тоже особых проблем нет.

И как использовать case-классы из Явы?
Совместимость есть только сверх вниз. Скала язык более мощный. И использовать его могут только не обделенные интеллектом люди. Так что конечно совместимость есть, но она только годится для экспорта больших кусков функциональности запихнутых в классы. Та же фигня в дотнет и Немерле.

C>Можно сравнить ситуацию с C# и VB.NET. Java постепенно становится этаким VB.NET'ом, а Scala имеет все шансы стать аналогом C#.

Боюсь VB.NET 9 порвет Яву по всем параметрам.

C>Тем более, что IntelliJ анонсировали поддержку Scala в следующей IDEA.

Дай бог. Но боюсь, что они лоб разобьют о скалу.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Всё это суета. "Полный доступ" это синтаксический сахар к тому, что сейчас есть. Литеральный синтаксис — тоже.

Все на свете синтаксический сахар, ну кроме сахара-песка конечно.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>А возможно ли в будущем слияние Java и C# в некий единый язык ?

Да — русский матерный.

PD>И если да — желательно ли ?

Кому как.

Здравствуйте, rsn81, Вы писали:

R>Согласен. Но это одна сторона монеты, есть другая: в сравнении флагманских языков платформ именно Java ориентируется на дятлов: Re[8]: [офф] небольшой вопрос по LINQ

Автор: rsn81
Дата: 01.11.07

.

Шарп тоже на дятлов ориентируется. Дятлов много... в Инднии развилось нынче... Такие дела...

Здравствуйте, Cyberax, Вы писали:

C>В Java более красивые библиотеки. Сравни SWING и WinForms, например.

Ага. Или SWING и WPF.

ЗЫ

После такого откровенно фанатского заявления твои аргументы без смеха слушать невозможно. Увы.

Здравствуйте, Cyberax, Вы писали:

C>>>В Java более красивые библиотеки. Сравни SWING и WinForms, например.
L>>А почему не с WPF?
C>WinForms появился раньше. Это как раз современник Swing'а.
AWT еще раньше...

Здравствуйте, Cyberax, Вы писали:
C>В него входит:
C>1) Почти минимальный Debian.
Вот это, по большому счету, и не так.
C>2) Sun JVM 1.6.
ты собственно JRE поставил, или JDK?
C>3) JetBrains TeamCity.
C>4) Apache+SVN
C>5) Tomcat + Jira + Confluence.
C>Я ничего не настраивал, конечно, а просто побросал вместе распакованые дистрибутивы.
А где багзилла? А где JUnit? А где тул для подсчета Code Coverage? Где мускуль для базы данных этого всего?

C>И можно ещё мегабайт 100 при желании убрать.
На самом деле из Team System тоже можно убрать пару-тройку гигов.

Здравствуйте, Sinclair, Вы писали:

S>А где багзилла?

JIRA

S>А где JUnit?

Это копейки, меньше 1Мб. Включая плагин для Maven, который нарисует отчёт.

S>А где тул для подсчета Code Coverage?

Это тоже копейки. Cobertura + плагин для Мавена, который построит отчёт ~= 200Кб. Ещё, конечно, немного зависимостей будет, но это тоже копейки.

Впрочем, TeamCity похоже использует EMMA, которое тоже весит немного. 1Мб.

Здравствуйте, Cyberax, Вы писали:

C>Хмм.. Для интереса попробовал собрать на основе своего MinDebian. Получилось 400Мб.
Кстати, ты на чем собирал Virtual Appliance? VMWare?

Здравствуйте, Sinclair, Вы писали:

C>>1) Почти минимальный Debian.
S>Вот это, по большому счету, и не так.
То есть?

C>>2) Sun JVM 1.6.
S>ты собственно JRE поставил, или JDK?
JDK без документации и исходников. Собственно, из JRE легко делается JDK лёгким движением руки (добавлением каталога lib с компилятором).

C>>Я ничего не настраивал, конечно, а просто побросал вместе распакованые дистрибутивы.
S>А где багзилла? А где JUnit? А где тул для подсчета Code Coverage? Где мускуль для базы данных этого всего?
Это всё мегабайты. JUnit — что-то около 500Кб, emmma (тул для Code Coverage) — 600Кб, Багзилла — 12Мб (я же вроде бы написал, что добавл в эту смесь Jira и Confluence?).

Мускуль с базами — ну ещё 50 мегабайт максимум. Можно вместо него скромный PostgreSQL поставить, у него всех зависимостей на 20Мб.

C>>И можно ещё мегабайт 100 при желании убрать.
S>На самом деле из Team System тоже можно убрать пару-тройку гигов.
Appliance в 5Гб зато хорошо показывает подход MS.

Здравствуйте, Sinclair, Вы писали:

C>>Хмм.. Для интереса попробовал собрать на основе своего MinDebian. Получилось 400Мб.
S>Кстати, ты на чем собирал Virtual Appliance? VMWare?
В VirtualBox (оно совместимо с VMWare по формату дисков).

Здравствуйте, Erop, Вы писали:

C>>Ещё бы. Не способны вы на такое.
E>Дык если платить надо за библиотеки, то как-то стрёмно грузить "что загрузится", потому, что уже не пофиг...
Вот весь смысл в том, что для Java у меня всё нужное есть в OpenSource.

E>В принципе, если тебе и на качество конечного продукта не пофиг, то тоже грузить "что загрузится" как-то стрёмно, да и с отладкой и разделением зон ответственности тема как-то не раскрыта...
Работоспособность приложения проверяется QA-шниками, конкретные версии зависимых библиотек тут не важны. Посмотреть что именно загрузилось, конечно, не мешает (хотя бы раз), но потом об этом особо можно не заботиться.

А что не так с разделением зон ответственности?

Здравствуйте, Erop, Вы писали:

E>В принципе, если тебе и на качество конечного продукта не пофиг, то тоже грузить "что загрузится" как-то стрёмно, да и с отладкой и разделением зон ответственности тема как-то не раскрыта...
Вот, кстати, как выглядит отчёт о зависимостях для одного модуля приложения:

[INFO] [dependency:tree]
[INFO] com.sd:sd-server:war:292
[INFO] +- com.sd:common-lib:jar:292:compile
[INFO] +- com.sd:lake-lib:jar:292:compile
[INFO] +- com.sd:hib-bear-lib:jar:292:compile
[INFO] +- com.sd:sd-server-api:jar:292:compile
[INFO] +- org.hsqldb:hsqldb:jar:1.8.0:test
[INFO] +- org.apache.velocity:velocity:jar:1.5:compile
[INFO] |  +- commons-collections:commons-collections:jar:3.2.1:compile
[INFO] |  +- commons-lang:commons-lang:jar:2.1:compile
[INFO] |  \- oro:oro:jar:2.0.8:compile
[INFO] +- org.springframework:spring:jar:2.0.3:compile
[INFO] |  \- commons-logging:commons-logging:jar:1.1:compile
[INFO] |     +- logkit:logkit:jar:1.0.1:compile
[INFO] |     +- avalon-framework:avalon-framework:jar:4.1.3:compile
[INFO] |     \- javax.servlet:servlet-api:jar:2.3:compile
[INFO] +- org.springframework:spring-web:jar:2.0.3:compile
[INFO] |  +- org.springframework:spring-beans:jar:2.0.3:compile
[INFO] |  +- org.springframework:spring-context:jar:2.0.3:compile
[INFO] |  \- org.springframework:spring-core:jar:2.0.3:compile
[INFO] +- org.springframework:spring-remoting:jar:2.0.3:compile
[INFO] |  +- aopalliance:aopalliance:jar:1.0:compile
[INFO] |  \- org.springframework:spring-aop:jar:2.0.3:compile
[INFO] +- org.springframework:spring-hibernate3:jar:2.0.3:compile
[INFO] |  +- org.springframework:spring-dao:jar:2.0.3:compile
[INFO] |  \- org.springframework:spring-jdbc:jar:2.0.3:compile
[INFO] +- aspectj:aspectjrt:jar:1.5.3:compile
[INFO] +- aspectj:aspectjweaver:jar:1.5.3:compile
[INFO] +- org.hibernate:hibernate:jar:3.2.5.ga:compile
[INFO] |  +- net.sf.ehcache:ehcache:jar:1.2.3:compile
[INFO] |  +- javax.transaction:jta:jar:1.0.1B:compile
[INFO] |  +- asm:asm-attrs:jar:1.5.3:compile
[INFO] |  +- dom4j:dom4j:jar:1.6.1:compile
[INFO] |  +- antlr:antlr:jar:2.7.6:compile
[INFO] |  +- cglib:cglib:jar:2.1_3:compile
[INFO] |  \- asm:asm:jar:1.5.3:compile
[INFO] +- c3p0:c3p0:jar:0.9.1.2:compile
[INFO] +- org.acegisecurity:acegi-security:jar:1.0.5:compile
[INFO] |  \- commons-codec:commons-codec:jar:1.3:compile
[INFO] +- org.acegisecurity:acegi-security-tiger:jar:1.0.5:compile
[INFO] +- com.caucho:hessian:jar:2.1.12:runtime
[INFO] +- javax.activation:activation:jar:1.1:compile
[INFO] +- javax.mail:mail:jar:1.4:compile
[INFO] +- postgresql:postgresql:jar:8.3-603.jdbc4:compile
[INFO] +- opensymphony:quartz:jar:1.5.2:compile
[INFO] +- org.drools:drools-core:jar:4.0.7:compile
[INFO] |  \- org.mvel:mvel:jar:1.3.1-java1.4:compile
[INFO] +- org.drools:drools-compiler:jar:4.0.7:compile
[INFO] |  +- org.antlr:antlr-runtime:jar:3.0:compile
[INFO] |  +- org.eclipse.jdt:core:jar:3.2.3.v_686_R32x:compile
[INFO] |  +- janino:janino:jar:2.5.10:compile
[INFO] |  +- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] |  \- xerces:xercesImpl:jar:2.4.0:compile
[INFO] +- org.drools:drools-decisiontables:jar:4.0.7:compile
[INFO] |  \- jexcelapi:jxl:jar:2.4.2:compile
[INFO] +- jasperreports:jasperreports:jar:2.0.2:compile
[INFO] |  +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
[INFO] |  +- commons-digester:commons-digester:jar:1.7:compile
[INFO] |  +- com.lowagie:itext:jar:1.02b:compile
[INFO] |  +- jfree:jcommon:jar:1.0.0:compile
[INFO] |  +- jfree:jfreechart:jar:1.0.0:compile
[INFO] |  \- eclipse:jdtcore:jar:3.1.0:compile
[INFO] +- junit:junit:jar:3.8.1:runtime (scope not updated to compile)
[INFO] +- com.google.gwt:gwt-user:jar:1.4.60:provided
[INFO] +- com.google.gwt:gwt-servlet:jar:1.4.60:compile
[INFO] +- com.thapar.gwt:simpledatepicker:jar:1.0:compile
[INFO] +- com.google.code.p:gwtchismes:jar:0.4:compile
[INFO] +- org.gwtwidgets:gwtwidgets:jar:0.1.5:compile
[INFO] +- org.gwtwidgets:server:jar:0.1.4b:compile
[INFO] +- com.gwtext:gwtext:jar:0.9.3:compile
[INFO] \- log4j:log4j:jar:1.2.13:compile

Управлять всем этим вручную? Ну нафиг.

Здравствуйте, IB, Вы писали:

C>>Да, предпочитают открытые системы. Вот ведь ненормальные!
IB>Вот, яж говорю — открытые системы разрушают мозг.. ))
Точно! За каждую библиотеку нужно платить _минимум_ по $100!

C>>Поставил, смотрю. Не вижу.
IB>Ну, я тебе не доктор. .
Нет в MSBuild транзитивного управления зависимостями с поддержкой загрузки недостающих артефактов из репозиториев. Точнее, это можно всё руками сделать — как можно сделать всё и на чистом make.

Здравствуйте, VladD2, Вы писали:

C>>Scala замечательно интероперирует с Java. Вызовы Java из Скалы абсолютно прозрачны, с обратными вызовами тоже особых проблем нет.
VD>И как использовать case-классы из Явы?
В виде обычных классов. Естественно, лямбду с ними вручную делать будет очень неудобно.

VD>Совместимость есть только сверх вниз. Скала язык более мощный. И использовать его могут только не обделенные интеллектом люди. Так что конечно совместимость есть, но она только годится для экспорта больших кусков функциональности запихнутых в классы. Та же фигня в дотнет и Немерле.
Мне, лично, другого и не нужно.

C>>Можно сравнить ситуацию с C# и VB.NET. Java постепенно становится этаким VB.NET'ом, а Scala имеет все шансы стать аналогом C#.
VD>Боюсь VB.NET 9 порвет Яву по всем параметрам.
Ну да, VB.NET — это другая запись C#, по большей части.

C>>Тем более, что IntelliJ анонсировали поддержку Scala в следующей IDEA.
VD>Дай бог. Но боюсь, что они лоб разобьют о скалу.
Пока вроде бы успешно продвигаются — я примерно раз в неделю тестирую Scala-плугин. Уже работает автокомплит и отладка.

Здравствуйте, VladD2, Вы писали:

C>>В Java более красивые библиотеки. Сравни SWING и WinForms, например.
VD>Ага. Или SWING и WPF.
Ну нефиг бить маленький SWING.

VD>ЗЫ
VD>После такого откровенно фанатского заявления твои аргументы без смеха слушать невозможно. Увы.
Ну я же не сравнивал SWING и WPF. И вроде бы не отрицаю, что WPF лучше SWING'а.

Здравствуйте, Cyberax, Вы писали:

C>Точно! За каждую библиотеку нужно платить _минимум_ по $100!
Было бы здорово...

C>Нет в MSBuild транзитивного управления зависимостями с поддержкой загрузки недостающих артефактов из репозиториев.
Нет потребности нет и функционала — все просто. И уж точно не имеет никакого отношения к красоте архитектурных решений..

Здравствуйте, Cyberax, Вы писали:

C>Вот весь смысл в том, что для Java у меня всё нужное есть в OpenSource.
Да и для .Net все что нужно есть, только для этого с зависимостями разбираться не надо и тащить кучу хлама из внешних репозиториев..

C>Работоспособность приложения проверяется QA-шниками, конкретные версии зависимых библиотек тут не важны.
Меня терзают смутные сомненья.. ))

Здравствуйте, Cyberax, Вы писали:

VD>>И как использовать case-классы из Явы?
C>В виде обычных классов. Естественно, лямбду с ними вручную делать будет очень неудобно.

Данное утверждение показывает, то что ты просто плохо знаешь что такое Скала.
case-классы не имеют отношения к ламбдам. Это реализация алгеброический типов данных. Без паттерн-матчинга встроенного в язык их полноценно использовать невозможно.

VD>>Совместимость есть только сверх вниз. Скала язык более мощный. И использовать его могут только не обделенные интеллектом люди. Так что конечно совместимость есть, но она только годится для экспорта больших кусков функциональности запихнутых в классы. Та же фигня в дотнет и Немерле.
C>Мне, лично, другого и не нужно.

Блабам всегда не нужно того о чем они имеют смутное представление. Изучи обсуждаемую тобой технологию и тогда поговорим более серьзно.

C>>>Можно сравнить ситуацию с C# и VB.NET. Java постепенно становится этаким VB.NET'ом, а Scala имеет все шансы стать аналогом C#.
VD>>Боюсь VB.NET 9 порвет Яву по всем параметрам.
C>Ну да, VB.NET — это другая запись C#, по большей части.

Ага. И оба языка на сегодня рвут Яву как тузик грелку.
Так что если в Яву 7 добавят все что описанно в ссылке.

C>>>Тем более, что IntelliJ анонсировали поддержку Scala в следующей IDEA.
VD>>Дай бог. Но боюсь, что они лоб разобьют о скалу.
C>Пока вроде бы успешно продвигаются — я примерно раз в неделю тестирую Scala-плугин. Уже работает автокомплит и отладка.

Интересно было бы глянуть.
Под "работают" понимается "хоть как-то работают" или "работает как часы (не врет и не сбоит)"?

IB пишет:

> с зависимостями разбираться не надо и тащить кучу хлама из внешних
> репозиториев..
>
Прямо сказка...


--
ISO/IEC 8652:1995/Amd 1:2007

Здравствуйте, VladD2, Вы писали:

C>>В виде обычных классов. Естественно, лямбду с ними вручную делать будет очень неудобно.
VD>Данное утверждение показывает, то что ты просто плохо знаешь что такое Скала.
VD>case-классы не имеют отношения к ламбдам. Это реализация алгеброический типов данных. Без паттерн-матчинга встроенного в язык их полноценно использовать невозможно.
А ещё они могут использоваться для реализации лямбд. Про PM я даже вспоминать не стал — понятно, что в Java его нет.

А case-типы так вполне нормально использоваться могут, просто как обычные типы. Посмотри во что они компилируются.

1) Имеем:

abstract class Node
case class Leaf(name: String) extends Node
case class Middle(name: String, left: Node, right: Node) extends Node

2) В скомпилированом виде (часть кода вырезана):

public abstract class Node
    implements ScalaObject
{
    public Node()
    {
    }
    public int $tag()
    {
        return scala.ScalaObject.class.$tag(this);
    }
}

public class Leaf extends Node
    implements ScalaObject, Product, Serializable
{
    private final String name;

    public Leaf(String name)
    {
        this.name = name;
        super();
        scala.Product.class.$init$(this);
    }

    private final boolean gd1$1(String x$1)
    {
//...
    }

    public Object productElement(int x$1)
    {
        int i = x$1;
        if(i == 0)
        {
            return name();
        } else
        {
            throw new IndexOutOfBoundsException(BoxesRunTime.boxToInteger(x$1).toString());
        }
    }

    public int productArity()
    {
        return 1;
    }

    public String productPrefix()
    {
        return "Leaf";
    }

    public boolean equals(Object x$1)
    {
//...
    }

    public String toString()
    {
        return ScalaRunTime$.MODULE$._toString(this);
    }

    public int hashCode()
    {
        return ScalaRunTime$.MODULE$._hashCode(this);
    }

    public int $tag()
    {
        return 0x24137e;
    }

    public String name()
    {
        return name;
    }
}

public class Middle extends Node
    implements ScalaObject, Product, Serializable
{
    private final Node right;
    private final Node left;
    private final String name;

    public Middle(String name, Node left, Node right)
    {
        this.name = name;
        this.left = left;
        this.right = right;
        super();
        scala.Product.class.$init$(this);
    }

//...
    public Node right()
    {
        return right;
    }

    public Node left()
    {
        return left;
    }

    public String name()
    {
        return name;
    }

}

То есть, вполне обычные классы, которые можно вполне нормально использовать из Java. Где тут непеодолимые преграды?

C>>Ну да, VB.NET — это другая запись C#, по большей части.
VD>Ага. И оба языка на сегодня рвут Яву как тузик грелку.
VD>Так что если в Яву 7 добавят все что описанно в ссылке.
Java 7 — это Скала.

C>>Пока вроде бы успешно продвигаются — я примерно раз в неделю тестирую Scala-плугин. Уже работает автокомплит и отладка.
VD>Интересно было бы глянуть.
Могу запаковать IDEA с тестовым проектом и плугином.

VD>Под "работают" понимается "хоть как-то работают" или "работает как часы (не врет и не сбоит)"?
То что работает — оно стабильное, когда его разработчики в SVN не ломают . Работает тоже надёжно, так как использует инфраструктуру IDEA для поддержки языков.

Но многих фич пока просто нет.

Здравствуйте, Cyberax, Вы писали:

C>Управлять всем этим вручную? Ну нафиг.

А просто зависеть от всего этого?
Просто для OS такой подход органичен, для коммерческого проприетарного софта неудобен. Это не значит, что какой-то из подходов лучше или "для ламеров" или ещё что...

Здравствуйте, Cyberax, Вы писали:

C>Вот весь смысл в том, что для Java у меня всё нужное есть в OpenSource.
Весь смысл в том, что обычно когда разрабатывают коммерческий софт решение по использованию кажой библиотеки принимается осознанно. Как с точки зрения лицензирования, так и с точки зрения целесообразности использования.

C>Работоспособность приложения проверяется QA-шниками, конкретные версии зависимых библиотек тут не важны. Посмотреть что именно загрузилось, конечно, не мешает (хотя бы раз), но потом об этом особо можно не заботиться.
Ты что-нибудь про юнит-тесты, например, слышал, надеюсь? Как вы обеспечиваете покрытие тестами всего этого накаченного зоопарка?

C>А что не так с разделением зон ответственности?
Ну как что? Классический расклад: "А включаешь -- не работает". При этом не работает не совсем в твоём коде или совсем не в твоём. Кто и как ищет и фиксит багу, особенно если часть используемого кода проприетарная и в исходниках не доступна?
Опять же как осуществляется поддержка этой конструкции, особенно если у вас заявлены таймауты на реакцию?..

Здравствуйте, Cyberax, Вы писали:

C>Нет в MSBuild транзитивного управления зависимостями с поддержкой загрузки недостающих артефактов из репозиториев. Точнее, это можно всё руками сделать — как можно сделать всё и на чистом make.

Главное не забыть прикрутить прогресс-бар: "А теперь вы должны XXX килобаксов"
Кстати, темаинтересная. Надо такой тулл таки заботать, и паразитировать на финансовых потоках + продавать места в списках ссылок на репозитории...

Здравствуйте, Cyberax, Вы писали:

C>Appliance в 5Гб зато хорошо показывает подход MS.
Да это всего лишь показывает, что у клиентов, на которых это расчитано толстый канал, да и только...
Нам 5 Гб выкачать не особо трудно, например...

Здравствуйте, Erop, Вы писали:

C>>Управлять всем этим вручную? Ну нафиг.
E>А просто зависеть от всего этого?
Так оно от этого всего и зависит. Но позволяет нормально структурировать зависимости.

E>Просто для OS такой подход органичен, для коммерческого проприетарного софта неудобен. Это не значит, что какой-то из подходов лучше или "для ламеров" или ещё что...
Нормально удобен. Внутри организации у меня свой приватный репозиторий (с контролем доступа и т.п.), куда публикуются модули, которые точно так же прилинковываются к нужным проектам.

Здравствуйте, Erop, Вы писали:

C>>Нет в MSBuild транзитивного управления зависимостями с поддержкой загрузки недостающих артефактов из репозиториев. Точнее, это можно всё руками сделать — как можно сделать всё и на чистом make.
E>Главное не забыть прикрутить прогресс-бар: "А теперь вы должны XXX килобаксов"
Зачем? Сразу номер карточки в настройках тулзы указывать.

E>Кстати, темаинтересная. Надо такой тулл таки заботать, и паразитировать на финансовых потоках + продавать места в списках ссылок на репозитории...
Maven уже так умеет — просто отделяешь библиотеку и лицензионный ключ для неё.

Здравствуйте, Erop, Вы писали:

C>>Appliance в 5Гб зато хорошо показывает подход MS.
E>Да это всего лишь показывает, что у клиентов, на которых это расчитано толстый канал, да и только...
E>Нам 5 Гб выкачать не особо трудно, например...
Мне тоже. Но это показывает общее небрежное отношение к объёмам и ресурсам.

Здравствуйте, Erop, Вы писали:

C>>Вот весь смысл в том, что для Java у меня всё нужное есть в OpenSource.
E>Весь смысл в том, что обычно когда разрабатывают коммерческий софт решение по использованию кажой библиотеки принимается осознанно. Как с точки зрения лицензирования, так и с точки зрения целесообразности использования.
В Maven для этого специально есть http://maven.apache.org/plugins/maven-project-info-reports-plugin/license-mojo.html . Всё продумано!

C>>Работоспособность приложения проверяется QA-шниками, конкретные версии зависимых библиотек тут не важны. Посмотреть что именно загрузилось, конечно, не мешает (хотя бы раз), но потом об этом особо можно не заботиться.
E>Ты что-нибудь про юнит-тесты, например, слышал, надеюсь? Как вы обеспечиваете покрытие тестами всего этого накаченного зоопарка?
Зачем мне тестировать зарелизенные версии библиотек? Хотя, при желании, как раз, с Maven'ом это сделать совсем несложно.

Мой код прекрасно тестируется с помощью как раз этого Maven'а. Заодно Maven сам строит отчёты о тестировании: http://maven.apache.org/plugins/maven-surefire-report-plugin/ При желании туда ещё одним движением руки подключается code coverage.

C>>А что не так с разделением зон ответственности?
E>Ну как что? Классический расклад: "А включаешь -- не работает". При этом не работает не совсем в твоём коде или совсем не в твоём. Кто и как ищет и фиксит багу, особенно если часть используемого кода проприетарная и в исходниках не доступна?
Тут как раз оно очень удобно. Шаги такие:
1) Ищем предыдущую версию, которая работала.
2) Генерируем отчёт о зависимостях (как ни странно, с помощью одной команды Maven).
3) Смотрим что поменялось.
4) Смотрим кто поменял.
5) Бьём его по наглой рыжей морде.

Особенно удобно, когда разные модули проекта, которые пишут разные команды, тоже управляются Maven'ом.

E>Опять же как осуществляется поддержка этой конструкции, особенно если у вас заявлены таймауты на реакцию?..
А какие проблемы?

Здравствуйте, Cyberax, Вы писали:

C>Зачем мне тестировать зарелизенные версии библиотек? Хотя, при желании, как раз, с Maven'ом это сделать совсем несложно.
Круто!!! Ничего про баги в ПО не слышал?

E>>Ну как что? Классический расклад: "А включаешь -- не работает". При этом не работает не совсем в твоём коде или совсем не в твоём. Кто и как ищет и фиксит багу, особенно если часть используемого кода проприетарная и в исходниках не доступна?
C>Тут как раз оно очень удобно. Шаги такие:
C>1) Ищем предыдущую версию, которая работала.
C>Особенно удобно, когда разные модули проекта, которые пишут разные команды, тоже управляются Maven'ом.

А если такой версии не было никогда. Просто вновь обнаруженная бага. Или вопросы поддержки пользователей у вас вообще не рассматриваются?

E>>Опять же как осуществляется поддержка этой конструкции, особенно если у вас заявлены таймауты на реакцию?..
C>А какие проблемы?

Ну как это всё происходит организационно, интересно. Вот, скажем, надо вам реагировать в течении рабочего дня...
Бага, по твоему мнению находится в третьем поколении зависимостей. А фиксить надо либо там, либо во втром поколении зависимостей. И что делаем дальше?

Здравствуйте, Cyberax, Вы писали:

E>>А просто зависеть от всего этого?
C>Так оно от этого всего и зависит. Но позволяет нормально структурировать зависимости.
Так вот и не хочется зависить от ТАКОГО количества смежников...

E>>Просто для OS такой подход органичен, для коммерческого проприетарного софта неудобен. Это не значит, что какой-то из подходов лучше или "для ламеров" или ещё что...
C>Нормально удобен. Внутри организации у меня свой приватный репозиторий (с контролем доступа и т.п.), куда публикуются модули, которые точно так же прилинковываются к нужным проектам.
Так это у вас внутри конторы такие кустистые зависимости?

Здравствуйте, Cyberax, Вы писали:

E>>Нам 5 Гб выкачать не особо трудно, например...
C>Мне тоже. Но это показывает общее небрежное отношение к объёмам и ресурсам.

Зато инсталляция, скорее всего похожа на реальную, а не на минималлистическую. Почему тебе кажется, что время сотрудников менее ценно, чем трафик?..

Здравствуйте, Erop, Вы писали:

C>>Зачем мне тестировать зарелизенные версии библиотек? Хотя, при желании, как раз, с Maven'ом это сделать совсем несложно.
E>Круто!!! Ничего про баги в ПО не слышал?
А они находятся test-case'ами? Но Maven и в поиске багов помогает, IDEA сама мне скачает исходники используемых библиотек и подключит в проект. То есть, я прямо без всяких проблем могу отлаживать код библиотек.

C>>Особенно удобно, когда разные модули проекта, которые пишут разные команды, тоже управляются Maven'ом.
E>А если такой версии не было никогда. Просто вновь обнаруженная бага. Или вопросы поддержки пользователей у вас вообще не рассматриваются?
А если новая бага — то всё как обычно: дебаггер в руки, находим причину бага, фиксим. Если бага во внешней библиотеке — делаем workaround для неё, или создаём приватную версию с фиксом и кладём в свой репозиторий (параллельно пиная разработчиков библиотеки, чтобы включили фикс в следующий релиз).

C>>А какие проблемы?
E>Ну как это всё происходит организационно, интересно. Вот, скажем, надо вам реагировать в течении рабочего дня...
У меня обычно время реакции ещё меньше — считанные часы для критичных фиксов...

E>Бага, по твоему мнению находится в третьем поколении зависимостей. А фиксить надо либо там, либо во втром поколении зависимостей. И что делаем дальше?
Фиксим зависимость и делаем для неё override. Примерно так:

            <dependency>
                <groupId>jasperreports</groupId>
                <artifactId>jasperreports</artifactId>
                <version>2.0.2</version>
                <!-- XML APIs are broken because of conflict with root classloader -->
                <exclusions>
                    <exclusion>
                        <groupId>xml-apis</groupId>
                        <artifactId>xml-apis</artifactId>
                    </exclusion>
                </exclusions>
            </dependency>
            <!-- Manually override XML APIs version -->
            <dependency>
                <groupId>xml-apis</groupId>
                <artifactId>xml-apis</artifactId>
                <version>1.3.02</version>
            </dependency>

На практике, багов с зависимостями в рантайме у меня пока (к счастью) не было.

Здравствуйте, Erop, Вы писали:

C>>Так оно от этого всего и зависит. Но позволяет нормально структурировать зависимости.
E>Так вот и не хочется зависить от ТАКОГО количества смежников...
Ну так а что делать, если эти зависимости реально нужны? Основной другой вариант — свалить всё в кучу и молиться, чтоб работало.

C>>Нормально удобен. Внутри организации у меня свой приватный репозиторий (с контролем доступа и т.п.), куда публикуются модули, которые точно так же прилинковываются к нужным проектам.
E>Так это у вас внутри конторы такие кустистые зависимости?
У нас пока ещё не очень. В приватном репозитории лежат, в основном, только несколько чисто утиллитных проектов. Но к этому движется, да.

Здравствуйте, Erop, Вы писали:

C>>Мне тоже. Но это показывает общее небрежное отношение к объёмам и ресурсам.
E>Зато инсталляция, скорее всего похожа на реальную, а не на минималлистическую. Почему тебе кажется, что время сотрудников менее ценно, чем трафик?..
У меня тоже вполне реальная инсталляция. Если настроить компоненты — то можно сразу работать с ней. По возможностям, кстати, функционала будет не меньше, чем в TFS.

Здравствуйте, Cyberax, Вы писали:

E>>Бага, по твоему мнению находится в третьем поколении зависимостей. А фиксить надо либо там, либо во втром поколении зависимостей. И что делаем дальше?

C>Фиксим зависимость и делаем для неё override. Примерно так:

dependencyManagement в таком случае разве не поможет? Должен перекрыть версию.

Здравствуйте, WFrag, Вы писали:

C>>Фиксим зависимость и делаем для неё override. Примерно так:
WF>dependencyManagement в таком случае разве не поможет? Должен перекрыть версию.
Проще явно сделать руками, более красиво выглядит.

Здравствуйте, Cyberax, Вы писали:

C>IDEA сама мне скачает исходники используемых библиотек и подключит в проект. То есть, я прямо без всяких проблем могу отлаживать код библиотек.
C>А если новая бага — то всё как обычно: дебаггер в руки, находим причину бага, фиксим. Если бага во внешней библиотеке — делаем workaround для неё, или создаём приватную версию с фиксом и кладём в свой репозиторий (параллельно пиная разработчиков библиотеки, чтобы включили фикс в следующий релиз).
E>>Бага, по твоему мнению находится в третьем поколении зависимостей. А фиксить надо либо там, либо во втром поколении зависимостей. И что делаем дальше?
C>Фиксим зависимость и делаем для неё override. Примерно так:

А если всё-таки вернуться к ситуации, когда библиотеки проприетарные и код их не доступен, а редестрибуция своих версий невозможна?
Ты же в этих условиях все эти фичи заюзать советуешь, или ты всё только о мире OS говоришь?
Правда править чужую непростую либу я и сам не хотел бы, безотносительно к лицензиям. Вот, скажем, есть такая распознавалка "клинопись", у неё есть тулкит. Работает нестабильно. Отлаживать я бы не взялся, даже при доступных исходниках...

C>На практике, багов с зависимостями в рантайме у меня пока (к счастью) не было.
Ну и хорошо. Хотя это для меня странно. А у тебя какой цикл разработки (сколько времени между версиями проходит). У наукоёмкого софта это годы...

Здравствуйте, Cyberax, Вы писали:

C>Ну так а что делать, если эти зависимости реально нужны? Основной другой вариант — свалить всё в кучу и молиться, чтоб работало.
Что значит "реально нужны"? Обычно смежники дороже разработчиков обходятся...

E>>Так это у вас внутри конторы такие кустистые зависимости?
C>У нас пока ещё не очень. В приватном репозитории лежат, в основном, только несколько чисто утиллитных проектов. Но к этому движется, да.
Ну когда стаент всё так "хорошо" поделишься опытом управления этим зоопарком и механизмами разрешения конфликтов интересов...

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Cyberax, Вы писали:

C>>Ну так а что делать, если эти зависимости реально нужны? Основной другой вариант — свалить всё в кучу и молиться, чтоб работало.
E>Что значит "реально нужны"? Обычно смежники дороже разработчиков обходятся...

Наши Java приложения процентов на 90%, наверное, из OS библиотек и фреймворков обычно состоят. При этом эти OS библиотеки и фреймворки, как правило, по качеству гораздо лучше того, что делаем мы сами. Просто потому что их использует масса народу, включая монстров типа IBM. Либо они написаны грамотными разработчиками (тот же GWT).

Здравствуйте, WFrag, Вы писали:

WF> При этом эти OS библиотеки и фреймворки, как правило, по качеству гораздо лучше того, что делаем мы сами.
Меня терзают смутные сомненья. Сколько OS фреймворков не видел, в большинстве случаев качество ниже плинтуса и никто ни за что не отвечает.

WF> Просто потому что их использует масса народу, включая монстров типа IBM.
Обожемой, это первый признак того, что ни в коем случае использовать это нельзя..

WF>Либо они написаны грамотными разработчиками (тот же GWT).
А вы не грамотные что ли? =)

Здравствуйте, WFrag, Вы писали:

WF>Наши Java приложения процентов на 90%, наверное, из OS библиотек и фреймворков обычно состоят. При этом эти OS библиотеки и фреймворки, как правило, по качеству гораздо лучше того, что делаем мы сами. Просто потому что их использует масса народу, включая монстров типа IBM. Либо они написаны грамотными разработчиками (тот же GWT).

Прикольно, как это взаимосоотносится с тезисом Цайберакса о том, что Ява для людей пишуших мегастройный код, а C# для кодеров начального уровня...
Хотя мне вот тоже кажется, что вся методология работы с Мавином построена на том, что библиотеки намного лучше реализованы, чем прикладной код...

Здравствуйте, Erop, Вы писали:

E>Прикольно, как это взаимосоотносится с тезисом Цайберакса о том, что Ява для людей пишуших мегастройный код, а C# для кодеров начального уровня...
E>Хотя мне вот тоже кажется, что вся методология работы с Мавином построена на том, что библиотеки намного лучше реализованы, чем прикладной код...

Да, ключевой момент успеха Maven2 в Java среде (на мой взгляд) — наличие большого числа качественных и средне-качественных OS библиотек практически на все случаи жизни.

Здравствуйте, IB, Вы писали:

WF>> При этом эти OS библиотеки и фреймворки, как правило, по качеству гораздо лучше того, что делаем мы сами.

IB>Меня терзают смутные сомненья. Сколько OS фреймворков не видел, в большинстве случаев качество ниже плинтуса и никто ни за что не отвечает.

В .NET-среде или в Java? Я только за Java ручаться могу. И то за небольшую часть, ту, с которой я работал. С .NET фактически не работал, потому и сравнить не могу.

WF>>Либо они написаны грамотными разработчиками (тот же GWT).

IB>А вы не грамотные что ли? =)

Не особо.

Здравствуйте, IB, Вы писали:

WF>> При этом эти OS библиотеки и фреймворки, как правило, по качеству гораздо лучше того, что делаем мы сами.
IB>Меня терзают смутные сомненья. Сколько OS фреймворков не видел, в большинстве случаев качество ниже плинтуса и никто ни за что не отвечает.

я так понимаю смотрели нетовские ос фреймворки? это ли не еше одно подтверждение словам Cyberax-а, что "в Java предпочитают более красивые и стройные решения, а в .NET — по большей части то, что легко использовать 90% новичков"?

Здравствуйте, goorov, Вы писали:

G>я так понимаю смотрели нетовские ос фреймворки?
Не правильно понимаешь, именно явовские и их тупые порты на .Net =)

G>это ли не еше одно подтверждение словам Cyberax-а,
Это еще одно подверждение того, что вся явовская "красивость" на поверку оказывается редкостной кривизны конструкцией..

Здравствуйте, IB, Вы писали:

G>>я так понимаю смотрели нетовские ос фреймворки?
IB>Не правильно понимаешь, именно явовские и их тупые порты на .Net =)

G>>это ли не еше одно подтверждение словам Cyberax-а,
IB>Это еще одно подверждение того, что вся явовская "красивость" на поверку оказывается редкостной кривизны конструкцией..

короче, имена в студию — какие конкретно библиотеки и фреймворки, что не устраивает и т.д., а то все твои посты до текущего момента мягко говоря выглядят неадекватно

Здравствуйте, goorov, Вы писали:

G> а то все твои посты до текущего момента мягко говоря выглядят неадекватно
Вот именно, начиная с поста про красивость архитектуры явовских компонент и некрасивость .net-овских.

Здравствуйте, Cyberax, Вы писали:

C>А case-типы так вполне нормально использоваться могут, просто как обычные типы. Посмотри во что они компилируются.

C>1) Имеем:
C>

C>abstract class Node
C>case class Leaf(name: String) extends Node
C>case class Middle(name: String, left: Node, right: Node) extends Node
C>

C>2) В скомпилированом виде (часть кода вырезана):
C>

<Skipped>
C>

C>То есть, вполне обычные классы, которые можно вполне нормально использовать из Java. Где тут непеодолимые преграды?

Это понятно, в АТД Немерле кажется тоже примерно в такое компилируется. Но дело то вот в чем, АТД без паттерн-матчинга по сути бесполезны. Мне например в голову use cases АТД приходят только в сочетании с паттерн-матчингом, а без оного, я себе плохо представляю, какие можно получить выигрышы от использования АТД.

Здравствуйте, yumi, Вы писали:

Y>Это понятно, в АТД Немерле кажется тоже примерно в такое компилируется. Но дело то вот в чем, АТД без паттерн-матчинга по сути бесполезны. Мне например в голову use cases АТД приходят только в сочетании с паттерн-матчингом, а без оного, я себе плохо представляю, какие можно получить выигрышы от использования АТД.
Оно нужно для ситуации, когда надо создать параметры и вызвать какую-то Скалистую функцию с ними. Или что-то сделать из Java-кода с возвращённым результатом.

А больше ничего особого от них и не нужно. Разве что, ещё бы пригодилась возможность создавать свои case-классы на Java...

Здравствуйте, Erop, Вы писали:

C>>Фиксим зависимость и делаем для неё override. Примерно так:
E>А если всё-таки вернуться к ситуации, когда библиотеки проприетарные и код их не доступен, а редестрибуция своих версий невозможна?
Надо добавить: сидим в танке, Инета нет, компьютеров тоже.

E>Ты же в этих условиях все эти фичи заюзать советуешь, или ты всё только о мире OS говоришь?
А почему нет? Тут Maven, правда, поможет только тем, что структурирует свалку зависимостей.

Ну и опять же — в мире Java большая часть нормальных вещей как раз открытая.

E>Правда править чужую непростую либу я и сам не хотел бы, безотносительно к лицензиям. Вот, скажем, есть такая распознавалка "клинопись", у неё есть тулкит. Работает нестабильно. Отлаживать я бы не взялся, даже при доступных исходниках...
Это уже другой вопрос.

C>>На практике, багов с зависимостями в рантайме у меня пока (к счастью) не было.
E>Ну и хорошо. Хотя это для меня странно. А у тебя какой цикл разработки (сколько времени между версиями проходит). У наукоёмкого софта это годы...
У меня это дни. У нас сервис, в который мы непрерывно добавляем улучшения по просьбам клиентов. С наукоёмким софтом тоже разницы особой нет.