Что лучше: Java или C#?

Java
55
Нейтральная
сторона
7
C#
46
Sun
Прежде чем писать комментарии или выбрать сторону вы должны авторизироваться!
Microsoft

16-04-2009 18:51 +2

Support more platforms

7 комментариев
lynx 16-04-2009 19:10 0

dragonsamael, не аргумент - у C# (как и у всех .нет языков) есть не-виндовс альтернатива Моно. позволяется без перекомпиляции запускать в техже никсах теже программы на шарпе.

twirpx 17-04-2009 13:32 0

dragonsamael, Вот только это преимущество - абстракный конь в вакууме по-сути.

Ни разу не встречал в реальном ТЗ требования - кроссплатформеннось.

Для настольных приложений Java применяется редко, C# - все чаще на вин-платформах, но все еще уступает доле C++. А в серверных решениях ваша хваленая кросплатформенность мало кому нужна т.к. платформа и средства выбираются под задачу.

Kidalv 07-01-2011 17:08 0

twirpx, В серверных решениях Java - тоже лучший язык

danpetruk 27-12-2013 21:10 0

lynx, Mono. С вылетами через раз.

danpetruk 27-12-2013 21:11 0

twirpx, Сервера к вашему сведению держатся на linux

cherepets 27-12-2013 21:14 0

danpetruk, По моему это сообщение уже давно начало сигнализировать окончание общения.

cherepets 18-03-2017 11:39 0

dragonsamael, Наоборот же.

16-04-2009 19:15 +2

Java де-факто стандарт в корпоративных приложениях.

3 комментария
twirpx 17-04-2009 13:25 +2

rct, Ссылочку на независимые исследование и/или бюро стандартизации...

Tro 28-12-2013 16:33 0

danpetruk, Сравните с платформой J2EE, где нет ничего, кроме Java :-)
Лол. А как же Скала, Груви?

16-04-2009 20:23 0

Элегантный и неизбыточный (в отличии, например, от C#) язык программирования. // Не примешивайте к этому голосованию сравнения технологий, речь идёт только о языках программирования.

5 комментариев
paradoxs 17-04-2009 05:36 0

drevlyanin, К сожалению Java и сопутствующие ей технологии от нее неотделимы. Кроме того рассматривать их ТОЛЬКО как языки не имеет смысла. Все знают что C# зарулит. Это очевидно.

twirpx 17-04-2009 13:26 +1

drevlyanin, Элегантность не обьективная мера - не аргумент.

В чем состоит избыточность? Примеры?

danpetruk 27-12-2013 21:15 0

twirpx, Не избыточность - есть библиотеки под все случаи жизни. Для java это true. Для C# - false

danpetruk 27-12-2013 21:15 0

paradoxs, Ага, рулит, со своим дебильным : вместо extends

cherepets 27-12-2013 21:20 +2

danpetruk, Избыточность = наличие библиотек

а) Ты ебнутый
б) J# и IKVMC лишают аргумент про количество библиотек смысла.

16-04-2009 21:31 0

Уже есть такой же

1 комментарий
Lelik 01-10-2009 23:21 0

rct, то си++ вс ява

а сИплюсплюс!= СИшарп

27-04-2009 19:07 0

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

1 комментарий
NightmareZ 01-10-2009 23:00 +1

Reactobior, Во-первых .NET - это законченная платформа. Если говорить о жабе, которая подрумевается жабой, тогда можно сказать только одно, жаба дерьмо. Она отстаёт от дотнета и то, что от таких платформ нужно, умеет настолько глючно, что лучше на бэйсике написать решение.

01-10-2009 20:09 +1

C# - не четыре плюса, а решетка. Т.е. рабство мелкомягких

7 комментариев
NightmareZ 01-10-2009 23:01 0

HolyDark, Жаба - слизкая и зелёная. А всё зелёное уныло, как ваша сторона.

HolyDark 01-10-2009 23:30 0

NightmareZ, net - та же java только от мелкомягких

NightmareZ 01-10-2009 23:43 0

HolyDark, Ты программист? На чём пишешь? Пруфлинки?

PadonakSem 01-10-2009 23:44 0

NightmareZ, А всё зелёное уныло, как ваша сторона.

Зелёный - цвет жизни (и троллей). А голубой - как-то стрёмно отдаёт ахтунгом. )))))))))

NightmareZ 08-05-2011 17:30 0

HolyDark, Так пруфы будут? Я устал ждать.

NightmareZ 08-05-2011 17:30 0

HolyDark, Рабство под Ораклом лучше? :)

NightmareZ 06-02-2012 18:34 0

HolyDark, Ты мне будешь отвечать, мать твою?

01-10-2009 23:42 +1

Жаба - старый, сформировавшийся язык и платформа, с огромным комьюнити, с огромной базой классов, алгоритмов, наработок на все случаи жизни. Огромный плюс Жабы - непривязанность к определённой ОС, отсутствие Vendor Lock-In.

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

3 комментария
NightmareZ 01-10-2009 23:57 0

PadonakSem, Ну давай расскажи, какие же худшие качества унаследовал C#?

NightmareZ 08-05-2011 17:31 0

PadonakSem, Я внимательно слушаю.

NightmareZ 06-02-2012 18:33 0

PadonakSem, Я всё ещё, блять, слушаю.

04-10-2010 23:47 +1

С одной стороны, у C# рюшечек больше. Но с другой стороны, Java последовательнее.

2 комментария
NightmareZ 08-05-2011 17:32 0

opera.rulez, В чём она последовательна? В том, что по-человечески колбэки сделать в ней нельзя? Или в недодженериках? Или, может, в strictfp заключается последовательность? А, может, в чём-то ещё?

NightmareZ 06-02-2012 18:34 0

opera.rulez, В чём она последовательнее, блеать?

07-01-2011 23:51 0

холивар Java vs C++ был бы поинтереснее...

0 комментариев
31-07-2011 19:41 0

FYI:
Java vs C#

JAVA vs C#

И... барабанная дробь:
Oracle vs Microsoft — холивар i.c — того же автора, что и этот. Либо у автора лёгкая форма забывчивости, либо Java и C# поломали ему жизнь и ему пришлось подсесть на гидроксид пентагидрида дикарбония.

По теме холивара: Java пока универсальнее.

Что будем делать: закрывать или минусовать?

34 комментария
Tro 31-07-2011 19:56 +1

opera.rulez, В третьем холиваре сравнивались компании.

opera.rulez 31-07-2011 20:07 0

Tro, Хорошо. Третий холивар исключаю из списка, потому что отношение к компаниям может не коррелировать с отношением к языкам.

В тех двух вроде всё сказали. Я не знаю, что добавить.

1. Java поддерживается огромным количеством платформ, а C# — только страшным фреймворком .NET (и ещё его пародиями Mono и dotGNU).
2. Java достаточно простой язык, а в C# много чего налеплено и каждую очередную версию тянет в новую сторону.
3. Для Java уже есть куча готовых библиотек, а C# только развивается.

Linux 01-08-2011 15:32 0

opera.rulez, Хороший вар, можно оставить, баянчики надо периодически поднимать, время идёт - мнения меняются.

opera.rulez 02-08-2011 01:42 0

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

Сайт хранит кучу холиваров, не набравших даже 10 комментариев. Зачем плодить такие огрызки?

Linux 02-08-2011 18:14 +2

opera.rulez, Долой огрызки! Эпл не пройдёт!

Jotun 11-09-2016 12:56 +2

opera.rulez, 2. Java достаточно простой язык, а в C# много чего налеплено и каждую очередную версию тянет в новую сторону.
Смешно, но если говорить про текущие версии C# и Java, то в подобной красивой мультипарадигменности я скорее вижу преимущество C# перед Java.

1. Java поддерживается огромным количеством платформ, а C# — только страшным фреймворком .NET (и ещё его пародиями Mono и dotGNU).
В 2016 году, когда mono полностью догнал оригинальный .Net, когда релизится .Net Core и Kestrel, когда Xamarin стремительно набирает обороты, я бы пересмотрел этот аргумент

cherepets 28-11-2016 18:21 0

Jotun, Да, Java сейчас наоборот надо ругать за недостаточную кроссплатформенность.

BerkutOi 28-11-2016 18:35 +1

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

именно это подразумевают ведь когда говорят что джава кроссплатформенная

cherepets 28-11-2016 18:45 +1

