Оригинал можно посмотреть на
http://telamon.ru/articles/csharpfromjava.html
=========================================================
Есть два подхода к сравнению языков программирования: религиозная война и «a нам всё равно». Я постараюсь втиснутся между ними и начну с общего. Ключевой особенностью и Java, и C# является автоматическое управление памятью. Конечно, оба языка из-за этого совершенно не подходят для написания ядра операционной системы, но зато существенно упрощают разработку прикладных программ, потому что:


остаётся меньше возможностей для memory leak;
не надо писать код для освобождения памяти;
можно написать f(g(x)) и не думать об освобождении памяти от результата g(x).

Итак, мы имеем две массовых платформы для разработки программного обеспечения, на каждой из которых работают миллионы программистов; за каждой стоят мировые софтверные гиганты, но ни одна не имеет революционных преимуществ.

Влияние Microsoft
Исторически Java появилась раньше .NET и потихоньку захватывала рынок не только серверного ПО, но и GUI-приложений для корпоративных клиентов, потому что C++ сложноват для рисования формочек, Visual Basic не похож на язык для крутых девелоперов, а Borland инвестировал в Java больше, чем в Delphi.

Но чем больше приложений на Java, тем меньше потребность в Windows, поэтому Microsoft решил не поддерживать Java, а создать .NET, чтобы стимулировать разработку программ для Windows. Кончено, какая-то кроссплатформенность у .NET есть, но, с точки зрения Windows, .NET стремится стать частью операционной системы, как Internet Explorer. Карьера .NET-разработчика предполагает тесные партнёрские отношения с Microsoft, включая использование среды разработки Visual Studio, базы данных MS SQL и системы контроля версий Visual SourceSafe.

Нужно отдать должное маркетингу Microsoft, многие компании предпочитают думать о программном обеспечении не выходя за рамки видения Microsoft. Иногда из-за этого приходится откладывать в сторону любимую Java и брать в руки C#. Хорошая новость в том, что накопленный в Java опыт помогает и в .NET, а развитие .NET стимулирует прогресс Java.

CVS vs. VSS
Большинство Java-разработчиков привыкли к CVS, после этого переход на Visual SourceSafe в сочетании с реализацией интеграции с ним в Visual Studio и концепцией solutions-projects воспринимается весьма болезненно. Справедливости ради стоит отметить, что переход на CVS в большом проекте теоретически возможен, но вызовет крайне негативную реакцию людей, привыкших к VSS.

В этом месте можно было бы немного помахать кулаками на тему «почему CVS лучше VSS», но я этого делать не буду, потому что CVS тоже не идеален, и есть такой проект как Subversion, который открыто позиционируется в качестве замены CVS. Microsoft тоже не считает VSS своим флагманским продуктом и готовит ему замену в виде Visual Studio 2005 Team System.

Влияние VB.NET
Программы на многих языках могут быть скомпилированы в байт-код для JVM, но практически абсолютно всё программное обеспечение для платформы Java написано именно на Java. Для .NET примерно с равной вероятностью проект может разрабатываться как на C#, так и на VB.NET, причём очень часто используются сразу оба языка.

Понятно, что C# и VB.NET практически не имеют между собой отличий, кроме синтаксиса, но вносят раздробленность в сообщество разработчиков. Даже если использовать только на C#, то в результатах поиска по документации всегда будут путаться материалы, относящиеся к VB.NET. В десктоп-версии MSDN можно настроить фильтр по языку программирования, но всё равно, на мой вкус, документация по Java значительно удобней и понятней.

Разработка GUI
Разработка GUI на C# являет типичным примером RAD, как Delphi. На Java GUI, как правило, делается при помощи Swing. Хотя Swing весьма объёмен и сложен, хорошая продуманность и расширяемость архитектуры в сочетании с доступными исходными кодами позволяет разрабатывать GUI любой сложности.

Разработка веб-приложений
Я съел собаку на разработке веб-приложений на Java, но никогда не использовал ASP.NET; тем не менее, я вполне допускаю, что ASP.NET имеет определённые и весьма существенные преимущества при создании небольших сайтов. Однако, эти преимущества выделяют веб-приложения в отдельный сегмент, очень многие .NET-разработчики специализируются либо только на GUI, либо только на веб. На Java веб-приложения можно создавать без использования каких-либо специфических технологий вроде JSP, JSTL или Struts: extends HttpServlet — и вперёд!

