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

Java
55
Нейтральная
сторона
7
C#
47
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, Я всё ещё, блять, слушаю.

07-01-2011 23:51 0

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

0 комментариев
06-02-2012 23:46 0

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

30 комментариев
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 (без установки). Кстати, у МС есть аналог этой вещи?
не совместимо только то для чего нет железа. Например, поворот акселерометром в браузере, конечно же не будет работать
Силверлайт же там не в браузере... причём тут он?

cherepets 08-02-2012 23:11 0

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

Tro 08-02-2012 23:40 0

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

cherepets 09-02-2012 00:19 0

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

cherepets 09-02-2012 07:36 0

Office 365 != Office Web App.

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

cherepets 09-02-2012 16:42 0

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

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

danpetruk 27-12-2013 21:17 0

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

cherepets 27-12-2013 21:21 0

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

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.

46 комментариев
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

Tro 17-03-2017 23:26 +1

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

Tro 18-03-2017 00:24 +1

С наличием 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 рулит! )

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

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

Tro 22-04-2011 23:18 0

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

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