BerkutOi, .Net Standard - полностью кроссплатформенный. Если ты напишешь библиотеку на нем, то ты можешь её использовать в любых типах приложений на всех поддерживаемых платформах (Windows (как win32, так и uwp), Linux, Mac, iOS, Android) и тебе не надо никак разбираться вызывают ли этот код из Mono или .Net Core.

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

Tro 28-11-2016 19:18 0

Jotun, когда Xamarin стремительно набирает обороты
Уже который год слышу эту фразу. Он мб и был полезен, потому что тормозили с переходом на OpenJDK (правда, я так и не понял, почему они это сделали лишь из-за авторских прав - преимущество в виде Java 8 слишком велико), но с Android N уже не очень актуально.

cherepets 28-11-2016 19:41 0

Tro, В смысле не актуально? Java 8 нормально дружит с iOS и всеми MS-платформами?

Суть Xamarin в том что иметь здоровый кусок кода кроссплатформенным, но при этом не выглядеть "иноземцем" ни на одной из платформ.

Jotun 28-11-2016 21:15 0

Tro, Ну, ты можешь эту фразу слышать который год от людей, которые просто рекламируют Майкрософт, но сейчас, например, ты слышишь её от человека, который год делает на нём приложения под три платформы в enterprise-секторе.

cherepets 28-11-2016 22:51 0

Jotun, А ты пользуешься MvvmLight или ReactiveUi?

Tro 28-11-2016 23:05 +2

cherepets, Во-первых, можно оставить только iOS - мало даже серьёзных проектов делают версию под винду. Во-вторых, пласт кода под отдельные платформы получается довольно жирным, да и вообще Android и iOS очень разные - начнём хотя бы с того, что в Андроиде есть доступ к файловой системе. Ну и в третьих, одному человеку трудно разбираться во всех тонкостях (гуи, внутреннее взаимодействие) конкретной платформы, и для качественного приложения лучше нанять отдельно Android- и iOS-разработчиков. Десктопную кроссплатформенность ещё можно как-то понять - разницы особой нет, но на мобилах оно не так.

Tro 28-11-2016 23:10 0

Jotun, Я и его антирекламу слышу от опытных разработчиков. Но вот в enterprise оно мб и полезно - требования скорее типа "чтоб надёжно работало", а не "чтоб красиво и нативно выглядело и использовало все фичи платформы".

cherepets 28-11-2016 23:19 0

Tro, Во-первых, даже если бы вообще весь мир кроме MS отказался бы от винды, то это всё равно это бы не называлось "мало проектов". А это не так.

Большей части приложении обычно требуются как раз таки полностью общие возможности (сеть... эм, ну и достаточно пока). Более того, с NControl можно даже сделать свой контрол с единым кодом отрисовки на все 3 платформы.

UI - да, похоже что лучше делать отдельно (по крайней мере я в итоге и правда просто нанял еще 2х чуваков). Но если приложение не особо "ui intensive" (например, какая-нить внутрикорпоративная хрень), то можно делать на Forms - там WPFный разработчик справится один и приложение НЕ будет выглядеть как что-то инородное.

Кстати, общие код можно использовать не только между мобилками, но, например, скинуть и все объекты передающиеся между клиентом и сервером в одну библиотеку и использовать одно и то же средство сериализации/десериализации.
В итоге избегаем кучи проблем что отправленное распарсилось "как-то не так".

cherepets 28-11-2016 23:21 0

Tro, Но он позволяет "чтоб красиво и нативно выглядело и использовало все фичи платформы".
Потому что в Xamarin это всегда и будет нативная разметка и всегда будет доступ к полному нативному SDK всех платформ.

Jotun 28-11-2016 23:53 0

cherepets, MvvmCross, а на микро-проекте, который сделали мимоходом в октябре, были Xamarin.Forms и... спойлер

Jotun 28-11-2016 23:56 +1

Tro, начнём хотя бы с того, что в Андроиде есть доступ к файловой системе
В iOS тоже

Ну и в третьих, одному человеку трудно разбираться во всех тонкостях (гуи, внутреннее взаимодействие) конкретной платформы, и для качественного приложения лучше нанять отдельно Android- и iOS-разработчиков.
Года на Xamarin хватило, чтобы я нормально разобрался в iOS/Android. Про UWP пока сказать такого не могу ещё.

Во-вторых, пласт кода под отдельные платформы получается довольно жирным
Зависит от приложения сильно. Насколько я могу судить по рабочим и университетским проектам, в оптимистичных сценариях, суммарного кода в "нативных" частях будет меньше, чем разделяемого. В пессимистичных, в каждой OS-specific части его будет примерно столько же, сколько и в PCL.

Jotun 28-11-2016 23:59 0

Jotun, Но вообще хотел бы закончить эту серию аргументов следующей характеристикой: мне не нравится педалить под Xamarin в первую очередь из-за того, что мне не нравится то, какие говёные по своей сути iOS и Android.
И, кстати, это хорошо вписывается в то, насколько неаккуратные и говнокодистые мобильные разработчики по сравнению с .Net или Java-девелоперами.

Tro 29-11-2016 00:03 0

cherepets, Во-первых, даже если бы вообще весь мир кроме MS отказался бы от винды, то это всё равно это бы не называлось "мало проектов". А это не так.
Вот пусть MS и юзает свой Xamarin - под три платформы им уже тяжко будет писать код.

Кстати, общие код можно использовать не только между мобилками, но, например, скинуть и все объекты передающиеся между клиентом и сервером в одну библиотеку и использовать одно и то же средство сериализации/десериализации.
И на чём тогда писать сервер? На асп.нет, что ли? И вообще передавать сериализованные объекты - не самая безопасная затея.

cherepets 29-11-2016 00:09 0

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

А про Forms по прежнему не согласен. Аргумент прежний: друг умеет делать на нём хорошо.
В общем-то и мне бы он понравился если б в моем случае пол проекта не превращалось в сплошные рендереры (кстати, говорят, что это еще и дико тормозит => совсем плохая идея).

Tro 29-11-2016 00:09 +1

Jotun, В iOS тоже
Начиная с iOS 8 - не столь давно, пользователи к ним не привыкли, и сообщение типа "мы сохранили ваш файл туда-то" будет для них неожиданным. Да и там почти все файлы бэкапятся в iTunes - какой-нибудь бесполезный для пользователя файл не положить (базу данных, например - с ней работа в двух платформах совсем разная).

Года на Xamarin хватило, чтобы я нормально разобрался в iOS/Android.
Кроме всего прочего, нужно ещё быть активным пользователем своей системы, чтоб не страдал UX (опять же, для корпоративных приложений не актуально). Ты используешь одновременно две системы?

Jotun 29-11-2016 00:13 +1

Tro, Кроме всего прочего, нужно ещё быть активным пользователем своей системы, чтоб не страдал UX (опять же, для корпоративных приложений не актуально). Ты используешь одновременно две системы?
Нет, я не использую ни одну из них, поэтому первые месяца четыре было сложновато. Но, опять же, у нас за UX отвечает "бог дизайна и цвета" a.k.a. Senior designer.

Начиная с iOS 8 - не столь давно
Позволю с этим не согласиться. Это тебе не Андроид, где после выхода версии люди четыре года сидят на предыдущей.
После выхода iOS 10 прошло меньше квартала, а у нас 85% логов уже с iOS 10.

Tro 29-11-2016 00:17 0

Jotun, Это тебе не Андроид, где после выхода версии люди четыре года сидят на предыдущей.
После выхода iOS 10 прошло меньше квартала, а у нас 85% логов уже с iOS 10.

Мы друг другу не противоречим - я говорю, что даже при переходе на новые версии системы привычки у пользователей не меняются.

Jotun 29-11-2016 00:17 0

cherepets, А мне чет MvvmCross дико не понравился. Он же считай вообще все архитектуру приложения перелопачивает и пытается её привести к какому-то совсем уж убогому варианту где все отдано только на соблюдение концепций паттерна и не важно что ты хочешь из фонового процесс переходы совершать, а на винде нормально стрелку обработать.
Да, мне в нём тоже не нравится жёсткое "вбивание" модели навигации в рамки, удобные для iOS, более-менее удобные для Android (если нормально напедалить presenter и/или интеракторы), и вообще печальные для UWP.

А про Forms по прежнему не согласен. Аргумент прежний: друг умеет делать на нём хорошо.
Хз, как можно сделать нормально, если там половина приложения течёт по памяти, классы для UI выглядят как кусок говна, а некоторые нативные контролы невозможно заимплементить.
Ну, я, конечно, утрирую, но суть ясна.
Да, маленькие приложения на Xamarin.Forms можно делать, но для enterprise эта технология не тянет, имхо