Конечно, рынок разработки сайтов Java без боя не отдаст, можно ожидать новостей от JavaServer Faces или от Fabrique. В любом случае, делать веб-странички — это не самый сложный класс задач для современных языков программирования.

Is everything object?
В Java очень популярен лозунг "Everything is object", в C# это не так. Первое, что бросается в глаза — наличие структур в C#. Очевидно, что есть мотивы использовать структуры для повышения производительности, но мне кажется, что современные компьютеры достаточно производительны, чтобы не добавлять ещё одну сущность в язык.

Также, вместо анонимных классов в C# используются делегаты, это такая идея о том, что если у метода есть определённый набор аргументов и заданный тип возвращаемого значения, то совершенно не важно, как он называется, является ли он статическим и прочие глупости — можно его дёргать.

Если уж зашла речь о delegate, то нужно упомянуть и об event — они действительно сокращают размер кода при разработке GUI, хотя и ценой отступления от идей ООП.

В определённой степени C# менее лаконичен, не вдаваясь в подробности, ограничусь упоминанием ключевых слов virtual, override, ref, out и param, не имеющих аналогов в Java.

Влияние платформы на самосознание программистов
Безусловно, больше всего на качество программного обеспечения влияет качество самих разработчиков, а не язык программирования. Тем не менее, мой опыт говорит о том, что в подавляющем большинстве проектов на Java для build management используется Ant, а в .NET очень часто билды делаются встроенными средствами Visual Studio, хотя аналогичные инструменты существуют и для .NET. Кроме этого, в C# нет чётких правил наименования классов и их размещения на диске, что часто вносит дополнительную путаницу (конечно, квалифицированные программисты успешно борются с этой проблемой).

В С# нет checked exceptions, есть даже объяснение почему. Такое решение имеет свои резоны, но если компилятор не контролирует обработку checked exception, то нужно больше рассказывать об обработке ошибок через другие коммуникационные каналы, иначе появятся программисты, которые вообще не будут знать, что такое exception.

Тигры рвутся вперёд
Есть области, в которых Java доминирует безусловно, например, игры для мобильных телефонов или технология JavaCard. Однако, борьба между C# и Java за долю на рынке будет идти ещё долго, обе платформы будут совершенствоваться, например, в Java 5 и .NET 2.0 появится поддержка generics.

Очевидно, что успех каждого конкретного проекта зависит не от языка программирования, а от понимания задачи, умения давать методам понятные названия, способности избегать дублирования кода и других общечеловеческих ценностей.

Благодарности
Огромное спасибо Дмитрию Жемерову, благодаря которому вам не пришлось читать всю ту ерунду, которую я написал сначала, компании DataArt, которая дала мне возможность заниматься изучением C# в рабочее время, коллегам из компании DataArt, которые оказывали мне интеллектуальную и моральную поддержку, а также компании JetBrains, которая очень вовремя начала делать ReSharper, который позволяет получать на C# многие виды удовольствия, привычные пользователям IntelliJ IDEA. Особая благодарность Алексею Пчелинцеву за заботу о букве Ё.

Ссылки
1. The C# Programming Language for Java Developers
http://msdn.microsoft.com/vstudio/java/get.../csharpforjava/

2. J2EE fundamentals for .NET developers
http://www-106.ibm.com/developerworks/java...ary/j-roadmap1/

Хорошая статья.

Код

Однако, борьба между C# и Java за долю на рынке будет идти ещё долго, обе платформы будут совершенствоваться, например, в Java 5 и .NET 2.0 появится поддержка generics.

Можно Тигра не ждать, а обoйтись старым добым Мерлином
Generics можно взять здесь:

http://java.sun.com/developer/earlyAccess/adding_generics/

и использовать с Java 1.4 - сгенеpированыый байткод будет полностью совместим с JVM.

Это сообщение отредактировал(а) Domestic Cat - 13.8.2004, 17:34

Цитата

Я съел собаку на разработке веб-приложений на Java, но никогда не использовал ASP.NET; тем не менее, я вполне допускаю, что ASP.NET имеет определённые и весьма существенные преимущества при создании НЕБОЛЬШИХ сайтов.

Да ну лаадно!
Про Pet Shop слышали? Кто там победил?...
(Про Pet Shop читал отсюда: http://www.middlewareresearch.com/
конкретный линк на отчет потерял, если кому нужен он (pdf) - могу прислать на мыло или выложить на ftp, если он у вас есть)

Код

Про Pet Shop слышали? Кто там победил?...

