Привет всем. Начну с того, что занимаюсь программированием около 2 лет и чисто как хобби. Но около 2 месяцев назад начал лезть в мир и дебри языка Java и у меня возник вопрос. Джава язык один из самых распространенных и его знают практически все программисты, но почему именно Джава, неужели он хуже C++ или С для PC? И еще, если он такой распространенный, то на какую платформу пишут Джава программисты чащу всего?
P.S. 2 месяца Java не много, поэтому и лезут такие вопросы.
но почему именно Джава, неужели он хужемне кажется, или здесь противоречие ?
А вообще джава как язык — это в принципе, просто неплохой язык.
Но кроме языка — это еще и платформа под любое железо — раз, и вагон с тележкой хорошо продуманных API и библиотек, вылизанных по процессу JCP — два. Именно эти два — секрет успеха.
А в С++ до сих пор каждый изобретает свой string.
неужели он хуже C++ или С для PC?— вопрос поставлен некорректно, у каждого языка, в большинстве своём, своя сфера применения.
на какую платформу пишут Джава программисты чащу всего— понятие платформы в случае с Java(как языка) как таковое отсутствует(хотя есть нюансы с поддержкой специфического API, например Swing никак не подружишь с Android’ом ибо у оного свой UI Framework). Специфическим для каждой платформы является лишь реализация виртуальной машины.
его знают практически все программистыЯ не знаю и как то обхожусь без этой самой явы
Ммм... а на чем кодишь? В какой сфере работаешь? Какой опыт?
Старый и добрый Си, видеобработка, более 15 лет
Думаю одним из основных преимуществ Java над остальными языками была и есть стандартная библиотека. Из коробки и бесплатно мы получаем классы для работы с файловой системой (а ну ка сделай File.list() в С++), сетью (IPv4 + IPv6 без особых отличий в использовании), коллекциями, ZIP, XML, просто офигенная библиотека для криптографии, unicode строки, *нужное добавить*. Т.е. нам не надо разбираться в миллионе сторонних библиотек для решения стандартных задач как это обычно происходит в С, C++, Delphi etc.
А забыл еще SSL, HTTP client.
(а ну ка сделай File.list() в С++)Это что, всерьез? )))
Если в nix, man ls, и затем pipe,pipe,pipe
упаришься в Яве всё это реализовать, не?
Насчет скорости, то не всякий пользователь компилятора Си догонит батник для виртуальной машины winXP, где крутится ручной ассемблерный код команд cmd.exe. В nix да, с этим похуже, от рождения...
Оставлю без комментария....
Прочтите на досуге, Knuth vs McIllroy.
но почему именно Джава, неужели он хуже C++ или С для PC?Для десктопов лучше C# если виндовый десктоп, или тот же QT или С + GTK
да ни чем...
а про JavaFX опять забыли.
И вообще, холливарить Java vs .NET уже давно не модно, щас пророчить безграничное светлое будущее стэку HTML5 — более трендовый срачь, хотя тоже, былой запал начал иссякать ;)
Можно ли писать приложения под windows phone на Java
Эти JVM под различные операционки, на чем они пишутся?
Можно ли их написать на java?
То есть все эти вещи пишутся не на Java? И ява нуждается в каком то другом ЯП для своего существования и развития, nicht war?
Можно ли писать приложения под windows phone на Java
Конечно нетПод виндовс фон C#. На яве пишутся под андроид
Нуждается. Она написана на С++. И?
Мальчик, ты лучше не пиши на форумах, ты лучше читай. Вот будет 20 лет, тогда можешь начинать, по чуть-чуть.
У тебя в тексте — логическая ошибка, не говоря уже о том, что ответы на твои вопросы находятся поиском (но тебе этого пока не понять).
Дима или очередной мыслитель- любитель готовенького (пережеванного и в ротик поданного )
либо вообще забыл про свой топик.
А мнения собрались интересные, может даже срач получится; все в сборе))
Можете попробовать почитать
Gosling. «The Java™ Language Environment». A White Paper
Это автор языка рассказывает что за язык они сделали. В документе явное указание на отличия от C++ (в основном упрощения) и причины.
неужели он хуже C++ или С для PCЛучше для бизнес-проектов.
то на какую платформуЛибо J2EE — все равно какая ось, какой проц, так что понятие платформы — отсутствует.
Не троллинга ради, но категорически интересно. Вот есть такой факт, что в Java были намеренно исключены беззнаковые целые. Нам на практике это немного ударило (резкое усложнение маршаллинга для целевых протоколов). Одним из преимуществ C# считается наличие беззнаковых. Гослинг никак не мотивирует отказ от них. Вы можете прокомментировать со своей стороны, какие могли быть мотивы подобного архитектурного решения, и как Вы лично оцениваете эти мотивы?
намеренно исключены беззнаковые целые.Таки char есть.
Сталкивался на J2ME — были нужны числа с фиксированной точкой 24+8 для 3Д расчетов.
Писал
MyMath.add(int, int):int
MyMath.mul(int, int):int
...
т.е. все сложности с отсутствием чисел с фиксированной точкой спрятал в MyMath. Думаю, так же можно делать и с беззнаковыми. Отсутствие типа и операторов (+, -, *, /) можно компенсировать другим типом (short, int, long — подбирай кол-во байт по потребности) и собственными библиотечными методами.
> Думаю, так же можно делать и с беззнаковыми.
Да можно, конечно, но изврат дикий получается...
Думаю, таким образом авторы
— упростили жизнь ВСЕМ новичкам
за счет
— усложнения жизни НЕКОТОРЫМ middle/senior
Для захвата мира — годный ход. :)
Таки лучше иметь платформу которая создает десятки миллионов revenue, чем иметь беззнаковые типы.
А как второе мешает первому?
Язык с большим количеством тонкостей порождает высокий порог входа (до production нужно практиковаться 3 месяца или 9 — это существенно), что приводит к перетеканию мелких компаний, учебных заведений, самоучек — на другой язык/платформу.
Наверно, мне мешает понять это мой background (как эта путет па рюски?), который даёт, что беззнаковые тривиально понятны и привычны. Здесь предпочту поверить на слово человеку с опытом обучения языку (по крайней мере пока другой такой же не возразит;))
Но мой реальный опыт с Java, а именно, с перепиской одного из компонентов с Python показал, что основные грабли лежат в перегруппировке сущностей по объектам, которая усложняется странными явовскими ограничениями типа необходимости класса для любой отдельной логической сущности или правила, что публичный класс должен лежать в отдельном файле — что превращает код в скопище одноэкранных мелочей и банально мешает понимать всё получившееся. По сравнению с этим возможная проблема от беззнаковых выглядит ничтожной.
возможно, Гослинг полагался на интуицию. она его не подвела.
код в скопище одноэкранных мелочейТак все и задумано, бро:)
публичный класс должен лежать в отдельном файлеА не задумывался о пользе непубличных, или публичных вложенных классов?
непубличных
Задумывался. Именно так и начинал делать. Но пришлось вытеснить в публичные.
или публичных вложенных классов
Вот это не пробовал. Насколько оно путано в использовании?
Вот это не пробовал. Насколько оно путано в использовании?Ну ты расскажи какие именно тебя сценарии смущают, разберемся.
И уже ПОСЛЕ захвата мира частично добавить unsigned в Java 8.
Хм... это надо было делать в 2000, а не в 2013.
Оракул так пропах Индией, что немного боязно.
Как бы они не скатили Джаву в УГ.
Ну вот джаву там пишет куча бледнолицых, в том числе русских.
это радует, хотя среди наших тоже говнарей хватает.
бодишопинг располагает.
Скажем как вычитать беззнаковые? Что получается при вычитании двух беззнаковых двухбайтных?
А что получается при сложении, например, двух двухбайтных по 20000?
Это одна и та же проблема выхода за домен и решение должно быть одинаковое по сути. Например, выбор между игнорированием и генерацией исключения.
С int проще (знаковый 4х байтный) — складывай, вычитай, умножай, дели если что, данные сами потеряются.
Что такое «сами потеряются», я не понял. Но от переполнения int не защищает. Вот, например, надо работать со счётчиками (SNMP-типа, IB-типа или другими аналогичными), по 8 байт. И работа с ними превращается в сплошной закат солнца вручную — мы эмулируем арифметику за счёт работы с её частями. Выглядит это ужасно.
Да переполнение есть.
Я имел в виду, что
int i0 = 100;
int i1 = 50;
int i2 = i0 — i1;
компилируется. Переполнение происходит при выходе за границы домена, а это [-2B, +2B] — если часто подходишь к границе — бери long.
А у беззнаковых не просто есть граница домена в 0 (т.е. 5 пальцев — это уже близко к границе домена), но и происходит расширение типа до знакового при любом вычитании (я говорю про chat в java, не знаю как у других).
Совсем начинающим тяжеловато, скажем, воспринимается что:
1) byte b = 0; b = b + 1; // не компилируется
2) byte b = 0; b++; // компилируется
Это мелочь, но такие расширения типа — повышают порог входа новичкам.
но и происходит расширение типа до знакового при любом вычитании (я говорю про chat в java, не знаю как у других).
Вот это расширение и есть полная глупость при работе с данными. Для современного уровня все конверсии между знаковым и беззнаковым (кроме, разве что, констант) должны быть явными. А выражение типа b+1 должно быть или b+1u, или с автоматическим опознанием нужного типа для константы.
(C совершает ту же глупость, но в обратном направлении — при двух операндах, где один беззнаковый, второй преобразуется в беззнаковый.)
То есть тут нет никакой проблемы с порогом в самой по себе беззнаковой арифметике — если нет описанных Вами явных диверсий.
Что такое «5 пальцев», я не понял. Видимо, это идиома какого-то эмпирического метода защиты от переполнений. Но я твёрдо предпочитаю не использовать такую защиту, которую слишком легко проломить не заметив, а использовать в ключевых местах что-то вроде C# «checked» (извините уж за сравнение с конкурентом, но оно само напросилось).
Вот, например, надо работать со счётчиками (SNMP-типа, IB-типа или другими аналогичными), по 8 байт. И работа с ними превращается в сплошной закат солнца вручную — мы эмулируем арифметику за счёт работы с её частями. Выглядит это ужасно.Язык, по замыслу, должен был стать языком высокого уровня, но оказался настолько же мелковат, как и Си++. Но не настолько, как Ада и Си++, в которых можно и драйвер к оборудованию написать. Зато настолько, что отрезал самую фундаментальную часть — позиционную байтовую арифметику.
Этот отказ от позиционной в байтах арифметики выглядит невежеством.
Для адептов C++ сразу хочу уточнить, что
Нет кучи мелких бестолковых проблем типа арифметики указателей или разного размера int на разных платформахтолько для бизнес-целей.
Эту нишу сейчас отъедают D, Go, Rust и ещё десяток аналогов.
Наибольшая вероятность что вы все-таки осилите решить вашу задачу по сравнению с другими языками. «Решабельность» ©
Чому Джава? Ну, наприкінці
1) вперше з’явився garbage collection, протікання пам’яті перейшло на якісно новий рівень.
2) безпека програм, неможливість зробити на рівному місці buffer/stack overflow.
3) мова сама по собі спартанська, вчиться легко; як наслідок, легко здавати на аутсорс в Індію, втім, ма́ла відносно приємні на той час нововведення, наприклад, виключення.
4) було багато шуму з нічого навколо ООП у
5) вперше в менйстримі з’явилась справжня і легка кросплатформність (С++ разом із С — це кросплатформні асемблери). Пітон і Перл тоді були «забавкою», про Рубі знали три з половиною хіккі.
6) саме тоді підхід «кожний байт дорогоцінний!» замінився на «закон Мура наше все», залізо стало дешевше, ніж робота програміста.
Зараз же ці причини поступаються іншим:
1) накопичений запас відточених бібліотек і фреймворків
2) загальна репутація екосистеми як дуже надійної для ентерпрайзу
3) кількість вкладених зусиль у JVM, її JIT, профайлинг і так далі.
При цьому всьому особисто мені Джава не подобається, але Scala/Clojure примушують примиритись із JVM.
вперше з’явився garbage collectionХочу заметить что в BASIC, perl, common lisp был GC еще до появления Java.
мова сама по собі спартанська, вчиться легко; як наслідок, легко здавати на аутсорс в Індію, втім, ма́ла відносно приємні на той час нововведення, наприклад, виключенняПо сравеннию с С++ или Haskell, да. После С++ кстати очень легко было выучить джаву.
да, правильніше було б «промислові програмісти вперше дізнались, що таке garbage collection», він перестав бути академічною темою і чимось, що асоцієються із пекельно повільними (як тоді здавалось) інтерпретаторами ліспів. Коротше, об’єкти із Smalltalk і збирання сміття із ліспів пішли в маси.
Хочу заметить что в BASIC, perl, common lisp был GC еще до появления Java.
Начну с LISP. Не Common LISP, это только одна из реализаций, а все LISP, включая Scheme и несколько других более экзотических веток, в принципе не могут обойтись без GC за счёт конструкции языка. То же самое касается Prolog (ещё
Далее, Perl есть 5 и 6 (которого, считаем, нет). В Perl5 нет GC при его обычном выполнении, несмотря на все рекламные агитки. При обычной работе интерпретатора там работает только подсчёт ссылок. GC включается только между циклами вызова интерпретации кода, что может быть достигнуто только в embedded perl, но не при standalone (/usr/bin/perl). Соответственно, до завершения такого цикла всё с циклическими ссылками «творчески» игнорируется рантаймом. Такого упрощения нет в аналогах (как минимум Python и Ruby имеют полноценный GC).
Упоминая Basic, надо указывать конкретную версию. Для дообъектных версий про GC говорить не приходится. Объектные же были резко ограничены в авторстве (считаем, одна MS) и применении (за пределами Office оно было неизвестно).
Так что Java действительно стала первым широко распространённым языком общего назначения с GC. Разумеется, это не так, как предыдущий комментатор сказал, что она была вообще первой; но ширнармассы (tm) узнали про GC только начиная с Явы. И Ваше замечание верно в общем принципе, но страдает в фактах.
Упоминая Basic, надо указывать конкретную версию. Для дообъектных версий про GC говорить не приходится. Объектные же были резко ограничены в авторстве (считаем, одна MS) и применении (за пределами Office оно было неизвестно).
В «объектную эру» у MS существовало 3 ипостаси: полноценный Visual Basic, встроенный в Офис Visual Basic for Applications (VBA) и совсем урезанный VBScript.
Но ни в одной из них не было сборщика мусора. Был подсчет ссылок, точно такой же, как и в COM (по сути, любой объект в Visual Basic / VBScript был, одновременно, и COM-объектом)
Более того, на полной версии Visual Basic до появления .NET писали довольно много бизнес-приложений, никак не связанных с MS Office — и не только десктопных, но и бизнес-логику для Web-приложений: благо, VB хорошо «дружил» с МСовским middleware COM+ (он же, в «девичестве» — Microsoft Distributed Transaction Coordinator)
неможливість зробити на рівному місці buffer/stack overflow.Легко. Две строчки кода
Это вроде не переполнение буфера или стека
Ну это сильно разные темы. К тому же по твоей ссылке прямо написано что проблема там возникает не из-за джавы, а из за конретного класса, который сам пытается менеджить память думая что он эффективнее джавы.
там проблема как раз из-за того что не освобождается память.
класс можно любой туда подставить.
это задокументированные грабли Джавы.
Лол, ну да, если держать ссылку на обьект, то он не удалится, это задокументированная возможность джавы.
Васисуалий Лоханкин
anonymous
Усачев Олег
anonymous
Vsevolod Ievgiienko
Vsevolod Ievgiienko
Кирилл Нечаев
Viacheslav
reality_hacker
artificiatum
Oleksandr Kolosov
Viacheslav
Oleksandr Kolosov
Igor Petruk
Sandro Zakusilov
Dr Alban
Ivan Golovach
Valentin Nechayev
Ivan Golovach
Ivan Pomidorov
Dr Alban
Igor Petruk
Dmytro Sirenko
Dmytro Sirenko
Dmytro Lapshyn
public class Example {
public static void main(String[] args){
getStackOverflow();
}
static int getStackOverflow(){
int a = 5;
return getStackOverflow();
}
}
StackOverflowError
глубокой рекурсией можно не только Джаву положить.
Там же приклад memory leak, про які я і писав, що вони перешли на новий рівень.
А приклад buffer overflow можна?
а какой эксепшн в Джаве соответствует buffer overflow ?
Integer overflow устроит?
www.mkyong.com/...erflow-careful
Мне кажется речь шла о другом оверфлоу, типа когда в Ц++ пишешь в массив без bound чека можешь переписать какую нибудь переменную, и потом это очень непросто отловить. В джаве такого не бывает.
Чи можна за допомогою запису в масив перезаписати іншу змінну, яка до цього масива відношення не має? Це досить часто відбувається в Сі.
по причине переполнения в описанном выше примере портится не соседнее значение, а текущее.
без эксепшнов. тоже отловить непросто.
Я просто отставлю это здесь.
Уже благодаря одной только сборке мусора Java намного лучше для сложных приложений. Можно написать на C или C++ супер-эффективную масштабируемую систему, но на это уйдет в 10 раз больше времени. Пусть она потом работает в несколько раз быстрее и на слабом железе, но никто не хочет ждать 10 лет, если то же самое можно написать на Java за год и купить сервер помощнее. Железо теперь стоит копейки. Так что ничего личного, только бизнес.
Сборщик мусора никак не влияет на скорость разработки. Это стереотип, что C++ сложен из-за всех этих указателей и памяти.
В C++ очень мало стнадардных фреймворков, которые дают полуготовые решения. To, что стандартное (стандартная библиотека) или претендует (как-то boost) по природе своей уебищно. Остается разрозненная хрень, типа QT, Poco, и т. д. Но это никак не конкуренция Java платформе.
Возможно, ситуация в C++ изменилась с тех пор, как я на нем писал. Помнится, самой большой головной болью были memory leaks. На их поиск и отладку уходила пропасть времени.
Зараз є valgrind та shared_ptr<>, але наскільки це змінило ситуацію, неясно.
Умные указатели давно появились в бусте. auto_ptr вроде с 2003 уже в стандарте STL был.
Умные указатели убивают производительность до такой степени что непонятно зачем ц++ становится нужен. Тем более они не спасают в случаях где джвм отлично справляется, например в случае циклических ссылок.
интересно, а как может обычный смарт пойнтер на основе счетчика ссылок значительно влиять на производительность? операции сложения/вычитания стали слишком дорогими?
Если сравнивать с джава, то там и этого делать не надо, не нужно подсчитывать ссылки. Но к.м.к. серьезный контрибьюшн в деградацию делает многопоточность, т.е. с умными указателями на каждое присвоение программа должна преодолевать memory barrier и ставить всякие локи, что бы избежать race condition для счетчиков, а в джаве все делается в кеше процессора, что в
Как известно, для среды, где распределение памяти управляется рантаймом, есть две базовые стратегии опознания ненужных объектов — подсчёт ссылок (по уходу в 0) и полный GC. Подсчёт ссылок не ловит циклические зависимости, но сильно дешевле при малых объёмах данных. Проводились исследования его цены для больших систем (например, не менее 8 процессоров, память в десятки гигабайт и т.д.) и было показано, что с ростом системы цена на подсчёт ссылок растёт настолько, что использование только GC оказывается существенно дешевле. Поэтому в средах, обычно рассчитанных на более-менее «большие» применения, как та же Java, .NET, используется только GC. Ссылок не дам, но можете сами легко найти по ключевым словам.
В случае всяких smart pointers проблема оказывается в большом количестве атомарных операций со счётчиком (которые сильно дороже простых, как бы ни исполнялись) и засорению кэша, когда часть целевого объекта вынуждена постоянно быть закэширована, даже если не читается (любое копирование такого указателя при передаче в функцию или метод уже достаточно, чтобы дёргать счётчик). Если же пытаться избавляться от этого явным заданием конкретного типа владения (own/borrow/share и тому подобное), то резко возрастает опасность получить не тот эффект из-за описок программиста.
В сумме мы имеем тут реализацию классического «мы можем сделать быстро, дёшево, качественно — выберите любые два». Или гимор программисту, или затраты по памяти (где в 2, а где и в 10 раз), или затраты процессорного времени. Каждая реализация оптимизируется с ухудшением одного из этих факторов, смотря что менее важно.
я так понимаю имелся ввиду shared_pointer который известен своей относительно низкой производительностью: nerds-central.blogspot.com/...issues-and.html
в большинстве случаев без shared pointer можно вполне обойтись заменив более легковесным классом
всякие разновидности auto pinters вполне себе эффективны и имеют малый оверхед: www.drdobbs.com/...ueptr/240002708
всякие разновидности auto pinters вполне себе эффективны и имеют малый оверхед: www.drdobbs.com/...ueptr/240002708Да, у ц++ программистов жизнь тяжела, нужно держать в голове 100500 костылей с ограниченной применимостью, вместо того что бы сосредоточиться на задаче.
Тем более они не спасают в случаях где джвм отлично справляется, например в случае циклических ссылок.
с циклическими ссылками помогают weak pointers: msdn.microsoft.com/...o/hh279672.aspx
с циклическими ссылками помогают weak pointers: msdn.microsoft.com/...o/hh279672.aspxВсе равно семантика в джаве намного проще, не нужно держать в голове граф ссылок слпожного приложения, и без проблем с производительностью.
Не сильно изменило.
Я постоянно наблюдаю, как соседи мучаются с C++ кодом.
Проблема одной из компонент тянется уже много месяцев. За это время перепробованы все средства поиска утечек, неположенных присвоений и тому подобного. valgrind уже ничего не осиливает. Пробуются другие аналогичные инструменты, даже если они формально слабее — находят кой-чего интересного.
Разумеется, все shared_ptr и тому подобные средства в полный рост — но это не помогает.
Я уже подумываю посоветовать им яву, но это будет новый цикл издевательств уже другого плана:)
Сам я там же питоню и, как ни странно, итоговая производительность отличается несущественно.
А че за проблемы у них? Мемори лики или краши?
Оба названных явления.
Лики хорошо решаются valgrind + проанализируйте владение объектами.
Пo поводу крашей, советую проанализировать thread-safety. Очень часто проблемы с ней завуалированы под гулящие указатели. Помните, что все типы (int, string, collections, etc) не thread-safe
> Лики хорошо решаются valgrind + проанализируйте владение объектами.
Я уже написал, что valgrind не помогает. Вы как-то слишком выборочно читаете.
> Пo поводу крашей, советую проанализировать thread-safety.
Спасибо, но текущий коллектив уже достаточно компетентен в этих проблемах. Но наследие прошлых героев не решается мгновенно.
Простите, я не правильно понял цель Вашего сообщения :)
Успехов компетентнму коллективу
Последние N лет пишем/развиваем довольно большую встроенную хрень. По опыту больше всего хлопот доставляет многопоточность. Проблемы с памятью вылазили всего раза два. Valgrind гоняем раз в полгода-год в основном перед релизом нового большого функционала.
Я начинал с C++, мозгов было мало, помню как поразился разнице C++ vs Java в двух местах:
1. ЭТО не компилируется. Почему?
2. ЭТО упало в момент работы. Почему?
В Java даже с маленьким опытом работы ответы лежали сверху.
Сборщик мусора никак не влияет на скорость разработки. Это стереотип, что C++ сложен из-за всех этих указателей и памяти.Ну канэшн, в ц++ исчезли утечки памяти вдруг?
Если нету кривирукости, то все ок. Конечно защиты от дурака в Яве гораздо больше, спору нет.
Не в криворукости дело а в продуктивности и сложности разработки.
Ява хороший мотоцикл, но чуть что не так начинает жрать неоправданно много бензина
Думаю от рук во многом зависит, ява ранает почти все биг дата стеки, и ниче.
но почему именно Джава, неужели он хужемне кажется, или здесь противоречие ?
А вообще джава как язык — это в принципе, просто неплохой язык.
Но кроме языка — это еще и платформа под любое железо — раз, и вагон с тележкой хорошо продуманных API и библиотек, вылизанных по процессу JCP — два. Именно эти два — секрет успеха.
А в С++ до сих пор каждый изобретает свой string.
Java — как автомат Калашникова.
Стреляет не быстрее всех, не дальше всех, не точнее всех.
Но энтепрайз без Джава как революция без АК.
А в С++ до сих пор каждый изобретает свой string.между прочим либ для С++ очень огромно, есть решения почти для каждой задачи
В С++ есть слишком большое число решений для каждой задачи — и практически нет признанных стандартов API. Прикручивать сторонние либы часто проблематично, велосипеды плохо совместимы. Часто это заканчивается изобретением еще одного велосипеда.
не, ну идеологически я за жабу, да, но
А в С++ до сих пор каждый изобретает свой string.ну это не «вина» плюсов, ибо std::string или тот же boost/algorithm/string/, возможно просто специфически оптимизируют под свои конкретные задачи
В целом, личное имхо — большинство Java-библиотек исключительно design patterns-friendly и пропитаны методологиями и абстракциями чуть более чем полностью, ну и лично для меня архитектурная составляющая одна из самых важных, но это всё педантство и не более, на практике же — ну нет никаких оснований заменять шарпом яву, вот нет их просто и не будет, как бы микромягкие не старались... просто .NET не нужен, и с этим должны смириться сеньоры и прочие там виндовс-фон воздыхатели ;)
Потому что сборщик мусора тогда открыл новые возможности.
Потому что Гослинг когда придумывал новый язык для написания программок под стиральные машинки и прочую технику и предположить не мог, что она дойдет и до серверных решений и окажется очень надежным языком в плане уязвимостей, доступности, простоты и прочих факторов. Наверное практически любой «тяжелый» сервер-сайд, требующий надежности (про производительность это отдельная история, наращивается железом и кластеризацией) будет писаться на Java.
Ну и второе — так это поскольку таки язык задумывался для микроволновок и подобных девайсов с ограниченными ресурсами, то очень неплохо вписался в мобильную разработку, а тут еще и Гугл со своим андроидом и сотнями миллионов девайсов, программы для которох востребованы не меньше.
Теперь понятно, почему все хотят знать / или знают Java?
Теперь понятно, почему все хотят знать / или знают Java?зарплата больше?
Vadym Zagorulko
Anton Bredykhin
code monkey
Васисуалий Лоханкин
Mykola Gurov
Igor Poloz
sensei
Найкращі коментарі пропустити