cherepets 29-11-2016 00:18 0

Tro, Ну они и юзают. И все остальные кто хочет сэкономить примерно ~треть времени на получение такого же результата как обычно.

Сервер писать тоже на шарпе, но не обязательно Asp.Net - всё же это здоровенный фреймворк с кучей всего и ориентированный веб.
Лично мне кажется самым простым вариантом просто из службы принимать JSON RPC.

Почему плохая идея передавать сериализованные объекты и какая у нас по сути есть альтернатива?

Jotun 29-11-2016 00:24 0

cherepets, Лично мне кажется самым простым вариантом просто из службы принимать JSON RPC.
ASP.NET Web API есть прекрасный. Он не очень легковесный, но зато очень простой и высокоуровневый.
И позволяет на обеих сторонах использовать Newtonsoft Json, например.
Мы даже делали пару раз следующий подход: библиотека с DTO делалась portable и шарилась между solution'ами мобильного и веба.

Tro 29-11-2016 00:27 0

cherepets, Почему плохая идея передавать сериализованные объекты и какая у нас по сути есть альтернатива?
Там может вылезти какая-нибудь рефлексивная бяка. Альтернатива - всякие JSON, но они тоже могут пониматься под сериализацией - я именно про нативную говорил.

cherepets 29-11-2016 00:31 0

Jotun, Ну, это же всё равно IIS, Web.config и т.п.?
Лично для меня основной аргумент за просто сервис - то что весь деплой сводится всегда к "скопируй dll в папку" (ну еще в первый раз батник надо запустить), то есть нулевые потребности в конфигурации.
Более того, текущее серверное приложение у меня исполняет еще и другие функции (не только HTTP сервер) и укладывать это в концепцию Asp.Net как-то странно.

cherepets 29-11-2016 00:35 0

Tro, Ну вот и я вообще имел ввиду в первую очередь JSON :)
Нативную тоже использую и честно говоря мне понятна проблема из статьи - видимо речь идет о каком-то конкретном неудачном сериализаторе.

Jotun 29-11-2016 00:39 0

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

cherepets 29-11-2016 00:51 0

Jotun, Из личного то проекта не охота делать очередного ужасного корпоративного монстра, охота чтобы он был максимально простым и приятным (но при этом всё делал).

Кстати, в Azure у меня для пары приложений крутятся Asp.Net бэкэнды и вот там они меня не напрягают: просто кладешь код в папку, а IIS и конфиги - уже забота совсем других людей.
Но, к сожалению, на часть сервисов у них ценники нездоровые (да серьезно, ~$25 за каждую коллекцию в DocumentDB?? например, Google плевать сколько коллекций в монге за <$6 ) => не для всего покатит.

cherepets 30-11-2016 12:48 0

Jotun, Большой аргумент "за" Forms: не нужно ебаться с версткой сделанной Apple.
Я хотел вчера пару мелочей помочь поправить и чуть с ума не сошел, это дико запутанная херня. Всё же заслуженно им больше денег платят чем остальным "мобильщикам".
Даже Android приятнее (пока не нужны вложенные скроллы).

06-02-2012 23:46 0

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

33 комментария
NightmareZ 06-02-2012 23:49 +1

Tro, Нормальной поддержки нормальных систем? Это ты про линупс сейчас штоле, которого на десктопах чуть меньше одного процента? Так я тебя огорчу, даже в нём есть mono - реализация дотнет фреймворка.

Tro 06-02-2012 23:52 0

NightmareZ, Кэп, я знаю, что есть Моно, но оно же нормальным не является. Я не могу запустить Paint.NET - и какой смысл было писать его на C#?

cherepets 06-02-2012 23:59 +1

Tro, Главная проблема - не отсутствие .Net под чем-то неWin, а отсутствие пользователей под неWin.

Тем более, что уже давно есть VirtualBox (или во что его там оракл переименовал?) с интеграцией окон в ту ОС в которой работаешь. Конечно решение не быстрое, но надежное и когда что-то ну очень надо, то можно и потерпеть.

Правда я сейчас наоборот во имя Maven, Ant и ASM терплю бубунту в виртуалке.

NightmareZ 07-02-2012 00:23 0

Tro, Paint.NET ты не можешь запустить не потому, что он написан на шарпе, а потому что разработчики юзали windows-specific фичи и клали болта на линупсоидов.

Tro 07-02-2012 00:24 0

NightmareZ, И каков смысл писать это не нативно?

NightmareZ 07-02-2012 09:15 +1

Tro, Быстрее, удобнее, качественнее, меньше багов, утечек и прочей фигни.

Tro 07-02-2012 14:06 0

NightmareZ, Количество багов в C++ меньше, чем в C#? Лоол. На чём тогда .NET написан? На чём-то очень неудобном, некачественном, багнутом и имеющим утечки?

cherepets 07-02-2012 20:18 +1

Tro, На чём-то очень неудобном, некачественном, багнутом и имеющим утечки

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

Tro 07-02-2012 21:03 0

cherepets, Он пишет, что низкоуровневые языки имеют некачество, багнутость и утечки. Тогда КАК то, что написано на этом языке, может быть хорошим? .NET написан на чём-то нативном. Значит, оно должно иметь всё то, что является противоположным сказанному в посте NightmareZ.

cherepets 07-02-2012 21:06 +1

Tro, С++ - пшеница. Она твердая, с шелухой и её не особо приятно есть.
С# - макароны. Сделаны из пшеницы, но они отлично варятся и выходят мягкими и вкусными.

Tro 07-02-2012 21:20 0

cherepets, Абсолютно неверная аналогия, ибо удобнее C++ из популярных есть только Python. Что же есть удобного в C#?

cherepets 07-02-2012 21:23 +1

Tro, В C# меньше мест где ты можешь ошибиться, ибо это всё уже сделали за тебя.
И на программиста вешают только бизнес-логику, а не возню с выводом формы на экран.

NightmareZ 07-02-2012 21:27 0

Tro, Не поверишь, в то же, что в упомянутом тобой Python, плюс ещё немного :)

Tro 07-02-2012 21:37 0

cherepets, Для этого есть Python. Опять же, с кроссплатформенностью у него лучше.

cherepets 07-02-2012 21:39 +1

Tro, Ничего не лучше. Windows Phone и Xbox не поддерживаются.
Причем доля виндафонов в общем траффике уже больше процента, а линукса до сих пор меньше, так что...

Tro 07-02-2012 21:46 0

cherepets, WinPhone - очередная винда, которая может стать популярной лишь из-за рекламы (которая имеет очень навязчивый характер). Пощупал - говно. Реально говно, ибо есть только 2 возможности - запускать приложения и вытаскивать на основной экран что-то мультимедийное (виджеты лучше). Вряд ли будет действительно много пользователей.
Дальше. Python не хуже C# и имеет бОльшую кроссплатформенность. a + 1 > a, смысл выбирать что-то, когда можно выбрать что-то хоть немного лучшее?

cherepets 07-02-2012 21:54 0

Tro, Пощупал - говно.

Ну, по функционалу и правда гавно как айОС. Но решает реально красивый и реальный плавный интерфейс + рабочий софт совместимый с ПеКашными братьями.
И еще меня радует сама идея: есть достаточно широкий ассортимент аппаратов, но полностью остутствую проблемы с совместимостью.

a + 1 > a

Нет. Мы сравнимаем "a + x - y" с "a - x + y".

Tro 07-02-2012 22:17 0

cherepets, но полностью остутствую проблемы с совместимостью
Это пока... системе-то всего 1 год. Именно у этой компании очень много проблем с совместимостью между различными продуктами.

cherepets 07-02-2012 22:19 0

Tro, Ну так спика под дроидом у меня на момент покупки (еще до выхода 1.6) не погла запустить ~30% всех приложений.

Tro 07-02-2012 22:40 0

cherepets, Согласен, есть небольшие проблемы с этим у Андроида. Но у МС часто это доходит до 50-100%: Office, W7, WM6.5 -> WP7...

cherepets 07-02-2012 22:52 +1

Tro, Офис 2010 и 2007 открывают файлы созданные в абсолютно любых версиях офиса. Для 2003 требуется дополенение бесплатно распространяемое майкрософтом для совместимости с 07 и 10. Так что там всё идеально.

Win7 полностью совместим с Vista и имеет отдельный режим для полной совместимости с ХР. С прошлыми версиями в целом совместимость есть, но много проблем из-за того что дрова всего оборудования сильно изменились.