Ну вот, старая тема
1. Было 2 пет шопа. В пет шопе номер 1 Java побили в пух и прах - и производительность ниже, и писать больше, прямо отсой . Позднее выяснилось, что:

а. Бенчмаркинг спонсировался ... кем, как ты думаешь?
б. Middleware "забыла" пригласить специалистов по J2EE, но зато специалисты из M$ принимали самое живое участие.

Ай-ай-ай. M$ лоханулся, и Middleware решилась на "Reload".
Заметь, на gotDotNet лежит СТАРЫЙ документ (2002)! А найти доклад от 2003 года...

2. Смотрим официальный документ, опубликованный Миддлеваре ("Middleware30.pdf").

Цитата

J2EE and .NET (RELOADED)  Yet Another Performance Case Study    Based on  The Middleware Company Application Server Baseline Specification  http://www.middleware-company.com/casestudy/    The Middleware Company Case Study Team  June 2003

Читаем выводы (сорри, без перевода, но очень уж обломно)

Цитата

•A Web Application Test. This tested performance when hosting a typical, web application with  steadily increasing user loads.  This test used two different databases, Oracle 9i and Microsoft  SQL Server 2000.  The test results showed that both .NET and the fastest J2EE platform performed approximately  the same.  The J2EE solution was slightly better than the .NET solution (about 2%) when using  Oracle 9i.  When using Microsoft SQL Server, the .NET solution was slightly better than J2EE  (about 11%).  In general the J2EE implementations performed equally well against both  databases.  The .NET implementation performed almost the same as J2EE when using Oracle 9i  and slightly better when using Microsoft SQL Server.  •  24 Hour Reliability Test.  This tested the sustainable performance and reliability of platforms  over a 24-hour period as it runs a transaction-heavy test script against the web application under  a constant, peak-throughout, user load.  For this test the database used for each codebase was the  one it appeared to perform most reliably and conveniently with,  For both the J2EE codebases  the 24-Hour Reliability Test was run with Oracle 9i. For the .NET codebase the 24-Hour  Reliability Test was run with Microsoft SQL Server.  The results of this test were that the fastest J2EE and the .NET platform  performed almost  identically, with less than 2% difference in performance.  •  Web Services Test.  This tested the performance of the application server as it hosts a basic web  service via SOAP 1.1.  The results of this test showed that the .NET platform outperformed the fastest J2EE platform,  by over 200%.

Победа бо Web(XML)-сервису? Реально в 99% случаев это роли никакой не играет; кроме того, с тех пор прошло некоторое время...
"Победы" здесь ничьей нет. В чем-то Java обогнала NET, в чем-то проиграла.
Ну и? Заметь, Middleware не называет это даже бенчмаркингом, а "case study". Есть разница?

Можно сколько угодно делать пдпбных сравнений, но бенчмаркинг свидетельствует
чаще всего о том, что в ДАННОЙ ситуации кто-то был быстрее, а кто-то хуже.
Как насчет других параметров?

Ну пишут про 101 преимущество Java

http://www.freeroller.net/page/ceperez/200...name=101%20List

а gotDotNet помещает избранные гистограммы из этого самого доклада и делает вид
что это непреложная истина. (А вот эти самые выводы они помещали на сайте? Нет.)

Что поменялось?

Это сообщение отредактировал(а) Domestic Cat - 13.8.2004, 18:36

Эх.. Что-то мне не хочется в сотый раз начинать одни и те же споры. Надоело както и заранее известен конец - все останутся при своем мнении..
Вобщем, резюме: каждый использует то, что ему нравится.
Вот тока я не пойму одного. Получается, что только M$ на всех давит и доказывает свою правоту, а остальные?
Ну не верю я, что Sun (как любая другая фирма) не занимается подобными вещами, ну может, не в таких масштабах. Им же тоже деньги нужны.

Цитата

Вобщем, резюме: каждый использует то, что ему нравится.

Eсли бы J2EE была действительно такой плохой, все бы перешли на NET, тем более что это дитя M$.
Дело здесь не в любви к чему-то, а в том, насколько платформа себя оправдывает.

Цитата

Hу не верю я, что Sun (как любая другая фирма) не занимается подобными вещами, ну может, не в таких масштабах. Им же тоже деньги нужны.

Любая компания гребет под себя, разница только в способах. У M$ способы простые
и подсудные, вот и все. Можешь найти уйму дел против M$.

