Защо Java
123 отговора
6565 прегледа
Re: Опит за отговор
Това е вярно... Java HotSpot VM част от J2SE 1.3.1+
Чувал съм и за оптимизарани сървърски Java VM, които динамично разгръщат цикли и други такива простотии...
Въпреки оптимизациите, С++ програмите са си по-бързи от Java програмите... (дори теоретично)
Проблема на С++ е че липват толкова всеобхватни стандартни библиотеки... За сметка на това има(или могат да се напишат) допълнителни библиотеки които неглежират това предимство на Java.
Все пак Java е просто програмен език (както и C++ е просто език).
J2SE/J2EE/други J2xx са съвкупност от Java/VM/библиотеки която трябва да се сравняват с равнопоставена такава съвкупност от С++ и библиотеки, а не само с езика С++...
Ако пък иска някой да ползва С++, богати стандартни библиотеки и в добавка менажиран код - да прова С++ и .NET...
П.П.
Всеки език си има предназначение и приложение... Нежелая да участвам в празнословие по темата "Java - anti Java".
Чувал съм и за оптимизарани сървърски Java VM, които динамично разгръщат цикли и други такива простотии...
Въпреки оптимизациите, С++ програмите са си по-бързи от Java програмите... (дори теоретично)
Проблема на С++ е че липват толкова всеобхватни стандартни библиотеки... За сметка на това има(или могат да се напишат) допълнителни библиотеки които неглежират това предимство на Java.
Все пак Java е просто програмен език (както и C++ е просто език).
J2SE/J2EE/други J2xx са съвкупност от Java/VM/библиотеки която трябва да се сравняват с равнопоставена такава съвкупност от С++ и библиотеки, а не само с езика С++...
Ако пък иска някой да ползва С++, богати стандартни библиотеки и в добавка менажиран код - да прова С++ и .NET...
П.П.
Всеки език си има предназначение и приложение... Нежелая да участвам в празнословие по темата "Java - anti Java".
Re: Опит за отговор
fd=фд
"fd" става на "фд" щото като напишеш с кредора един отговор на кирилица и при следващия отговор кредора директно си пише на кирилица...
Това с хотспота не го знаех... Чичо гугъл ми го обясни...
Това със скороста е по повод част от мнението на Masklin..
"fd" става на "фд" щото като напишеш с кредора един отговор на кирилица и при следващия отговор кредора директно си пише на кирилица...
Това с хотспота не го знаех... Чичо гугъл ми го обясни...
Това със скороста е по повод част от мнението на Masklin..
Re: Защо Java
Драги ми Муру. Добра рима - Гуру - Муру. Нещо като Полковник - Подполковник, само че по-добро, понеже сричките са еднакъв брой. Поздравления.
ОК. Сега ще напиша един много мъдър параграф. ДОБРИЯТ ДЕВЕЛОПЪР СЕ СПРАВЯ ЕДНАКВО ДОБРЕ С ВСИЧКИ ЗАДАЧИ, БЕЗ ЗНАЧЕНИЕ КАКВА ПЛАТФОРМА ПОЛЗВА (1).
Доволен?
------------------------------------------------------------------------------------------------
(1) Горният параграф е верен, ако не ползвате Оракъл или Джава. Но ако ползвате Оракъл и / или Джава (недай си боже в комбинация) вие вече много добре знаете, че справянето със задачата няма никакво значение и ще печелите от други неща.
--
Increasing performance by lowering expectations.
ОК. Сега ще напиша един много мъдър параграф. ДОБРИЯТ ДЕВЕЛОПЪР СЕ СПРАВЯ ЕДНАКВО ДОБРЕ С ВСИЧКИ ЗАДАЧИ, БЕЗ ЗНАЧЕНИЕ КАКВА ПЛАТФОРМА ПОЛЗВА (1).
Доволен?
------------------------------------------------------------------------------------------------
(1) Горният параграф е верен, ако не ползвате Оракъл или Джава. Но ако ползвате Оракъл и / или Джава (недай си боже в комбинация) вие вече много добре знаете, че справянето със задачата няма никакво значение и ще печелите от други неща.
--
Increasing performance by lowering expectations.
Редактирано от Гypy на
в отговор на Kaндидaт Джaбap
#25
Тип приложения
може и да те интересуват, ама е по-важното е да се чувстваш комфортно. Друго си е да знаеш, че ако чуеш "класическата" работодателска фраза в деня за заплата "А бе, момчета, лесна работа, тия дни ще си изчистим сметките!" и да можеш като хванеш сайт за работа и в него има повече обяви за нещо свързано с Java, отколкото са дните до следващата заплата. Късмет! 
Re: Опит за отговор
Такааа, по тоя въпрос имаше една интересна статия на IBM Research labs писана съвместно с няколко университета. Жалко само, че не мога да я открия и да ви я постна.
Стратегии за предварително компилиране има няколко като например JIT (Just In Time), AOT (Ahead Of Time) и още няколко. По същество и теоретично AOT компилацията може да генерира по-бърз код отколкото C/C++. Знам, знам... Това е невъзможно ще каже някой, но я се замислете първо. Ако вие сте разработчици и вашият application е предназначен да върви на х86 машини, тогава вие го компилирате (С/С++), да кажем, с включени оптимизации за Pentium MMX и почвате да го разпространявате. Какво става обаче, ако вашето приложение го пуснете на Athlon XP или Pentium 4? Просто в този случай приложението не може да се възползва от мощта на процесора.
От другата страна е Java VM-то с Java приложението и AOT или JIT компилатор, които за *конкретната* машина могат да компилират Bytecode-а до съответните машинни инструкции и ще го направят перфектно.
Също така има и една друга възможност за оптимизация, а именно че Java VM-то работещо на конкретната машина и компилирано за конкретната машина знае много подробности за нея и чисто теоретично може да премахне ненужен код, който зависи от условия, които никога няма да сработят на машината.
Та такива ми ти работи :-)
Стратегии за предварително компилиране има няколко като например JIT (Just In Time), AOT (Ahead Of Time) и още няколко. По същество и теоретично AOT компилацията може да генерира по-бърз код отколкото C/C++. Знам, знам... Това е невъзможно ще каже някой, но я се замислете първо. Ако вие сте разработчици и вашият application е предназначен да върви на х86 машини, тогава вие го компилирате (С/С++), да кажем, с включени оптимизации за Pentium MMX и почвате да го разпространявате. Какво става обаче, ако вашето приложение го пуснете на Athlon XP или Pentium 4? Просто в този случай приложението не може да се възползва от мощта на процесора.
От другата страна е Java VM-то с Java приложението и AOT или JIT компилатор, които за *конкретната* машина могат да компилират Bytecode-а до съответните машинни инструкции и ще го направят перфектно.
Също така има и една друга възможност за оптимизация, а именно че Java VM-то работещо на конкретната машина и компилирано за конкретната машина знае много подробности за нея и чисто теоретично може да премахне ненужен код, който зависи от условия, които никога няма да сработят на машината.
Та такива ми ти работи :-)
Re: Опит за отговор
>> Въпреки оптимизациите, С++ програмите са си по-бързи от Java програмите... (дори теоретично)
Забелязал съм че много хора обсъждат скоростта на Джава... едните твърдят, че С++ по дефиниция (солиден аргумент!) е по-бърз от Джава и други несериозни езици. Вторите говорят за JIT компилаторите, които генерират също толкова (или съизмеримо) бърз код като на типичните "native" езици.
Ето каква е истината по мое скромно мнение: Джава по принцип е по-бавна. Не че ако въртиш цикъл на С или Джава ще усетиш някаква фрапираща разлика в performance-a. И все пак джава е по-бавна първо заради garbage collector-a и run-time environment-a въобще, който на практика не е толкоз бързичък колкото на теория. Някой тук обясняваше, че референцията всъщност е указател. Да, ама не е съвсем така. Много ВМ са реализирани така че референцията е указател към указател (има си причина за това;) Второ в джава се ползват обекти за щяло и за нещяло (например за цвят, за стринг, масиви и т.н.). Трето в джава доста се ползват неща като сериализацията, които доста облекчават някои операции, ама не са много бързички:) Абе още доста може да се каже по въпроса, ама засега това се сещам.
Между впрочем когато почнах да се занимавам с джава ми беше доста трудно да свикна с мисълта, че няма директна работа с указатели например. И доста други неща с които бях свикнал. Ама ей го на още съм жив... и все пак стигнах до извода, че освен недостатъци, езикът си има и плюсове, ама не ми се влиза във вечния и много тъп спор от типа "Левски или ЦСКА"
Забелязал съм че много хора обсъждат скоростта на Джава... едните твърдят, че С++ по дефиниция (солиден аргумент!) е по-бърз от Джава и други несериозни езици. Вторите говорят за JIT компилаторите, които генерират също толкова (или съизмеримо) бърз код като на типичните "native" езици.
Ето каква е истината по мое скромно мнение: Джава по принцип е по-бавна. Не че ако въртиш цикъл на С или Джава ще усетиш някаква фрапираща разлика в performance-a. И все пак джава е по-бавна първо заради garbage collector-a и run-time environment-a въобще, който на практика не е толкоз бързичък колкото на теория. Някой тук обясняваше, че референцията всъщност е указател. Да, ама не е съвсем така. Много ВМ са реализирани така че референцията е указател към указател (има си причина за това;) Второ в джава се ползват обекти за щяло и за нещяло (например за цвят, за стринг, масиви и т.н.). Трето в джава доста се ползват неща като сериализацията, които доста облекчават някои операции, ама не са много бързички:) Абе още доста може да се каже по въпроса, ама засега това се сещам.
Между впрочем когато почнах да се занимавам с джава ми беше доста трудно да свикна с мисълта, че няма директна работа с указатели например. И доста други неща с които бях свикнал. Ама ей го на още съм жив... и все пак стигнах до извода, че освен недостатъци, езикът си има и плюсове, ама не ми се влиза във вечния и много тъп спор от типа "Левски или ЦСКА"
Като по учебник
На теория не би трябвало да има разлика между теорията и практиката, но на практика не е точно така
Тия неща дето ги казваш могат да се прочетат във всеки жабешки учебник и повечето са абсолютно грешни, или са откровена рекламна лъжа. За сметка на това някои аспекти са пропуснати ( премълчани ). Аз съм работил и на двата езика и имам някои наблюдения. Ето и моя анализ на казаното:
ОК, това е добре - така си независим от OS ( поне на теория. На практика не е съвсем така, но това е друга тема ).
На теория това е много хубаво, ако е направено добре и работи. Но не е, а липсата на каквито и да е механизми за 'ръчен' контрол на паметта прави нещата трагични.
Какво се получава на практика? Получава се, че хората пишат Object Pools и правят всякакви еквилибристики за Object Reusing за да задържат консумацията на памет в разумни граници. Т.е. не се занимават директно, а индиректно с управлението на паметта, което е значително по-трудно.
Предобрили са го. Ако имаш random access и искаш достъп до произволен елемент е приемливо. Ама като имам нещо от рода на
for( i = 0; i < arr.size(); ++i ) // не помня как се пишеше това на Жаба
( i не се бара в цикъла ) проверката си е живо разточителство.
C++ също има такъв механизъм за проверка в контейнерите си, чрез достъп до елементите не по индекс а с container.at(index)
И тук работата като при паметта - теорията и практиката съществено се разминават. Ако извикването на функции с празно тяло нямаше никакъв ефект - добре. Но нещата не са направени както трябва и в момента няма добър начин да е направи trace( .. ) функция. Извикването на функция, заедно с целия текст влиза в изходния код, макар функцията да е празна. Не помагат и модификатори static final. Затова вмесо
trace("bla bla")
хората пишат
if( traceEnabled ) trace("bla bla");
Тъпо!
Дават, но са лошо документирани и са на светлинни години от MSDN. Затова често се налага да се прави reverse engineering.
Абе не знам мениджърите какво разбират от тия неща дето ги изброи. Според мен това което те най-харесват в Жабата е лесното портване на различни OS.
Що се отнася до 'класическите' грешки - от години не съм допускал нито една от тях. Те не са трудни за избягване с добра практика.
Основният проблем е, че жабата действа на програмиста отпускащо и той не се замисля за ресурса. С лекота се правят нови обекти, копират се данни ненужно и т.н. Кой жабар сте видели да ползва StringBuf вместо да си събира стринговете с '+'? А ресурсите за контрол отдавна не се смятат за големи.
Някои недостатъци на езика:
- Няма еквивалент на const * предаването на аргументи на функция. Това прави трудно проследяването на даден аргумент дали се модифицира.
- Няма const модификатори на функции. Това затруднява проследяването дали се модифицират членове на класа.
- Няма templates ( всъщност напоследък май са сложили, но това е твърде ново за да влияе ). Това налага чест typecast и ненужни RTTI проверки.
- Няма слаби, или профилирани кастове. А езикът налага прекалено често ползване на typecast. Това е потенциален извор на грешки и ненужни RTTI проверки.
- Няма беззнаково разширение на целочислените типове ( но пък има беззнаково шифтване на дясно, което е добре ). C++ програмистите често остават неприятно изненадани, че ако в буфера има байт със стойност FF като го разширят не става 255, а -1. Затова се налага да се пише нещо от рода на
i = b&0xFF;
System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_
Тия неща дето ги казваш могат да се прочетат във всеки жабешки учебник и повечето са абсолютно грешни, или са откровена рекламна лъжа. За сметка на това някои аспекти са пропуснати ( премълчани ). Аз съм работил и на двата езика и имам някои наблюдения. Ето и моя анализ на казаното:
В отговор на:Основното предимство на Java е, че е платформа, контролираща изпълнението на програмата.
ОК, това е добре - така си независим от OS ( поне на теория. На практика не е съвсем така, но това е друга тема ).
В отговор на:Не се занимаваш директно с управлението на паметта
На теория това е много хубаво, ако е направено добре и работи. Но не е, а липсата на каквито и да е механизми за 'ръчен' контрол на паметта прави нещата трагични.
Какво се получава на практика? Получава се, че хората пишат Object Pools и правят всякакви еквилибристики за Object Reusing за да задържат консумацията на памет в разумни граници. Т.е. не се занимават директно, а индиректно с управлението на паметта, което е значително по-трудно.
В отговор на:и освен това всяка команда се проверява за коректност (примерно индексиране на масив).
Предобрили са го. Ако имаш random access и искаш достъп до произволен елемент е приемливо. Ама като имам нещо от рода на
for( i = 0; i < arr.size(); ++i ) // не помня как се пишеше това на Жаба
( i не се бара в цикъла ) проверката си е живо разточителство.
C++ също има такъв механизъм за проверка в контейнерите си, чрез достъп до елементите не по индекс а с container.at(index)
В отговор на:Като по-съвременен език от C++, Java няма нужда от препроцесор
И тук работата като при паметта - теорията и практиката съществено се разминават. Ако извикването на функции с празно тяло нямаше никакъв ефект - добре. Но нещата не са направени както трябва и в момента няма добър начин да е направи trace( .. ) функция. Извикването на функция, заедно с целия текст влиза в изходния код, макар функцията да е празна. Не помагат и модификатори static final. Затова вмесо
trace("bla bla")
хората пишат
if( traceEnabled ) trace("bla bla");
Тъпо!
В отговор на:стандартните библиотеки, които ти дават почти всичко
Дават, но са лошо документирани и са на светлинни години от MSDN. Затова често се налага да се прави reverse engineering.
В отговор на:от мениджърска гледна точка изглежда, че с Java е много по-лесно да се напише работещ код, без класическите програмистки грешки като изтичане на памет, препълване на буфери, използване на различни декларации или параметри на интерфейси и т.н., които изяждат много време за дебъгване.
Абе не знам мениджърите какво разбират от тия неща дето ги изброи. Според мен това което те най-харесват в Жабата е лесното портване на различни OS.
Що се отнася до 'класическите' грешки - от години не съм допускал нито една от тях. Те не са трудни за избягване с добра практика.
В отговор на:Основният проблем при Java е, че контролирания код е тежък - изисква много процесорна мощ и памет. Поради това, макар че теоретично не трябва да има голяма разлика в скорстта между приложение, писано на Java и такова, писано на C++, хората забелязват без особени усилия в повечето случаи тромавия Java код.
Основният проблем е, че жабата действа на програмиста отпускащо и той не се замисля за ресурса. С лекота се правят нови обекти, копират се данни ненужно и т.н. Кой жабар сте видели да ползва StringBuf вместо да си събира стринговете с '+'? А ресурсите за контрол отдавна не се смятат за големи.
Някои недостатъци на езика:
- Няма еквивалент на const * предаването на аргументи на функция. Това прави трудно проследяването на даден аргумент дали се модифицира.
- Няма const модификатори на функции. Това затруднява проследяването дали се модифицират членове на класа.
- Няма templates ( всъщност напоследък май са сложили, но това е твърде ново за да влияе ). Това налага чест typecast и ненужни RTTI проверки.
- Няма слаби, или профилирани кастове. А езикът налага прекалено често ползване на typecast. Това е потенциален извор на грешки и ненужни RTTI проверки.
- Няма беззнаково разширение на целочислените типове ( но пък има беззнаково шифтване на дясно, което е добре ). C++ програмистите често остават неприятно изненадани, че ако в буфера има байт със стойност FF като го разширят не става 255, а -1. Затова се налага да се пише нещо от рода на
i = b&0xFF;
System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_
Не са точно глупости
HotSpot върши огромна работа, дори в сравнение с Just-In-Time компилаторите, които от своя страна увеличават значително производителността в сравнение с чистия интерпретиран код.
(Обаче както Questor спомена, като кажат веднъж, че сестра ти е курва, ходи доказвай, че нямаш сестра.)
Доста интересно сравнение управляем / компилиран език (в частност Java / C++) можеш да намериш тук. Прочети го, интересно е. Та там авторът обяснява, че има ситуации, в които управляемия код е дори по-добър от обикновения компилиран код, основно защото може да се прави run-time анализ, който позволява оптимизации, невъзможни при compile-time анализ на кода.
За C++ има наистина огромно количество библиотеки; проблемът обаче е, че не се стандартни. Пък и аз се опитах да обясня защо хората харесват Java - защото в нея вече има необходимия преносим и висококачествен код. Даже ми се струва, че почти няма област в ИТ, където да няма решени основните проблеми с Java библиотеки ...
Още едно, според мен убийствено предимство на управляемия код. За съжаление, не мога да се сетя за точното име; същината е следната: с добавяне на една конкретна библиотека към програмата ти можеш да посочиш критерии, при които да бъде викан избран от теб код, като критериите са динамични и могат да включват викане на метод / конструктор, четене / промяна на стойност на променлива, даже ако не се лъжа, преминаване през определена точка от кода.
Което както и да го погледнеш, дава страшно удобен метод за дебъгване, при това на съществуващ код, без модификации в него. Разбира се, същото може да се направи с всеки добър debugger, но представи си, че това става при клиенти - там дебъгер няма, но нищо не пречи да заложиш капанче, което при определени условия да излови проблеми и да ти ги рапортува.
Всъщност приложения има и други, но мен лично това направо ме тресна по главата
И една поправка на постинга ти: не C++ и .Net, а C# и .Net. C++ наистина работи на управляема платформа, но с емулации, доколкото знам.
Понякога седя и си мисля, а понякога само си седя ...
(Обаче както Questor спомена, като кажат веднъж, че сестра ти е курва, ходи доказвай, че нямаш сестра.)
Доста интересно сравнение управляем / компилиран език (в частност Java / C++) можеш да намериш тук. Прочети го, интересно е. Та там авторът обяснява, че има ситуации, в които управляемия код е дори по-добър от обикновения компилиран код, основно защото може да се прави run-time анализ, който позволява оптимизации, невъзможни при compile-time анализ на кода.
За C++ има наистина огромно количество библиотеки; проблемът обаче е, че не се стандартни. Пък и аз се опитах да обясня защо хората харесват Java - защото в нея вече има необходимия преносим и висококачествен код. Даже ми се струва, че почти няма област в ИТ, където да няма решени основните проблеми с Java библиотеки ...
Още едно, според мен убийствено предимство на управляемия код. За съжаление, не мога да се сетя за точното име; същината е следната: с добавяне на една конкретна библиотека към програмата ти можеш да посочиш критерии, при които да бъде викан избран от теб код, като критериите са динамични и могат да включват викане на метод / конструктор, четене / промяна на стойност на променлива, даже ако не се лъжа, преминаване през определена точка от кода.
Което както и да го погледнеш, дава страшно удобен метод за дебъгване, при това на съществуващ код, без модификации в него. Разбира се, същото може да се направи с всеки добър debugger, но представи си, че това става при клиенти - там дебъгер няма, но нищо не пречи да заложиш капанче, което при определени условия да излови проблеми и да ти ги рапортува.
Всъщност приложения има и други, но мен лично това направо ме тресна по главата
И една поправка на постинга ти: не C++ и .Net, а C# и .Net. C++ наистина работи на управляема платформа, но с емулации, доколкото знам.
Понякога седя и си мисля, а понякога само си седя ...
Доста си краен
Но да прескочим обидите (не ти правят чест) и странните съждения от сорта на "ако пише на Java, значи не се замисля за ресурсите". Това е точно толкова нелепо, колкото да кажеш "абе този пише на C, т.е. макроасемблер, значи не се замисля за платформено независима архитектура".
Java е инструмент и като такъв има свои особености, с които да се съобразиш, както и несъмнени недостатъци.
Абсолютно съгласен съм, че не е добре програмистът изобщо да не контролира управлението на паметта. Просто защото е страшно трудно да се напише код, който да знае как най-добре да я управлява. Значи, трябва да има начин да се дават съвети на управителя на паметта, в допълнение на наистина удобната възможност когато не ти трябва, да не мислиш за управлението й.
Не си разбрал нещо ключово в постинга ми, струва ми се. Управлението на програмата е нещо далеч по-голямо и по-важно от преносимостта. Същественото е, че програмата не може да прави каквото си иска, което позволява да отрежеш цели клонове грешки (които всички ние, с изключение може би на теб, допускаме) и потенциални пробиви в сигурността. Помага страшно много и при дебъгването - вместо да се намаже нещо някъде, просто ще те ударят през пръстите. А намазване се случва в много ситуации, които не са свързани директно с програмистка грешка от сорта на излизане от рамките на масив. Става и при неправилен cast, при използване на стара версия на интерфейс и какво ли още не ...
Ако се разгледа развитието на C++ в последните години, в очи се набива нека да не е точно подражание на Java, но при всички случаи взаимстване на технологии от нея, примерно защитени индексирания. Разликата е, че просто няма как да принудиш програмиста да ги използва.
Да го кажем така: полза от управлението на програмата има. Java е първият сериозен опит в тази насока, с много недостатъци и несомислици. .Net е вторият сериозен опит. В идеята има много хляб, просто защото е по-важно да се пише стабилен, отколкото бърз код и то да се пише бързо. Разбира се, не бива да се изпада в крайности, но като цяло, в доста случаи по-важно е да работи, на цената на примерно 30% забавяне, отколкото да се чупи или да отнема с месеци повече за разработка.
И C++ просто не е инструмент за писане на управляем код. C++ е инструмент за писане на критични приложения, в които скоростта е от първостепенно значение, както и вероятно малкото използвана памет. Поради важността на кода можем да си позволим по-бавна разработка и купища време за debug. Но за едно бизнес-приложение, усилието да се пише на C++, а не на управляема платформа (нека не е Java, нека е C#) е неоправдано.
Понякога седя и си мисля, а понякога само си седя ...
Java е инструмент и като такъв има свои особености, с които да се съобразиш, както и несъмнени недостатъци.
Абсолютно съгласен съм, че не е добре програмистът изобщо да не контролира управлението на паметта. Просто защото е страшно трудно да се напише код, който да знае как най-добре да я управлява. Значи, трябва да има начин да се дават съвети на управителя на паметта, в допълнение на наистина удобната възможност когато не ти трябва, да не мислиш за управлението й.
Не си разбрал нещо ключово в постинга ми, струва ми се. Управлението на програмата е нещо далеч по-голямо и по-важно от преносимостта. Същественото е, че програмата не може да прави каквото си иска, което позволява да отрежеш цели клонове грешки (които всички ние, с изключение може би на теб, допускаме) и потенциални пробиви в сигурността. Помага страшно много и при дебъгването - вместо да се намаже нещо някъде, просто ще те ударят през пръстите. А намазване се случва в много ситуации, които не са свързани директно с програмистка грешка от сорта на излизане от рамките на масив. Става и при неправилен cast, при използване на стара версия на интерфейс и какво ли още не ...
Ако се разгледа развитието на C++ в последните години, в очи се набива нека да не е точно подражание на Java, но при всички случаи взаимстване на технологии от нея, примерно защитени индексирания. Разликата е, че просто няма как да принудиш програмиста да ги използва.
Да го кажем така: полза от управлението на програмата има. Java е първият сериозен опит в тази насока, с много недостатъци и несомислици. .Net е вторият сериозен опит. В идеята има много хляб, просто защото е по-важно да се пише стабилен, отколкото бърз код и то да се пише бързо. Разбира се, не бива да се изпада в крайности, но като цяло, в доста случаи по-важно е да работи, на цената на примерно 30% забавяне, отколкото да се чупи или да отнема с месеци повече за разработка.
И C++ просто не е инструмент за писане на управляем код. C++ е инструмент за писане на критични приложения, в които скоростта е от първостепенно значение, както и вероятно малкото използвана памет. Поради важността на кода можем да си позволим по-бавна разработка и купища време за debug. Но за едно бизнес-приложение, усилието да се пише на C++, а не на управляема платформа (нека не е Java, нека е C#) е неоправдано.
Понякога седя и си мисля, а понякога само си седя ...
Re: Опит за отговор
Това изследване бих го причислил към поръчковите такива...
Определено, подходящо оптимизирана програма е по-бърза от неподходящо оптимизирана.
Intel бяха достигнали такива висоти в оптимизиращите компилатори, че специално оптимизирана програма за P4 (компилирана с Интелски компилатор) процентно подобряваше работата на АMD процесор повече от колкото на P4 (мисля че за теста беше ползван Опертон).
Тогава още нямаше оптимизирани компилатори за AMD...
Колкото до JIT/АОТ - неможе да се сравнят с целенасоченото оптимизирано компилиране до машинен код направено от разработчиците на програмата... Скороста при JIT/AOT макар и понякога с малко е по-зле.
Предимството на JIT/AOT е че се компилира до байт код само веднъж и окончателната компилация се осъществява на място. Докато при C++(т.е. езици с предварително компилиране до машинен код) трябва да се правят предварително оптимизирани компилации специално за "всяка" платформа...
Ако JIT/AOT имаха някакво предимство в скороста, драйверите или примерно програмите за обработка на изображения/видео/звук/други щяха да се пишат примерно на Java (а не на C/C++/други).
Все пак Microsoft май предприемат действия драйверите в бъдещите версии на Windows да се пишат на .NET (макар да си мисля, че критичните за скороста части от драйверите ще се пишат като и до сега - предварително компилиран оптимизиран неменажиран код)
Определено, подходящо оптимизирана програма е по-бърза от неподходящо оптимизирана.
Intel бяха достигнали такива висоти в оптимизиращите компилатори, че специално оптимизирана програма за P4 (компилирана с Интелски компилатор) процентно подобряваше работата на АMD процесор повече от колкото на P4 (мисля че за теста беше ползван Опертон).
Тогава още нямаше оптимизирани компилатори за AMD...
Колкото до JIT/АОТ - неможе да се сравнят с целенасоченото оптимизирано компилиране до машинен код направено от разработчиците на програмата... Скороста при JIT/AOT макар и понякога с малко е по-зле.
Предимството на JIT/AOT е че се компилира до байт код само веднъж и окончателната компилация се осъществява на място. Докато при C++(т.е. езици с предварително компилиране до машинен код) трябва да се правят предварително оптимизирани компилации специално за "всяка" платформа...
Ако JIT/AOT имаха някакво предимство в скороста, драйверите или примерно програмите за обработка на изображения/видео/звук/други щяха да се пишат примерно на Java (а не на C/C++/други).
Все пак Microsoft май предприемат действия драйверите в бъдещите версии на Windows да се пишат на .NET (макар да си мисля, че критичните за скороста части от драйверите ще се пишат като и до сега - предварително компилиран оптимизиран неменажиран код)
Re: Защо Java
Доволен от какво?
Зададох въпрос, а не ми отговори. Скачаш ми с твърдение+изключение без да привеждаш примери и факти. Може би по-горе си искал да кажеш "... огромен екип НЕКАДЪРНИ девелопери за две години ...", м? Дори и да си искал това да кажеш, пропуснал си да уточниш какво е това нещо, и колко на брой (не)кадърни девелопери за какво време обикновено се справят с тази задача на друга платформа.
Зададох въпрос, а не ми отговори. Скачаш ми с твърдение+изключение без да привеждаш примери и факти. Може би по-горе си искал да кажеш "... огромен екип НЕКАДЪРНИ девелопери за две години ...", м? Дори и да си искал това да кажеш, пропуснал си да уточниш какво е това нещо, и колко на брой (не)кадърни девелопери за какво време обикновено се справят с тази задача на друга платформа.
Re: Опит за отговор
Всъщност силата на C++ е в надграждането. По принцип, ако сложиш фреймуърк, който да ти прави среда все едно пишеш на java (въпросните GC, bound-чекове, и всички остнали екстри), вероятно няма да е кой-знае колко по-бърз от java. Но определено ще изразходва значително по-малко ресурси.
Но определено ще изразходва значително по-малко ресурси.Re: Доста си краен
Краен съм, защото просто не съм засягал нещата които ми харесват. Харесвам много неща в Жаба. Например опростеният синтаксис и редуцираните операции позволяват създаването на страхотни среди за програмиране с мощ която прави Visual Studio да изглежда смешно.
Това за писането на Жаба и ресурсите според моя опит е вярно. Наблюдавал съм го върху себе си и върху колегите си. Същото е споделял и един приятел, преподаващ на малките жабарчета във ФМИ 'СД и ООП' на C++.
А тия 'цели клонове грешки' не ги допускам с много проста хигиена - не правя нищо 'ръчно'. В мой код никъде няма да видиш new или delete по средата на функция. Капсулирам нещата в малки добре проверени класове с конструктор, деструктор, copy, assign.
Навремето като пишех графика си бях направил auto_GDI - смарт пойнтер грижещ се да селектира подаден Pen, Brush, или квото там му дадеш в DC-то и в деструктора да върне каквото е имало и да убие новото. С такава техника няма как да ти изтече ресурс. Правил съм си и auto_buf - нещо като вектор, но по-просто и без излишни инициализации. Щото не е приемливо като ми трябва 1M памет за картинка некой да ми я пълни с 0 и после аз да копирам 1M данни върху тия нули.
Индексация почти никога не ползвам - много малко алгоритми налагат random_access достъп. Работя с итератори и знам добре, кои са операциите които ги инвалидират. Последният път когато допуснах грешка out_of_range беше преди около 2.5 години. Тогава ми се наложи да изуча crt-то за да я хвана. После съм помагал с така придобитите знания на колеги да хванат техни грешки.
Разбира се и аз допускам грешки като всеки програмист, но те просто не са от класовете грешки от които ме пази Жаба-та.
За ключовото си прав - това с управлението ми беше мътно и продължава. Явно съм си прост занаятчия и тия неща ми звучат прекалено абстрактно.
За гарантиране на правилен каст си има dynamic_cast. Това е все едно да ми кажеш, че стават грешки от пойнтерна аритметика. Някои ги правят, други - не. И такива грешки не съм допускал. Най-малкото защото почти никога не ми се налага да правя каст. Ако ми се налага почвам да се чудя къде съм сбъркал и правя нещата така че да не се налага.
А тва за старите интерфейси вече втори път го казваш и понеже пак не ми стана ясно какво имаш предвид ще те помоля да го обясниш по-подробно.
Хубаво е, че езиците си взаимодействат и взимат хубави неща едни от други. Абсолютната истина не съществува, но така се приближаваме към нея :-))
Смятам, че стабилността на програмите зависи не толкова от езика за програмиране, колкото от технологията на производството им. Не бих си купил софт, дето ще върви мудно ако има негов еквивалент работещ нормално. Просто не ми звучи разумно твърдени е от сорта на 'Нашата програма може да е бавна, ама понеже е писана на Жаба има по-малко грешки от другата. Пък онова е писано на C++ и е абсолютно неуправляемо.'
System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_
Това за писането на Жаба и ресурсите според моя опит е вярно. Наблюдавал съм го върху себе си и върху колегите си. Същото е споделял и един приятел, преподаващ на малките жабарчета във ФМИ 'СД и ООП' на C++.
А тия 'цели клонове грешки' не ги допускам с много проста хигиена - не правя нищо 'ръчно'. В мой код никъде няма да видиш new или delete по средата на функция. Капсулирам нещата в малки добре проверени класове с конструктор, деструктор, copy, assign.
Навремето като пишех графика си бях направил auto_GDI - смарт пойнтер грижещ се да селектира подаден Pen, Brush, или квото там му дадеш в DC-то и в деструктора да върне каквото е имало и да убие новото. С такава техника няма как да ти изтече ресурс. Правил съм си и auto_buf - нещо като вектор, но по-просто и без излишни инициализации. Щото не е приемливо като ми трябва 1M памет за картинка некой да ми я пълни с 0 и после аз да копирам 1M данни върху тия нули.
Индексация почти никога не ползвам - много малко алгоритми налагат random_access достъп. Работя с итератори и знам добре, кои са операциите които ги инвалидират. Последният път когато допуснах грешка out_of_range беше преди около 2.5 години. Тогава ми се наложи да изуча crt-то за да я хвана. После съм помагал с така придобитите знания на колеги да хванат техни грешки.
Разбира се и аз допускам грешки като всеки програмист, но те просто не са от класовете грешки от които ме пази Жаба-та.
За ключовото си прав - това с управлението ми беше мътно и продължава. Явно съм си прост занаятчия и тия неща ми звучат прекалено абстрактно.
За гарантиране на правилен каст си има dynamic_cast. Това е все едно да ми кажеш, че стават грешки от пойнтерна аритметика. Някои ги правят, други - не. И такива грешки не съм допускал. Най-малкото защото почти никога не ми се налага да правя каст. Ако ми се налага почвам да се чудя къде съм сбъркал и правя нещата така че да не се налага.
А тва за старите интерфейси вече втори път го казваш и понеже пак не ми стана ясно какво имаш предвид ще те помоля да го обясниш по-подробно.
Хубаво е, че езиците си взаимодействат и взимат хубави неща едни от други. Абсолютната истина не съществува, но така се приближаваме към нея :-))
Смятам, че стабилността на програмите зависи не толкова от езика за програмиране, колкото от технологията на производството им. Не бих си купил софт, дето ще върви мудно ако има негов еквивалент работещ нормално. Просто не ми звучи разумно твърдени е от сорта на 'Нашата програма може да е бавна, ама понеже е писана на Жаба има по-малко грешки от другата. Пък онова е писано на C++ и е абсолютно неуправляемо.'
System Doctor Error:
Your girlfriend is pregnant.
(A)bort, (M)arry, (I)gnore?_
Мда
Всъщност това, което правиш ти с твои класове се опитва да направи Java, ама така, че да те накара да спазваш приличието, тоест добрият стил. Ама не е лесно, това програмисткото племе много изобретателно
Разбираш ли, не може да се разчита, че програмиста "знае" как трябва да работи и не работи иначе. Е, може де, ако искаш да си малко но тръни, но много в бързата среда за програмиране, но е по-спокойно, ако не мислиш тези неща, особено ако под теб има нам-си-колко маймуни, на които не можеш 100% да разчиташ. То в този случай и на куп други неща не можеш да разчиташ, не само на добрия стил, но поне изкушението да карат през просото им е спестено.
За интерфейсите имах предвид примерно следната заровена брадвичка: стари .h заедно с нова версия на .so/.dll. Сещаш се за ефекта - различни представи за структурите данни, които хвърчат между парчетата код, различни параметри като тип и/или брой при каскадно викане на функции (дефинирани като inline и поради това част от .h), различни дефиниции на обектите, ако щеш.
Между другото, самата идея да праскаш код в .h с цел оптимизация ме кара да си изповръщам червата. И защо така, мислиш? Защото C/C++ очаква linker-а нищо да не прави / разбира / оптимизира ... и няма друг начин да вземеш вече компилирания код и да го inline-неш където му е мястото. Ама това е вече anti-C конкретно, не сравнение компилиран / управляем код и е малко offtopic
Понякога седя и си мисля, а понякога само си седя ...
Разбираш ли, не може да се разчита, че програмиста "знае" как трябва да работи и не работи иначе. Е, може де, ако искаш да си малко но тръни, но много в бързата среда за програмиране
, но е по-спокойно, ако не мислиш тези неща, особено ако под теб има нам-си-колко маймуни, на които не можеш 100% да разчиташ. То в този случай и на куп други неща не можеш да разчиташ, не само на добрия стил, но поне изкушението да карат през просото им е спестено.
За интерфейсите имах предвид примерно следната заровена брадвичка: стари .h заедно с нова версия на .so/.dll. Сещаш се за ефекта - различни представи за структурите данни, които хвърчат между парчетата код, различни параметри като тип и/или брой при каскадно викане на функции (дефинирани като inline и поради това част от .h), различни дефиниции на обектите, ако щеш.
Между другото, самата идея да праскаш код в .h с цел оптимизация ме кара да си изповръщам червата. И защо така, мислиш? Защото C/C++ очаква linker-а нищо да не прави / разбира / оптимизира ... и няма друг начин да вземеш вече компилирания код и да го inline-неш където му е мястото. Ама това е вече anti-C конкретно, не сравнение компилиран / управляем код и е малко offtopic
Понякога седя и си мисля, а понякога само си седя ...
да ама никой не отчита, че
колкоти и добър код да генерират jit/aot компилаторите, тоя код трябва да се jit/aot-не. по мойте наблюдения, точно от там идва голямото забавяне и усещането за тромавост на приложенията писани на жаба.
даже и при aot, където на теория би трябвало да се използва iddle time, за тая работа, това дето ти трябва може още да не е готово (почти винаги по закона за гадостта :-)) и пак чакаш
друго, компилирането по време на изпълнение е оптимизирано за СКОРОСТ НА КОМПИЛАЦИЯТА, не за КАЧЕСТВЕН КОД (обърнете внимание колко бавно работи и по колко паса прави един истински оптимизиращ компилатор), така че няма начин генерирания код да е по-добър от предварително компилирания, независимо какви оптимизации съобразени с конкретната машина са направени на място.
а тези неща кой знае защо се изпускат от апологотетите на жабата
даже и при aot, където на теория би трябвало да се използва iddle time, за тая работа, това дето ти трябва може още да не е готово (почти винаги по закона за гадостта :-)) и пак чакаш
друго, компилирането по време на изпълнение е оптимизирано за СКОРОСТ НА КОМПИЛАЦИЯТА, не за КАЧЕСТВЕН КОД (обърнете внимание колко бавно работи и по колко паса прави един истински оптимизиращ компилатор), така че няма начин генерирания код да е по-добър от предварително компилирания, независимо какви оптимизации съобразени с конкретната машина са направени на място.
а тези неща кой знае защо се изпускат от апологотетите на жабата
Редактирано от ~!@$%^amp;*()_+ на
в отговор на Pekoнcтpykтop
#38
Re: Опит за отговор
Отговорих. Прави се на умен и на разбиращ. Умните ще се справят с .НЕТ и с Джава еднакво. Това е твоята теория.
Не е вярна.
Вярвай си.
--
Sometimes the sole purpose of your life is to serve as a warning to others.
Не е вярна.
Вярвай си.
--
Sometimes the sole purpose of your life is to serve as a warning to others.
Re: Опит за отговор
Abe momcheta shto se karate za gluposti ?
1. Kakvo znachenie ima ma kakav ezik programirash - ezika e samo instrument s koito da sqtvorish nekoia programa, ako imash dobri specification + design vseki student she ti go napishe kato mu dadesh podrobni specs
2. V segashno vreme e malko smeshno da se govori za hardwaren problem v smisal niamam dostatqchno dobqr hardware da run-van Java na nego, ne se izlagaite, na 16 processorna mashina kolko e razlikata v vremeto
Seriozni hora izglejdate a se karate koe bilo po bqrzo :)
1. Kakvo znachenie ima ma kakav ezik programirash - ezika e samo instrument s koito da sqtvorish nekoia programa, ako imash dobri specification + design vseki student she ti go napishe kato mu dadesh podrobni specs
2. V segashno vreme e malko smeshno da se govori za hardwaren problem v smisal niamam dostatqchno dobqr hardware da run-van Java na nego, ne se izlagaite, na 16 processorna mashina kolko e razlikata v vremeto
Seriozni hora izglejdate a se karate koe bilo po bqrzo :)
в отговор на ~!@$%^amp;*()_+
#40
Теоретично,
анализът какво прави кода на конкретното място може да бъде направен compile time, а run time просто да се съобразиш с конкретните условия в момента.
Но говоря малко наизуст, защото не знам какво се прави всъщност. Предполагам, че поне част от оптимизирането все пак се прави при компилиране.
Понякога седя и си мисля, а понякога само си седя ...
Но говоря малко наизуст, защото не знам какво се прави всъщност. Предполагам, че поне част от оптимизирането все пак се прави при компилиране.
Понякога седя и си мисля, а понякога само си седя ...