Win8 имеет поддержку 16-битных программ и обратную совместимость вплоть аж до вин3.1.

Windows Mobile и Windows Phone - разные ОС и совместимости между ними быть не должно. Но Windows Phone имеет бинарную совместимость с Windows CE, продолжателем которой он является, а так же почти полную с SilverLight (не совместимо только то для чего нет железа. Например, поворот акселерометром в браузере, конечно же не будет работать).


Да, ужас с совместимостью у мс))

NightmareZ 08-02-2012 17:06 0

Tro, Именно у этой компании очень много проблем с совместимостью между различными продуктами.

Ты херню несёшь. Я даже не знаю, что на это можно ответить. Это как если бы кто-то сказал, что Земля квадратная. Очевидно бы было сразу, что человек идиот.

Tro 08-02-2012 19:30 0

cherepets, Для 2003 требуется дополенение бесплатно распространяемое майкрософтом для совместимости с 07 и 10. Так что там всё идеально.
Но оно не всегда имеется у клиента. Проще брать с собой переносную версию LibreOffice (без установки). Кстати, у МС есть аналог этой вещи?
не совместимо только то для чего нет железа. Например, поворот акселерометром в браузере, конечно же не будет работать
Силверлайт же там не в браузере... причём тут он?

opera.rulez 08-02-2012 19:36 0

Tro, Переносной офис? Ты смеёшься? Это же помощь пиратам!

MS Office 2010 вообще распространяется по хитрожопой технологии Click-and-Run, а именно в виде образа виртуальной файловой системы, к которой у юзера нет доступа (доступ есть только к ярлыку запуска программ), чтобы его нельзя было похакать.

cherepets 08-02-2012 23:11 0

Tro, Проще пользоваться майкрософт веб офисом.

Tro 08-02-2012 23:40 0

cherepets, Он платный, и есть Гугл Докс.

cherepets 09-02-2012 00:19 0

Tro, С каких это пор он платный?

opera.rulez 09-02-2012 01:33 +1

cherepets, Балмер его знает, с каких, но платный: www.microsoft.com/ru-ru/office365/buy-sm ...

cherepets 09-02-2012 07:36 0

opera.rulez, Office 365 != Office Web App.

Заводишь учетку live -> skydrive.live.com/ -> Создать Word/Excel/Power Point/One Note.

opera.rulez 09-02-2012 15:03 0

cherepets, Как всё хитро у этого Микрософта. И где там написано, что эта штука предоставляет доступ к приложениям Офиса?

cherepets 09-02-2012 16:42 0

opera.rulez, Не знаю где написано, но я же написал как туда попасть и какие файлы оно умеет создавать.

А 365 он обычный клиентский, но с какими то облачными сервисами и lynqом.

danpetruk 27-12-2013 21:17 0

cherepets, Попробуй неlinux в энтерпрайзе. С ума сойдёшь

cherepets 27-12-2013 21:21 0

danpetruk, Пробую в течение долгого времени. Люто всем доволен. Не представляю что бывает лучше WCF.

07-02-2012 21:24 0

Для использования C# в веб-страницах нужен плагин Silverlight, который есть у нуля человек, включая Стива Балмера, Черепца, i.c и меня. Плагин же Java есть у многих.

2 комментария
NightmareZ 07-02-2012 21:28 +1

opera.rulez, Не пиши в вебе на шарпе. Пиши на шарпе под винду, вендофоны и асп.

cherepets 07-02-2012 21:31 +1

opera.rulez, Я недавно помучал сильверлайт 5.0 и выяснил, что хвалёную поддержку ХНА ты фиг заведешь и даже если заведешь, у юзеров все равно работать не будет.

А раз игрушки отпадают, то остается только формошлёпить для корпоративных юзеров, которым ты вполне можешь навязать установку плагина.

Кстати, C# же и в Unity используют, а его веб-плеер много у кого стоит.

16-04-2009 18:52 +1

Support from Microsoft

3 комментария
twirpx 17-04-2009 13:34 -1

dragonsamael, В чем выражается?
Вы подписчик MSDN?

Я - нет. У меня нет никого суппорта.

NightmareZ 08-05-2011 17:41 0

twirpx, Ну так подпишись же.

danpetruk 27-12-2013 20:59 0

dragonsamael, А java from oracle

16-04-2009 19:11 +3

Кодю на Java вот уже целый год. Кодим сложную систему по документообороту. Клиентская часть шарповская, сервер на яве. Обе сопоставимые по сложности. Друзья мои, я плачу каждый день. Мне жалко яву за ее убожество и наколеночность. Это очень печально. Я уж молчу про богатство синтаксиса C# по сравнению с Java.

48 комментариев
inj 17-04-2009 05:43 0

paradoxs, Ваше богатство синтаксиса выливается в богатство багов.

paradoxs 17-04-2009 11:35 +3

inj, Приведите пример какой "синтаксический сахар" шарпа является источником багов.

twirpx 17-04-2009 13:27 0

inj, Да, таки примеры в студию.

inj 18-04-2009 23:51 0

paradoxs, Хм, C#, безбажен?

NightmareZ 13-03-2011 23:06 0

inj, Вот чё ты сейчас пронёс? Что вообще в твоём понимание означает, что некоторый язык безбажен?

danpetruk 27-12-2013 21:01 0

paradoxs, Чем же синтаксис C# богат? Дурацкой : вместо extends

opera.rulez 28-12-2013 16:45 +1

danpetruk, paradoxs вряд ли ответит, но у сторонников C# есть аргументы посерьёзнее, чем знаки препинания: ссылка.

Я считаю, что перегрузка операторов и вывод типов коварны, потому и не занял синюю сторону.

Tro 17-03-2017 23:26 +1

opera.rulez, Вывод типов есть, а diamond operator'а нет. В итоге шарпоиды всё время пишут что-то типа List<AmazingClass<FuckingClass<CoolClass>>> GreatfulFunction() {return new List<AmazingClass<FuckingClass<CoolClass>>> GreatfulFunction();} вместо return new List<>();

opera.rulez 17-03-2017 23:30 0

Tro, Интересно. А он где-нибудь ещё может пригодиться, кроме такого примера?

Tro 18-03-2017 00:24 +1

opera.rulez, С наличием var'а - не сильно много где. Но применять этот var по-хорошему надо в ограниченном количестве мест, чтоб не нарушать читаемость кода. Так что в каком-нибудь
IList<SomeClass> someList = new List<SomeClass>();
второй SomeClass лишний, тип и без него понятен без нарушения читаемости.

cherepets 18-03-2017 11:38 0

Tro, Решарпер по дефолту вроде всегда предлагает использовать var.
Если метод возвращает тип, который неочевиден из сигнатуры - стоит его переделать, а не писать каждый раз тип.

Jotun 18-03-2017 19:53 +1

Tro, Ты наркоман штоле?
IList<SomeClass> someList = new List<SomeClass>() - это как раз супермегастандартный пример того, где нужно использовать var (или auto в C++).

Вот что меня больше всего смешит в сраче про выведение типов - так это то, как джависты, которые называли это минусом шарпа/плюсов/пайтона/любого другого подобного языка (нужное подчеркнуть), резко стали хайпить эту возможность, когда было озвучено, что она будет введена в следующей версии джавы.

Tro 18-03-2017 20:34 0

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

Jotun 18-03-2017 22:12 +1

Tro, Супермегастандартный пример - это какой-нибудь итератор, где без вара сотня лишних букв получается. А здесь всё ок.
Ну все, ты меня затроллил. Ведь не каждый день встречается джавист, который может ответить мне, какие примеры использования var нормальные, а какие - нет.

Шутка. Просто ты ошибся. И ошибся. И ошибся.