Я это не к тому, чтобы обидеть или что NET хуже Java. Я говорю о политике M$ как компании, о том что ее методы реально подсудны, и что позволь M$ съесть Sun, HP, IBM ..., ничего хорошего не выйдет.
То есть, я ругаю M$, а не NET. То, что вообще подобный "конкурс" NET-J2EE появился есть дело рук M$ и его стремление сожрать Sun и подмять под себя рынок web-приложений. Те кто писал NET, прекрасные программеры.
Не сомневаюсь в том, что NET это круто. Лично мне не нравится то что он стал
очередным орудием M$ в борьбе за монополию.

предыдущий пост озвучил и мое ИМХО по данному вопросу, ну а чтобы окончательно развеять всякие надежды на поиск истины :

http://java.sun.com/performance/reference/...WS_Test-1_0.pdf

- это вроде не упоминалось здесь. А вообще к вопросу о том что лучше, что хуже - это ведь очень субъективные категории. Более того, понятное дело, даже процент на рынке не показатель - коммерческий успех складывается из кучи факторов, среди которых продуманность и красота далеко не на первом месте.

Цитата

http://java.sun.com/performance/reference/...WS_Test-1_0.pdf

Спасибо, я об этой ссылке не знал.

Кстати, по данным Middleware (2003) Web Services throughput был такой :

J2EE~ 400 req/sec
NET ~ 800 req/sec

Здесь же (2004):

J2EE ~ 1700 req/sec
NET ~ 600 req/sec

что еще раз подтверждает что такие исследования можно проводить бесконечно.

Это сообщение отредактировал(а) Domestic Cat - 13.8.2004, 21:53

Господа, ну что вы в самом деле переругались из-за перформанса, при нынешней технике для корпоративных приложений это практически не важно, к тому же узким местом как правило является база данных.

Собственно, никто и не ругается.
Просто не хочется опять одно и то же повторять, хотя очень уж руки чешутся поспорить.

Цитата

Первое, что бросается в глаза — наличие структур в C#. Очевидно, что есть мотивы использовать структуры для повышения производительности, но мне кажется, что современные компьютеры достаточно производительны, чтобы не добавлять ещё одну сущность в язык.

Не понимаю смысла проблемы. Не хочешь - не используй.
Это всего лшь ВОЗМОЖНОСТЬ. Лично мне, например, не нравится ради двух полей (допустим, "id" и "класс") создавать класс.
Тем более все-таки скорость..
Блин, не люблю когда говорят "современные компьютеры достаточно производительны.." - из-за этого сейчас народ пишет не обращая внимане на ресурсы, железо все быстрее и быстрее, а вот софт все там же. Многие пишут по типу "и так сойдет. Комп все съест.". Итог - сплошные тормоза.
Четно говоря, меня удивляет предложение, к-е можно перефразировать так:
"нафиг нужны элементы языка для ускорения производительности?"..

IMHO если в классе есть только поля с тривиальными геттерами и сеттерами, то оптимизировать его должен компилятор. А если сначала завели struct с двумя полями, потом полей стало десять, а потом оказалось, что нужно всё-таки было делать класс, то рефакторинг будет не пропорционально велик. А тормозят современные программы как правило из-за нехватки мозгов у разработчиков - то алгоритм вставят крайне неэффективный, то с многопоточностью не разберутся, такое ни компилятором, ни железом не исправишь.

Объясните ламеру - что, структура в C# дейстительно быстрее класса?
Насколько я помню C++, там

Код

struct my_struct {     int x;     double y; };

есть абсолютно то же самое, что и

Код

class my_class {     public:          int x;          double y; };

Лишняя сущность в языке... Хоть это и возможность, но все же наверняка
у кого-нибудь возникнет желание "выиграть" в скорости, объявляя вместо классов
стуктуры. Ну и отсюда рефакторинг, и пр. и пр.

Это сообщение отредактировал(а) Domestic Cat - 18.8.2004, 16:25

Цитата(Domestic @ 18.8.2004, 17:24)

структура в C# дейстительно быстрее класса

Структура занимает меньше места, т.к. фактически когда объявляется переменная такого типа, ее не надо создавать через new и она не является ссылкой. Т.е. не надо тратить память на ссылку и не надо тратить время на создание. В принципе идея неплохая.

Хорошо использовать для таких объектов как Point или что-то подобное.

Цитата(AntonSaburov @ 18.8.2004, 07:39)

Структура занимает меньше места, т.к. фактически когда объявляется переменная такого типа, ее не надо создавать через new и она не является ссылкой. Т.е. не надо тратить память на ссылку и не надо тратить время на создание.

