| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > C# глазами Java |
| Автор: ysirotkin 13.8.2004, 16:34 |
| Оригинал можно посмотреть на 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 тоже не идеален, и есть такой проект как http://subversion.tigris.org/, который открыто позиционируется в качестве замены CVS. Microsoft тоже не считает VSS своим флагманским продуктом и готовит ему замену в виде http://msdn.microsoft.com/vstudio/teamsystem/default.aspx. Влияние VB.NET Программы на многих языках могут быть скомпилированы в байт-код для JVM, но практически абсолютно всё программное обеспечение для платформы Java написано именно на Java. Для .NET примерно с равной вероятностью проект может разрабатываться как на C#, так и на VB.NET, причём очень часто используются сразу оба языка. Понятно, что C# и VB.NET практически не имеют между собой отличий, кроме синтаксиса, но вносят раздробленность в сообщество разработчиков. Даже если использовать только на C#, то в результатах поиска по http://msdn.microsoft.com/всегда будут путаться материалы, относящиеся к 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 без боя не отдаст, можно ожидать новостей от http://java.sun.com/j2ee/javaserverfaces/ или от http://www.jetbrains.com/fabrique/index.html. В любом случае, делать веб-странички — это не самый сложный класс задач для современных языков программирования. Is everything object? В Java очень популярен лозунг "Everything is object", в C# это не так. Первое, что бросается в глаза — наличие структур в C#. Очевидно, что есть мотивы использовать структуры для повышения производительности, но мне кажется, что современные компьютеры достаточно производительны, чтобы не добавлять ещё одну сущность в язык. Также, вместо анонимных классов в C# используются делегаты, это такая идея о том, что если у метода есть определённый набор аргументов и заданный тип возвращаемого значения, то совершенно не важно, как он называется, является ли он статическим и прочие глупости — можно его дёргать. Если уж зашла речь о delegate, то нужно упомянуть и об event — они действительно сокращают размер кода при разработке GUI, хотя и ценой отступления от идей ООП. В определённой степени C# менее лаконичен, не вдаваясь в подробности, ограничусь упоминанием ключевых слов virtual, override, ref, out и param, не имеющих аналогов в Java. Влияние платформы на самосознание программистов Безусловно, больше всего на качество программного обеспечения влияет качество самих разработчиков, а не язык программирования. Тем не менее, мой опыт говорит о том, что в подавляющем большинстве проектов на Java для build management используется http://ant.apache.org/, а в .NET очень часто билды делаются встроенными средствами Visual Studio, хотя аналогичные инструменты существуют и для .NET. Кроме этого, в C# нет чётких правил наименования классов и их размещения на диске, что часто вносит дополнительную путаницу (конечно, квалифицированные программисты успешно борются с этой проблемой). В С# нет checked exceptions, есть даже http://www.artima.com/intv/handcuffs.html. Такое решение имеет свои резоны, но если компилятор не контролирует обработку checked exception, то нужно больше рассказывать об обработке ошибок через другие коммуникационные каналы, иначе появятся программисты, которые вообще не будут знать, что такое exception. Тигры рвутся вперёд Есть области, в которых Java доминирует безусловно, например, игры для мобильных телефонов или технология JavaCard. Однако, борьба между C# и Java за долю на рынке будет идти ещё долго, обе платформы будут совершенствоваться, например, в Java 5 и .NET 2.0 появится поддержка generics. Очевидно, что успех каждого конкретного проекта зависит не от языка программирования, а от понимания задачи, умения давать методам понятные названия, способности избегать дублирования кода и других общечеловеческих ценностей. Благодарности Огромное спасибо http://yole.ru/, благодаря которому вам не пришлось читать всю ту ерунду, которую я написал сначала, компании DataArt, которая дала мне возможность заниматься изучением C# в рабочее время, коллегам из компании http://www.dataart.com/, которые оказывали мне интеллектуальную и моральную поддержку, а также компании http://www.jetbrains.com/, которая очень вовремя начала делать ReSharper, который позволяет получать на C# многие виды удовольствия, привычные пользователям IntelliJ IDEA. Особая благодарность http://bleys.spb.ru/ за заботу о букве Ё. Ссылки 1. The C# Programming Language for Java Developers http://msdn.microsoft.com/vstudio/java/gettingstarted/csharpforjava/ 2. J2EE fundamentals for .NET developers http://www-106.ibm.com/developerworks/java/library/j-roadmap1/ |
| Автор: Domestic Cat 13.8.2004, 16:44 | ||
Хорошая статья.
Можно Тигра не ждать, а обoйтись старым добым Мерлином  Generics можно взять здесь: http://java.sun.com/developer/earlyAccess/adding_generics/ и использовать с Java 1.4 - сгенеpированыый байткод будет полностью совместим с JVM. |
| Автор: Kurt 13.8.2004, 18:06 | ||
Да ну лаадно! Про Pet Shop слышали? Кто там победил?...  (Про Pet Shop читал отсюда: http://www.middlewareresearch.com/ конкретный линк на отчет потерял, если кому нужен он (pdf) - могу прислать на мыло или выложить на ftp, если он у вас есть) |
| Автор: Domestic Cat 13.8.2004, 18:34 | ||||||
Ну вот, старая тема 1. Было 2 пет шопа. В пет шопе номер 1 Java побили в пух и прах - и производительность ниже, и писать больше, прямо отсой . Позднее выяснилось, что: а. Бенчмаркинг спонсировался ... кем, как ты думаешь? б. Middleware "забыла" пригласить специалистов по J2EE, но зато специалисты из M$ принимали самое живое участие. Ай-ай-ай. M$ лоханулся, и Middleware решилась на "Reload". Заметь, на gotDotNet лежит СТАРЫЙ документ (2002)! А найти доклад от 2003 года... 2. Смотрим официальный документ, опубликованный Миддлеваре ("Middleware30.pdf").
Читаем выводы (сорри, без перевода, но очень уж обломно)
Победа бо Web(XML)-сервису? Реально в 99% случаев это роли никакой не играет; кроме того, с тех пор прошло некоторое время... "Победы" здесь ничьей нет. В чем-то Java обогнала NET, в чем-то проиграла. Ну и? Заметь, Middleware не называет это даже бенчмаркингом, а "case study". Есть разница? Можно сколько угодно делать пдпбных сравнений, но бенчмаркинг свидетельствует чаще всего о том, что в ДАННОЙ ситуации кто-то был быстрее, а кто-то хуже. Как насчет других параметров? Ну пишут про 101 преимущество Java http://www.freeroller.net/page/ceperez/20030129?catname=101%20List а gotDotNet помещает избранные гистограммы из этого самого доклада и делает вид что это непреложная истина. (А вот эти самые выводы они помещали на сайте? Нет.) Что поменялось? |
| Автор: Kurt 13.8.2004, 20:21 |
| Эх.. Что-то мне не хочется в сотый раз начинать одни и те же споры. Надоело както и заранее известен конец - все останутся при своем мнении.. Вобщем, резюме: каждый использует то, что ему нравится. Вот тока я не пойму одного. Получается, что только M$ на всех давит и доказывает свою правоту, а остальные? Ну не верю я, что Sun (как любая другая фирма) не занимается подобными вещами, ну может, не в таких масштабах. Им же тоже деньги нужны. |
| Автор: Domestic Cat 13.8.2004, 20:35 | ||||
Eсли бы J2EE была действительно такой плохой, все бы перешли на NET, тем более что это дитя M$. Дело здесь не в любви к чему-то, а в том, насколько платформа себя оправдывает.
Любая компания гребет под себя, разница только в способах. У M$ способы простые и подсудные, вот и все. Можешь найти уйму дел против M$. Я это не к тому, чтобы обидеть или что NET хуже Java. Я говорю о политике M$ как компании, о том что ее методы реально подсудны, и что позволь M$ съесть Sun, HP, IBM ..., ничего хорошего не выйдет. То есть, я ругаю M$, а не NET. То, что вообще подобный "конкурс" NET-J2EE появился есть дело рук M$ и его стремление сожрать Sun и подмять под себя рынок web-приложений. Те кто писал NET, прекрасные программеры. Не сомневаюсь в том, что NET это круто. Лично мне не нравится то что он стал очередным орудием M$ в борьбе за монополию. |
| Автор: redrick 13.8.2004, 21:37 |
| предыдущий пост озвучил и мое ИМХО по данному вопросу, ну а чтобы окончательно развеять всякие надежды на поиск истины : http://java.sun.com/performance/reference/whitepapers/WS_Test-1_0.pdf - это вроде не упоминалось здесь. А вообще к вопросу о том что лучше, что хуже - это ведь очень субъективные категории. Более того, понятное дело, даже процент на рынке не показатель - коммерческий успех складывается из кучи факторов, среди которых продуманность и красота далеко не на первом месте. |
| Автор: Domestic Cat 13.8.2004, 21:49 | ||
Спасибо, я об этой ссылке не знал. Кстати, по данным Middleware (2003) Web Services throughput был такой : J2EE~ 400 req/sec NET ~ 800 req/sec Здесь же (2004): J2EE ~ 1700 req/sec NET ~ 600 req/sec что еще раз подтверждает что такие исследования можно проводить бесконечно. |
| Автор: ysirotkin 17.8.2004, 08:38 |
| Господа, ну что вы в самом деле переругались из-за перформанса, при нынешней технике для корпоративных приложений это практически не важно, к тому же узким местом как правило является база данных. |
| Автор: Kurt 17.8.2004, 15:35 | ||
| Собственно, никто и не ругается. Просто не хочется опять одно и то же повторять, хотя очень уж руки чешутся поспорить.
Не понимаю смысла проблемы. Не хочешь - не используй. Это всего лшь ВОЗМОЖНОСТЬ. Лично мне, например, не нравится ради двух полей (допустим, "id" и "класс") создавать класс. Тем более все-таки скорость.. Блин, не люблю когда говорят "современные компьютеры достаточно производительны.." - из-за этого сейчас народ пишет не обращая внимане на ресурсы, железо все быстрее и быстрее, а вот софт все там же. Многие пишут по типу "и так сойдет. Комп все съест.". Итог - сплошные тормоза. Четно говоря, меня удивляет предложение, к-е можно перефразировать так: "нафиг нужны элементы языка для ускорения производительности?".. |
| Автор: ysirotkin 17.8.2004, 22:52 |
| IMHO если в классе есть только поля с тривиальными геттерами и сеттерами, то оптимизировать его должен компилятор. А если сначала завели struct с двумя полями, потом полей стало десять, а потом оказалось, что нужно всё-таки было делать класс, то рефакторинг будет не пропорционально велик. А тормозят современные программы как правило из-за нехватки мозгов у разработчиков - то алгоритм вставят крайне неэффективный, то с многопоточностью не разберутся, такое ни компилятором, ни железом не исправишь. |
| Автор: Domestic Cat 18.8.2004, 16:24 | ||||
| Объясните ламеру - что, структура в C# дейстительно быстрее класса? Насколько я помню C++, там
есть абсолютно то же самое, что и
Лишняя сущность в языке... Хоть это и возможность, но все же наверняка у кого-нибудь возникнет желание "выиграть" в скорости, объявляя вместо классов стуктуры. Ну и отсюда рефакторинг, и пр. и пр. |
| Автор: AntonSaburov 18.8.2004, 16:39 | ||
Структура занимает меньше места, т.к. фактически когда объявляется переменная такого типа, ее не надо создавать через new и она не является ссылкой. Т.е. не надо тратить память на ссылку и не надо тратить время на создание. В принципе идея неплохая. Хорошо использовать для таких объектов как Point или что-то подобное. |
| Автор: Domestic Cat 18.8.2004, 17:34 | ||||||||
Еще непонятнее. Тогда она ведь на стэке создается? Или как поле в классе - но тогда она все равно на хипе занимает место. Все равно - память. Если переменная тuпа my_struct - не ссылка, то если я правильно понимаю, она передается по значению:
- так что структура копируется 2 раза; очень неэффективный способ. В любом случае, пусть есть структура Point:
Мне понадобилось посчитать рассtояние между Point'ами:
В результате все равно придем к классу Point. Имхо, подобные вещи засоряют язык, а польза от них нивелируется их недостатками. |
| Автор: redrick 18.8.2004, 17:46 |
| имхо тут дело такое : структура пришла вообще из С и примечательна тем, что "жестко привязана" к памяти, т. е. на структуру выделяется ровно столько памяти, сколько в сумме занимают её поля - таким образом это просто очень удобная оболочка для байтов (можно ворочать и запихивать/вынимать из памяти сразу большой и структурированный кусок). Таким образом это вещь для низкоуровнего программирования - в последнем примере конечно сподручнее использовать класс, но если таких вызовов будет много, то замена на структуры однозначно даст ускорение - это и будет шаг к оптимизации (в перспективе - переписывание функции на асме =)) ) |
| Автор: Domestic Cat 18.8.2004, 17:58 | ||||
Не совсем так. Структура может занимать больше памяти, чем сумма размеров полей - компилятор может посчитать нужным выделить больше памяти (для оптимизации).
Ну вот и я о том же. Оптимизировав таким образом код, можно получить абсолютно нечитабельный не-ОО кошмар. Для оптимального доступа в Java есть классы CharBuffer, DoubleBuffer,..., реализованные как нативные буфера. B основном быстрый доступ нужен к такого тuпа структурам. |
| Автор: redrick 19.8.2004, 16:09 | ||
не-ОО вовсе не значит кошмар и нечитабельный =) - читают люди, которые, как известно, очень разные бывают =) насчет Java - не спорю, та и есть, просто С и asm призваны для написания низукоуровневых вещей, очень нативных, поэтому говорить об их качествах и недостатках нужно именно на этом поле. Никто не собирается возводит корпоротивные системы (или что там ещё жутко ОО) на С и asm. Даже вебовские штуки очень редко на С пишут (я только один пример знаю =) ). Поэтому тут вроде довольно беспредметное обсуждение получилось (из-за не точно заданных краевых условий =)) ) |
| Автор: Domestic Cat 19.8.2004, 21:36 | ||
Не спорю, но ведь речь о структурах в C#, а его низкоуровневым трудно назвать |
| Автор: AntonSaburov 20.8.2004, 11:31 | ||
|
| Автор: redrick 20.8.2004, 15:25 |
| про C# молчу - я его использую по стольку по скольку (только когда нужно использовать что то написанное другими на нем). Вообще по синтаксису нельзя не заметить сходства с Java =) . Может конечно это и случайно, но я всё таки не тороплюсь втягиваться во всякие МС-овские нововведения, особенно после того как прочитал вот это http://forum.vingrad.ru/index.php?showtopic=28222&st=0&unread=&#entry202619 |