Если посыл неочевиден, поясню. Господа из Майкрософт в своих гайдлайнах для C# считают нормальным использовать var там, где правая сторона выражения указывает на тип (приведенные тобой примеры). Господа из Майкрософт же для Visual C++ рекомендуют использовать auto вообще везде.
У господина Страуструпа в Cpp Coding Guidelines нет гайдлайна насчет использования auto. Стоит только отметить, что он использует auto в ~70% случаев в этих самых гайдлайнах.
Теперь, когда мы сошлись во мнении, что приведенный мной пример использования var абсолютно нормален, скажу, почему считаю его суперстандартным: потому что во всех проектах, репозиториях и примерах кода, которые я просмотрел на шарпе, все и всегда пишут именно так.
Пруфов, что я читал больше кода на шарпе, чем ты, не будет, прости(

Ну и в конце картинка-триггер

Tro 18-03-2017 23:26 +1

Jotun, msdn.microsoft.com/ru-ru/library/dd29366...
Надежность. Если тип выражения изменился (в том числе если изменен возвращаемый тип функции), это не влияет на его работу.
Без auto, если изменился тип возвращаемой функции, возникнет ошибка. Ты придёшь в место ошибки и проверишь, ничего ли не поломалось. Даже если не придётся править ничего, кроме типа переменной. С выведением типов оно промолчит, и если используемые методы у нового типа те же самые (а с перегрузкой операторов шанс такого события ещё больше), у нас есть шанс заняться весёлым дебагом.

Эффективность. Преобразование гарантированно не будет выполнено.
Удобство использования. Можно не беспокоиться об опечатках и ошибках.
Эффективность. Быстрое написание кода.

Тут я вообще ничего не понял. Про второе я выше описал, что это не так. Про третье - лол, VS не умеет в генерацию кода?

И вернёмся к нашему примеру. Все знают, что лучше использовать интерфейсы, чем реализацию. У шарпоидов вообще плохо с пониманием классов и интерфейсов - у них что наследование от класса, что реализация интерфейса делаются через обычное двоеточие, хотя это две совсем разные вещи. Но мы не об этом. Представим, что в Джаве есть var, и запилили такую фигню:

var list = new LinkedList<String>();

Потом, не особо думая, вызвали list.getFirst() (этого метода нет у интерфейса List). Через сто лет решили, что ArrayList здесь будет лучше, и вставили его. Всё, у нас ошибки, так как используем специфические для LinkedList методы. Для избежания этого мы пишем что-то типа

List<String> list = new LinkedList<>();

И тем самым гарантируем возможность использования любой реализации листа. Эта штука описана в Effective Java, это вообще один из самых базовых принципов использования ООП. Так что var реально полезен (я не против его использования) в диких случаях - например, со stream API уровни вложенности дженериков в промежуточных результатах (к счастью, их не нужно выносить в отдельную переменную, но всё же) могут достигать 2-3. Но в случае каких-нибудь примитивов (меняешь в своём API int на double и радуешься, как пользователи библиотеки ищут причины кривой работы программы из-за поменявшейся семантики деления), реализующих интерфейсы классов (всякие коллекции) - спс, не надо.

Jotun 18-03-2017 23:49 0

Tro, У шарпоидов вообще плохо с пониманием классов и интерфейсов - у них что наследование от класса, что реализация интерфейса делаются через обычное двоеточие, хотя это две совсем разные вещи.
То ли дело Джава - язык, где интерфейсы могут иметь built-in реализацию методов, что было введено как костыль для backward compaitibility. Как говорится, в чужом глазу соринку видеть, а в своем хуя не заметить.

Представим, что в Джаве есть var, и запилили такую фигню:

var list = new LinkedList<String>();

Потом, не особо думая, вызвали list.getFirst() (этого метода нет у интерфейса List). Через сто лет решили, что ArrayList здесь будет лучше, и вставили его. Всё, у нас ошибки, так как используем специфические для LinkedList методы. Для избежания этого мы пишем что-то типа

List<String> list = new LinkedList<>();

И тем самым гарантируем возможность использования любой реализации листа.


Суть в том, что в приведенном примере есть две существенных проблемы.
Во-первых, если мы вызвали getFirst (какая-то слишком специфичная для джавы хуйня, но не будем сейчас об этом), то наверное же мы его вызвали не просто так. Например, потому что мы используем какую-то специфичную особенность той коллекции, которую мы используем (я говорю про асимптотическую сложность различных операций, разумеется). Если так, то твой пример некорректен, ведь в правильном объявлении мы должны были присвоить переменной тип специфичного интерфейса LinkedList'а.
Если же в Джаве есть коллекции, у которых есть специфичные для них методы, которые не внесены в интерфейс, либо же если этот твой getFirst() является полным дубликатом какого-то другого метода из интерфейса, не несущим никакой смысловой нагрузки, то это свидетельствует об откровенно хуевом дизайне стандартной библиотеки классов в Java.
OH WAIT, это и была проблема #2.
Ведь, кажется, выучив "три кита ООП", ты начал радостно использовать "принципы ООП" как аргумент в пользу джавовского подхода к классам и интерфейсам
Эта штука описана в Effective Java, это вообще один из самых базовых принципов использования ООП.
но постойте-ка.
Джавовская библиотека классов - это прямо таки клоака антипаттернов проектирования.
Я, конечно, не большой знаток джавовских коллекций, но приведу один пример грубого нарушения принципов объектно-ориентированного дизайна, чуть более сложных, чем наследование и интерфейсы. Есть в джаве такая чудная коллекция, как immutable list, которая реализует интерфейс самого обычного mutable листа (vector'а в терминологии C/C++), но в методах добавления и удаления элементов бросает исключение.
Упс.

To sum up: пример приведен некорректно, так как базируется на неудачной реализации джавовских интерфейсов и классов коллекций, отсутствии в джаве индексаторов и стремления использовать слишком общие интерфейсы там, где это бессмысленно (так как для нас важна именно внутренняя реализация коллекции, если уж мы говорим о таких эзотерических штуках, как связный список, и заменяем один тип коллекции на другой ради оптимизаций).

Jotun 19-03-2017 00:00 0

Tro, Без auto, если изменился тип возвращаемой функции, возникнет ошибка. Ты придёшь в место ошибки и проверишь, ничего ли не поломалось. Даже если не придётся править ничего, кроме типа переменной. С выведением типов оно промолчит, и если используемые методы у нового типа те же самые (а с перегрузкой операторов шанс такого события ещё больше), у нас есть шанс заняться весёлым дебагом.

Если ты говоришь о подмене библиотек в работающем приложении, то с var/auto тоже возникнет ошибка, ведь они compile-time.
Если ты говоришь об обновлении библиотек в ходе разработки, то тут есть два варианта:
1) у нас было выражение типа
var x = GetX();
Разработчики библиотеки заменили тип GetX() на родственный и реализующий, скажем, тот же интерфейс, потому что они сочли, что так будет лучше. В таком случае, и проверять ничего не надо, думаю. Мы полагаемся на внутреннюю реализацию библиотеки. Да и с тем же успехом здесь отработала бы явная типизация, кстати, ведь в выражении
IShit shit = GetShit();
замена возвращаемого класса с BaseShit на DerivedShit или вообще на левый CowShit, реализующий тот же интерфейс, не дала бы ошибки

2) У нас было такое же выражение, и разработчики third-party component заменили тип возвращаемого значения GetX() с X на какой-то вообще левый Y.
Тут в 90% случаев у нас произойдет где-то дальше ошибка компиляции из-за того, что мы использовали что-то, что явно задавало тип x с помощью утиной типизации (например, передавали его как параметр куда-то), но допустим, что этого не произошло.
Что ж. Ты прав. Мы выстрелили себе в ногу.
Но не кажется ли тебе, что это не проблема var, а проблема долбоебов-девелоперов, которые изменили реализацию функции так, что она стала возвращать объект другого типа и из другой иерархии наследования, но имеющий абсолютно такой же набор методов? Серьезно же, это просто дико тупой breaking changes.
Не думаю, кстати, что ты в реальном проекте такое встречал.

Тут я вообще ничего не понял. Про второе я выше описал, что это не так. Про третье - лол, VS не умеет в генерацию кода?
Причем тут генерация кода?

Tro 19-03-2017 00:14 0

Jotun, built-in реализацию методов
А что ещё было делать? Две параллельные вселенные наподобие System.Collections.Generic и System.Collections? Зато появились всякие Map.putIfAbsent(). Везде пишут и предостерегают, что не надо использовать эту фичу, только если вам сильно потребовалось добавить новый метод, а реализаций у библиотеки уже тысячи.

если мы вызвали getFirst ... то наверное же мы его вызвали не просто так
Мы вызвали его случайно. Могли бы спокойно делать get(0), но в подсказках появилось getFirst - почему бы и нет? Этот метод создавался для реализации Deque (спорный момент - реализация двух разных вещей одним классом - но это другой вопрос).

Джавовская библиотека классов - это прямо таки клоака антипаттернов проектирования.
Не спорю. Они даже java.time запилили в 8-й версии, потому что существовавшие до этого стандартные решения были уберужасны.

Tro 19-03-2017 00:22 0

Jotun, Ответ на первую часть: они это назвали надёжностью - я (и ты) сказал, что auto здесь либо ничего не меняет, либо, в 1% случаев, делает хуже. Где здесь надёжность?