Еще непонятнее. Тогда она ведь на стэке создается? Или как поле в классе - но тогда она
все равно на хипе занимает место. Все равно - память.
Если переменная тuпа my_struct - не ссылка, то если я правильно понимаю, она передается по значению:

Код

void func1() {    my_struct ms;    ms.member1 = 10000;    ms.member2 = 10002;    ....    ms.member10000 = 90000;          other_func(ms); } void other_func(my_struct ms) {     some_other_func(ms); } ...

- так что структура копируется 2 раза; очень неэффективный способ.

В любом случае, пусть есть структура Point:

Код

struct Point {     double x, y; };

Мне понадобилось посчитать рассtояние между Point'ами:

Код

double distance(Point* p2, Point* p1) {    return sqrt( pow((p2->x - p1->x), 2) + pow((p2->y - p1->y), 2) ); }

В результате все равно придем к классу Point. Имхо, подобные вещи засоряют язык, а польза от них нивелируется их недостатками.

Это сообщение отредактировал(а) Domestic Cat - 18.8.2004, 17:46

имхо тут дело такое : структура пришла вообще из С и примечательна тем, что "жестко привязана" к памяти, т. е. на структуру выделяется ровно столько памяти, сколько в сумме занимают её поля - таким образом это просто очень удобная оболочка для байтов (можно ворочать и запихивать/вынимать из памяти сразу большой и структурированный кусок). Таким образом это вещь для низкоуровнего программирования - в последнем примере конечно сподручнее использовать класс, но если таких вызовов будет много, то замена на структуры однозначно даст ускорение - это и будет шаг к оптимизации (в перспективе - переписывание функции на асме =)) )

Цитата(redrick @ 18.8.2004, 08:46)

структура пришла вообще из С и примечательна тем, что "жестко привязана" к памяти, т. е. на структуру выделяется ровно столько памяти, сколько в сумме занимают её поля

Не совсем так. Структура может занимать больше памяти, чем сумма размеров полей
- компилятор может посчитать нужным выделить больше памяти (для оптимизации).

Цитата(redrick @ 18.8.2004, 08:46)

но если таких вызовов будет много, то замена на структуры однозначно даст ускорение - это и будет шаг к оптимизации

Ну вот и я о том же. Оптимизировав таким образом код, можно получить
абсолютно нечитабельный не-ОО кошмар.

Для оптимального доступа в Java есть классы CharBuffer, DoubleBuffer,..., реализованные как нативные буфера. B основном быстрый доступ нужен к такого тuпа структурам.

Это сообщение отредактировал(а) Domestic Cat - 18.8.2004, 17:59

Цитата(Domestic @ 18.8.2004, 17:58)

Ну вот и я о том же. Оптимизировав таким образом код, можно получить абсолютно нечитабельный не-ОО кошмар.

не-ОО вовсе не значит кошмар и нечитабельный =) - читают люди, которые, как известно, очень разные бывают =)

насчет Java - не спорю, та и есть, просто С и asm призваны для написания низукоуровневых вещей, очень нативных, поэтому говорить об их качествах и недостатках нужно именно на этом поле. Никто не собирается возводит корпоротивные системы (или что там ещё жутко ОО) на С и asm. Даже вебовские штуки очень редко на С пишут (я только один пример знаю =) ). Поэтому тут вроде довольно беспредметное обсуждение получилось (из-за не точно заданных краевых условий =)) )

Цитата(redrick @ 19.8.2004, 07:09)

насчет Java - не спорю, та и есть, просто С и asm призваны для написания низукоуровневых вещей, очень нативных, поэтому говорить об их качествах и недостатках нужно именно на этом поле. Никто не собирается возводит корпоротивные системы (или что там ещё жутко ОО) на С и asm. Даже вебовские штуки очень редко на С пишут (я только один пример знаю =) ). Поэтому тут вроде довольно беспредметное обсуждение получилось (из-за не точно заданных краевых условий =)) )

Не спорю, но ведь речь о структурах в C#, а его низкоуровневым трудно назвать

М	Джентльмены, спор пока в рамках, но уже на грани выхода на флуд. Повнимательнее, пожалуйста.

про C# молчу - я его использую по стольку по скольку (только когда нужно использовать что то написанное другими на нем). Вообще по синтаксису нельзя не заметить сходства с Java =) . Может конечно это и случайно, но я всё таки не тороплюсь втягиваться во всякие МС-овские нововведения, особенно после того как прочитал вот это

http://forum.vingrad.ru/index.php?showtopi...d=&#entry202619