Причем тут генерация кода?
Написал выражение > нажал Ctrl+Alt+V > оно само подставило тип и предложило название новой переменной. Я что так вручную тип не пишу, что в ином случае писать var не буду - всё сгенерируется само.

Jotun 19-03-2017 00:23 0

Tro, А что ещё было делать?
"Что еще делать?" - не аргумент.
Писать на шарпе - вот, что делать.

То, что ввиду предыдущих версий джавы не получилось обойтись без грубого нарушения ООП и здравого смысла, никак не отменяет факта этого нарушения.
А ты тут жалуешься, что вместо привычных тебе extends/implements есть только двоеточие.

Мы вызвали его случайно. Могли бы спокойно делать get(0), но в подсказках появилось getFirst - почему бы и нет?
Значит, проблема не в var, а в бездумно кодящем программисте?

Этот метод создавался для реализации Deque (спорный момент - реализация двух разных вещей одним классом - но это другой вопрос).
Ну что же, ты сам подтвердил мою догадку - проблема как обычно в дизайне коллекций Джавы.

Jotun 19-03-2017 00:25 0

Tro, Ответ на первую часть: они это назвали надёжностью - я (и ты) сказал, что auto здесь либо ничего не меняет, либо, в 1% случаев, делает хуже. Где здесь надёжность?
Ммм, но я не говорил, что auto ничего не меняет. Auto делает лучше в тех ситуациях, где нам плевать на изменение типа, так как меняется реализация при том же интерфейсе (т.е. 99% подобных изменений). А про оставшийся процент я уже сказал - если кто-то делает такие изменения, то его надо просто по рукам бить за такое.

Написал выражение > нажал Ctrl+Alt+V > оно само подставило тип и предложило название новой переменной. Я что так вручную тип не пишу, что в ином случае писать var не буду - всё сгенерируется само.
Ничего не понял, на самом деле.

Tro 19-03-2017 00:49 0

Jotun, Писать на шарпе - вот, что делать.
У меня есть Kotlin, в котором полно синтаксических плюшек с полной совместимостью с Java-библиотеками - зачем мне шарп? К тому же у него нет убогой идеологии "давайте быть как Java, но не как Java" - то есть по сути всё оттуда взять, но в мелочах (в основном, оформление кода, которое у C# мне очень не нравится) делать всё наоборот.

никак не отменяет факта этого нарушения.
Вот как наткнусь на diamond problem - так поговорим. Пока что я не вижу поголовного использования этой фичи, так что проблем быть не должно. Альтернативами могли стать статические методы наподобие Collection.getStream(myCollection).filter(...) или параллельный мир новых коллекций (как в C#), но это всё тоже нехорошо.

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

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

Ничего не понял, на самом деле.
У тебя ж по-любому есть решарпер - неужели всё равно всё руками вводишь?

Jotun 19-03-2017 00:57 0

Tro, Даже если в стандартных библиотеках шарпа проблем нет, это не отменят их наличие в сторонних библиотеках, где тоже на многое можно наткнуться. Не будешь ведь их по всем канонам переписывать.
Примеры?

У тебя ж по-любому есть решарпер - неужели всё равно всё руками вводишь?
В 15 студии - да. В 17 - не стоит, потому что в принципе refactoring tools удовлетворяют всем потребностям.


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

Бля, ты вот скажи честно: ты меня троллишь сейчас?
Тебе не нравится ебаное двоеточие вместо extends. Двоеточие, Карл!
А то, что в Джаве смысл интерфейсов потерян напрочь, тебя не смущает, потому что эту фичу, мол, не сильно используют

Альтернативами могли стать статические методы наподобие Collection.getStream(myCollection).filter(...) или параллельный мир новых коллекций (как в C#), но это всё тоже нехорошо.
Ты второй раз уже пишешь про какой-то там "параллельный мир новых коллекций", и у меня возникает дежавю. Второй раз за день джавист рассказывает мне о каких-то реалиях C#, о которых я не знаю.


У меня есть Kotlin, в котором полно синтаксических плюшек с полной совместимостью с Java-библиотеками - зачем мне шарп?
Пиши на Kotlin, я ж ничего не говорю.

К тому же у него нет убогой идеологии "давайте быть как Java, но не как Java" - то есть по сути всё оттуда взять, но в мелочах (в основном, оформление кода, которое у C# мне очень не нравится) делать всё наоборот.
Ты, кажется, живешь в каком-то своем мирке.
Идеология Шарпа году эдак в 2003 действительно была "Давайте быть как Java, но только лучше".
Вот только в последние лет пять C# уже давно перегнал Джаву, и это уже она пиздит фичи из C#.

Tro 19-03-2017 01:06 0

Jotun, Примеры?
Я хз, я не кодил много на шарпе. Могу создать кривую библиотеку (да хоть перевести на C# Java collections) и выложить её - будет как пример.

refactoring tools удовлетворяют всем потребностям.
Разве кроме этого в решарпере ничего нет? Лучше у черепца спросить.

Тебе не нравится ебаное двоеточие вместо extends
Тем, что оно одновременно и extends, и implements.

параллельный мир новых коллекций
Дженерики в C# существуют не с первой версии, насколько я знаю. Как и в Джаве. Их прямое введение теряет совместимость с предыдущим кодом. В C# просто создали новую библиотеку коллекций - с дженериками, в Java же запилили нехорошие raw types, что зато позволило избежать существования двух типов коллекций.

Идеология Шарпа году эдак в 2003 действительно была "Давайте быть как Java, но только лучше".
Я про изначальную идеологию и говорю. Но не думаю, что седьмой шарп отличается больше, чем наполовину.

Jotun 19-03-2017 22:05 0

Tro, Разве кроме этого в решарпере ничего нет? Лучше у черепца спросить.

В 17 студии мне хватает Productivity Power Tools и встроенных возможностей

Тем, что оно одновременно и extends, и implements.
Ещё раз: в Джаве концепция интерфейсов сломана напрочь, а тебя смущает то, что в Шарпе другой синтаксис?
В Плюсах, вон, для интерфейса даже ключевого слова нет по сути (если считать интерфейсом класс, состоящий только из pure virtual methods).
Раз уж на то пошло, я вообще не нашёл языка, где бы ключевые слова для наследования классов и реализации интерфейсов отличались.

Дженерики в C# существуют не с первой версии, насколько я знаю. Как и в Джаве. Их прямое введение теряет совместимость с предыдущим кодом. В C# просто создали новую библиотеку коллекций - с дженериками, в Java же запилили нехорошие raw types, что зато позволило избежать существования двух типов коллекций.
Что плохого в существовании двух типов коллекций?
Это не ломает обратной совместимости. И это не добавляет никаких проблем. А знаешь, почему? Потому что в Шарпе все перешли на generic-коллекции, и не generic я за год работы встретил лишь однажды.
Но ты этого не понимаешь, потому что пользуешься джавой, где на generic-коллекции не перешли повсеместно, потому что они неудачно реализованы. Упс.

Я про изначальную идеологию и говорю. Но не думаю, что седьмой шарп отличается больше, чем наполовину.
Я повторю: в 2017 году не шарп копирует функциональность из Джавы, а наоборот.
Идеология шарпа уже давно абсолютно другая.
Я тебе больше скажу: к тому моменту, когда я начал учить шарп, это уже было так, поэтому про эти ваши "Как в Джаве, только наоборот" я слышу только из рассказов Джавистов, ностальгирующих по былым временам, когда Джава реально была впереди по развитию фич языка.

Кстати, как ни смешно, но плюсы сейчас ушли в развитии, пожалуй, дальше Джавы, хоть они и древние как мир.

Tro 19-03-2017 22:12 +1

Jotun, Раз уж на то пошло, я вообще не нашёл языка, где бы ключевые слова для наследования классов и реализации интерфейсов отличались.
А много где интерфейсы вообще существуют?

на generic-коллекции не перешли повсеместно
Я вообще не припомню, чтобы встречал не-дженерик коллекцию. Разве что в каком-то классе, написанном во времена Java 1-2.

Я повторю: в 2017 году не шарп копирует функциональность из Джавы, а наоборот
Чего ты так сильно бомбишь, что второй раз одно и то же пишешь? Я не спорю с этим утверждением, я про изначальную концепцию. И бесит меня именно она - почему нельзя было сделать вообще всё как в Джаве (даже стиль), просто добавляя плюшки и убирая недостатки, связанные с обратной совместимостью (типа raw types)?

BerkutOi 19-03-2017 22:28 0

Jotun, Но ты этого не понимаешь, потому что пользуешься джавой, где на generic-коллекции не перешли повсеместно, потому что они неудачно реализованы. Упс.

Если честно, то когда я начинал учить джаву, я даже не знал что можно использовать коллекции с raw types, первые несколько лет для меня существовали только generic коллекции, это еще во времена шестой джавы было, и только иногда в каких-то старых книгах или примерах можно было найти их использования, в реальном коде я ниразу не видел не generic коллекции

Jotun 19-03-2017 23:06 0

Tro, И бесит меня именно она - почему нельзя было сделать вообще всё как в Джаве (даже стиль), просто добавляя плюшки и убирая недостатки, связанные с обратной совместимостью (типа raw types)?
Не знаю. Чтобы Джависты страдали?

Чего ты так сильно бомбишь, что второй раз одно и то же пишешь?
Потому что с первого раза до тебя не дошло.
C# из начала двухтысячных - вторичный по отношению к C++ и Java язык, работающий только на платформах Microsoft.
C# в 2017 году - кроссплатформенный передовой язык, а вот Java порой использует концепцию "Сделать как в шарпе, только чтобы backward compatibility не отвалить случайно".


Я вообще не припомню, чтобы встречал не-дженерик коллекцию. Разве что в каком-то классе, написанном во времена Java 1-2.

Ну хз-хз. В тех местах, где я соприкасаюсь с Джавой, я встречаю non-generic коллекции.
Но если ты действительно и в джаве используешь обобщенные коллекции вместо обычных, то что тебя смущает в решении, принятом в шарпе?

А много где интерфейсы вообще существуют?
Нет. И поэтому мне вдвойне непонятно, почему у тебя бомбит от двоеточия.

Tro 20-03-2017 01:03 0

Jotun, Потому что с первого раза до тебя не дошло
Высунь шарп из глаз и перечитай мой ответ на первый раз. Ты трижды доносишь свою мысль - и опять не в тему, мы не об этом.

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

почему у тебя бомбит от двоеточия
Ну у Беркута ещё бомбит. Причина примерно та же, что и причина не любить наркоманские перловские функции, где необязательно скобки писать (даже когда есть аргументы). Да, при желании оно читаемо, но требуется время, чтоб отделить одно от другого. При чтении мне хочется сразу видеть (и раздельно от остального), от чего наследуется данный класс. Интерфейсы - это уже опционально.

Ram 20-03-2017 01:08 0

paradoxs, Фу. Ну и гейский у вас разговор.

Jotun 20-03-2017 01:20 0

Tro, При чтении мне хочется сразу видеть (и раздельно от остального), от чего наследуется данный класс. Интерфейсы - это уже опционально.
Ну, класс первый. Потом интерфейсы. Так что базовый класс сразу виден.

Высунь шарп из глаз и перечитай мой ответ на первый раз. Ты трижды доносишь свою мысль - и опять не в тему, мы не об этом.
R u kidding me?
Я третий раз тебе говорю, что ты сморозил хуйню, когда написал
К тому же у него нет убогой идеологии "давайте быть как Java, но не как Java" - то есть по сути всё оттуда взять, но в мелочах (в основном, оформление кода, которое у C# мне очень не нравится) делать всё наоборот.

BerkutOi 20-03-2017 01:41 +1

Jotun, Ну, класс первый. Потом интерфейсы. Так что базовый класс сразу виден.

а если нет базового класса то различить только по букве I в названии интерфейса? кстати на какой хер она там?

Tro 20-03-2017 01:47 0

Jotun, Ну, класс первый. Потом интерфейсы. Так что базовый класс сразу виден.
Если они не вразброс - уже лучше, даже хорошо.

R u kidding me?
Быть джавой - это шарповая изначальная концепция, и не надо это отрицать. Если я сяду сейчас кодить на шарпе, то увижу те же принципы, те же модификаторы, те же коллекции. Код между этими языками переводится почти что 1-в-1. Да, уже лет 10 как из джавы особо нечего брать - разве что в седьмом шарпе оттуда взяли запись числа в виде 234_344_344. Но изначальную концепцию это не меняет, и поменять её невозможно.
Сама джава из плюсов многое взяла - плохо, что ли? Речь не об этом, а о том, что не понимаю, в чём была проблема оставить привычные и хорошие мелочи типа отсутствия перевода строки перед {, маленькой первой буквы у методов, тот же extends/implements, package/import вместо namespace/using. Зачем нужны были все эти выделывания? Чтобы сделать вид, что мы из джавы ничего не брали и у нас всё своё?
По ходу написания придумываю ответ, но вдруг тебе будет ещё что добавить. Тогда Sun наезжала на Microsoft по поводу J# и MSJVM, мб поэтому старались сделать всё по-другому - что это типа другой язык.

BerkutOi 20-03-2017 01:49 0

Tro, кстати интересное предположение, и может действительно хотели сделать язык более похожим на плюсы

Jotun 20-03-2017 21:43 0

BerkutOi, кстати на какой хер она там?
Чтобы по названию сразу видеть, класс это или интерфейс.
Это, кстати, мне сильно не хватает в Джаве, когда я работаю с незнакомым API.
И, да, по ней сразу видно

BerkutOi 20-03-2017 21:46 0

Jotun, но ведь сразу видно по слову implements что дальше идут интерфейсы, а самом его коде написано, в дереве классов иконка в идее покажет что это интерфейс или класс

Jotun 20-03-2017 21:59 0

Tro, Если они не вразброс - уже лучше, даже хорошо.

Так они не могут быть вразброс, лол. Ошибка компиляции будет.



Быть джавой - это шарповая изначальная концепция, и не надо это отрицать. Если я сяду сейчас кодить на шарпе, то увижу те же принципы, те же модификаторы, те же коллекции. Код между этими языками переводится почти что 1-в-1. Да, уже лет 10 как из джавы особо нечего брать - разве что в седьмом шарпе оттуда взяли запись числа в виде 234_344_344. Но изначальную концепцию это не меняет, и поменять её невозможно.

Да ты же издеваешься.
Смотри.
Быть джавой - это шарповая изначальная концепция, и не надо это отрицать.
Ты абсолютно прав.
Если я сяду сейчас кодить на шарпе, то увижу те же принципы, те же модификаторы, те же коллекции. Код между этими языками переводится почти что 1-в-1. Да, уже лет 10 как из джавы особо нечего брать - разве что в седьмом шарпе оттуда взяли запись числа в виде 234_344_344.
Ты абсолютно не прав.

Шарп в самой первой версии был скопирован с Java и C++, но говорить сегодня об этом нет смысла, потому что это абсолютно разные языки, и именно Шарп ушёл вперед, а не Джава.
И код между этими языками не переводится 1-в-1, кстати. Перевести код между современными C# и Java не проще, чем между C# и C++.
Вот о чем я.
Так что, подводя итог:
- да, ты прав, что такой была концепция шарпа в момент его инициализации.
- говорить об этом бессмысленно, так как 80% современных .Net-девелоперов начали девелопить в те времена, когда ситуация была прямо противоположной.

Прежде чем ты начнешь писать ответ в духе "Ололо, ты тупой жотун, я тебе не о том толкую", давай посмотрим на две твоих цитаты:
К тому же у него нет убогой идеологии "давайте быть как Java, но не как Java" - то есть по сути всё оттуда взять, но в мелочах (в основном, оформление кода, которое у C# мне очень не нравится) делать всё наоборот.
По этой цитате: я не говорю, что у шарпа не было такой идеологии, как ты почему-то воспринимаешь мои слова. Я говорю, что у шарпа нет такой идеологии (причем уже много лет). Вот в чем суть.

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

Сама джава из плюсов многое взяла - плохо, что ли? Речь не об этом, а о том, что не понимаю, в чём была проблема оставить привычные и хорошие мелочи типа отсутствия перевода строки перед {, маленькой первой буквы у методов, тот же extends/implements, package/import вместо namespace/using. Зачем нужны были все эти выделывания? Чтобы сделать вид, что мы из джавы ничего не брали и у нас всё своё?
Единственная проблема в твоем утверждении - слово "хорошие".
Суть в том, что эти мелочи субъективно хорошие.
Вот, например, возьмем перенос строки после сигнатуры метода: я в последнее время поровну пишу на шарпе и на плюсах (в которых перенос такой же как и в джаве), и мне намного сложнее читать код в C++-конвенции, поскольку границы скоупа видны намного хуже.
Или там package/import и namespace/using. Начнем с того, что ты ошибаешься, думая, что это одно и то же, потому что эти вещи всё же слегка отличаются. Но вообще главное другое: а почему ты решила, что вариант package/import хорош? Как по мне, например, using семантически лучше, потому что мы не импортируем код из файла с кодом, как это было во времена C (читай: не копируем к нам в файл код), а используем какие-то сущности.
А с package ты вообще не прав, потому что в плюсах, например, namespace как раз таки. Так что тут уже Java выделилась.
В общем, суть в том, что отличия шарпа от джавы - это не недостатки шарпа. Это просто отличия.

Jotun 20-03-2017 22:02 0

BerkutOi, Где видно-то? Я здесь один нахуй


Рассказываю реальный юзкейс из жизни.
Я читаю следующий код в ответах на StackOverFlow, чтобы в Xamarin перевести его на шарп:
A a;
...
a = new B();

Что такое A? Класс или интерфейс?

BerkutOi 20-03-2017 22:09 0

Jotun, но ведь это не юзкейс из жизни, зачем тебе такой код переводить на шарп?

Jotun 20-03-2017 22:10 0

BerkutOi, Это юзкейс из жизни.
Просто я заменил два названия классов из Андроида на A и B, чтобы не вникать в детали.

BerkutOi 20-03-2017 22:11 0

Jotun, мне кажется или ты сам говорил что андроид это не джава?

Jotun 20-03-2017 22:16 0

BerkutOi, пруфы будут?

Впрочем, на самом деле подобный разрыв шаблона я испытал впервые ещё на второй неделе копания в Джаве, когда попробовал создать объект List'а.

BerkutOi 20-03-2017 23:49 0

Jotun, видимо мне показалось, хз, сори

Jotun 21-03-2017 00:13 +1

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

cherepets 21-03-2017 00:42 0

Jotun, Потому что им некогда писать код - нужно 100500 xmlей накидать на все случаи жизни.

Tro 21-03-2017 13:57 0

Jotun, Да ты же издеваешься.
Мне так надоело сраться над той ерундой, тем более что ты придрался не к основной мысли того сообщения (хз, уловил ли ты её). Ок, ты прав, я изначально не уточнил.

C++-конвенции
Её вроде как нет (де-факто) - там корпоративные стандарты: где-то так, где-то по-другому, где-то вообще вот_так.

и мне намного сложнее читать код в C++-конвенции, поскольку границы скоупа видны намного хуже.
Хз, как по мне - оно слишком удлиняет код. Трёх выделяющих элементов - отдельно стоящей }, табуляции и прорисованных линий у IDE - вполне достаточно. Чётвёртый уже лишний.

cherepets 21-03-2017 15:03 0

Tro, Полоски в VS добавили ток в этом году, да и честно говоря они скорее захламляют окно редактора, чем помогают определить скоуп.

В любом случае глупо обсуждать переносы строк как отличие между с C# и Java. Например, Xamarin Studio по дефолту ставит { на той же строке в C#.

Лично мне удобнее на отдельной строке. Надо, например, временно заменить реализацию на некоторое хардкодное значение для теста: выделяешь все строки кроме сигнатуры и добавляешь к ней => 5; или типо того.

Jotun 21-03-2017 22:09 0

Tro, Её вроде как нет (де-факто) - там корпоративные стандарты: где-то так, где-то по-другому, где-то вообще вот_так.
Есть гайдлайны от Страуструпа и есть гайдлайны от Microsoft по Visual C++.
Но, да, прямо таки стандарта форматирования кода нет.
Это, кстати, плохо, пожалуй, потому что даже в C# при подключении к какому-то проекту приходится привыкать к каким-то особенностям кода в нем, а уж в C++ вообще жесть

Трёх выделяющих элементов - отдельно стоящей }, табуляции и прорисованных линий у IDE - вполне достаточно. Чётвёртый уже лишний.
} определяет только конец скоупа, а по табам не всегда удобно увидеть начало скоупа.
А линии мне не нравятся, я их вообще отключил.

Мне так надоело сраться над той ерундой, тем более что ты придрался не к основной мысли того сообщения (хз, уловил ли ты её). Ок, ты прав, я изначально не уточнил.
> начать спорить о каком-то аспекте, а потмо назвать ерундой.
Беспроигрышный вариант

04-10-2010 15:27 0

Ruby рулит! )

3 комментария
Tro 22-04-2011 23:02 0

greg, Виндузятники неадекватны - минус не за что.

opera.rulez 22-04-2011 23:06 +1

Tro, А какое отношение имеет Ruby к C#?

Tro 22-04-2011 23:18 0

opera.rulez, Нейтралам некуда писать. Видимо, эта колонка была пустой.

08-01-2011 01:22 0

Нахуй эту джаву которая жрет столько ресурсов. Сложные проекты на ней хер спроектируешь.

10 комментариев
NightmareZ 06-02-2012 18:35 0

Pr00f, Может просто у тебя руки из жопы?

cherepets 06-02-2012 22:02 0

NightmareZ, Не факт.

На работе много пользуюсь HP ServiceDesk. В ней в правом нижнем углу выведен мониторинг потребляемого хипа и кнопочка для system.gc();

Поработал какое-то время, занято 100мб. Жму кнопку - 70, еще раз 50, 40, 35 и около 30 тормозится. Пытаемся открыть информацию по конфигурационной единице и получаем OutOfMemory.

Возникают вопросы:
- почему ява не очищает сразу весь мусор, а оставляет ~60% на потом?
- почему? почему, блять, оно при занятых 30мб вылетает с нехваткой памяти? как вообще это понимать?

NightmareZ 06-02-2012 22:07 0

cherepets, Ну, например, кривой софт.

cherepets 06-02-2012 22:22 0

NightmareZ, Кривости софта тут нет. Все же вызываемые функции доподлинно известны и явно должны работать не так.

NightmareZ 06-02-2012 23:40 0

cherepets, Ты уверен, что нет? Тебя научить делать утечки памяти в языках со сборщиком мусора? :-D

У меня таких проблем, как ты описываешь, нет.

cherepets 06-02-2012 23:54 0

NightmareZ, Значит, в НР работают индусы =)

NightmareZ 07-02-2012 00:24 0

cherepets, Запросто.

Tro 18-03-2017 20:43 0

cherepets, почему ява не очищает сразу весь мусор, а оставляет ~60% на потом?
Там есть minor и major garbage collections. Если чистить каждый раз всё, должны быть адские глюки на каждой очистке.
Какую именно сборку мусора вызывает System.gc() - хз, виртуальная машина вообще имеет право игнорировать этот вызов.

Jotun 18-03-2017 22:13 0

cherepets, - почему ява не очищает сразу весь мусор, а оставляет ~60% на потом?
GC в C# тоже работает с поколениями, если что

Slimmer 18-03-2017 22:40 0

cherepets, кнопочка для system.gc()
уверен, не от большого ума там эта кнопочка появилась
почему? почему, блять, оно при занятых 30мб вылетает с нехваткой памяти? как вообще это понимать?
спишем на молодость?;-)

31-07-2011 16:16 0

В последний раз когда катался на Яве наебнулся.

1 комментарий
Tro 31-07-2011 18:59 0

iPoWhoY, Не думаю, что ты катался на Яве. Надо винить волны Индийского/Тихого океана.

31-07-2011 22:31 0

Побуду на этот раз здесь, ибо:
1) Скорость работы
2) Мультитач и еще некоторые довольно не поплуряные хреновины
3) Да, пусть винда и дальше будет "основной" системой, а остальные пусть выкручиваются как хотят.
Наличие одной систему у всех решает довольно много проблем.
(хотя сам я сижу на федоре)

0 комментариев
01-08-2011 19:24 0

Мне кажется, что это хуйня, а не сравнение. Ах да, минусну-ка я этот вар, а то минусомет застоялся.

0 комментариев
07-02-2012 09:36 +1

Слева уже Sun пора заменить на Oracle.
И если Sun хотя бы развивал яву, то последние 2 года не происходит ни каких изменений к лучшему и народ потихоньку разходится кто куда.
Корпоративный сектор и разнородные формошлепы в основном находят приют в .Net, игроделы - в Unity или XNA.

1 комментарий
danpetruk 27-12-2013 21:21 0

cherepets, Нихрена, от oracle даже больше пользы

08-02-2012 20:35 0

И то и другое - высокоуровневое отборное булькающее.
В нейтрал, тапками не кидать

1 комментарий
danpetruk 27-12-2013 21:21 +1

reckount, Жизнь коротка, что писать на говне вроде C