Почему так мало программ на java?

[Axa-Ru]

Понятно. Может вы и правы: эти вещи слабо связанные.

[SergeyIT]

А зачем джава, если все на С/С++ написать можно?

[gengzu]

А зачем джава, если все на С/С++ написать можно?

пока разработчики на С/С++ извращаются пытаясь выбрать из базы данные, а потом отлавливают утечки, разработчики на Java уже сдали проект и получили деньги.

[ii343hbka]

для явы - ява машина, а сишечка нативненько

[RazrFalcon]

А зачем джава, если все на С/С++ написать можно?

пока разработчики на С/С++ извращаются пытаясь выбрать из базы данные, а потом отлавливают утечки, разработчики на Java уже сдали проект и получили деньги.

Бедные быдлокодеры...

[gengzu]

Бедные быдлокодеры...

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

[Axa-Ru]

Вообще программы на ООЯП С++ очень трудны для чтения и подходят под определение быдлокодерства 

[RazrFalcon]

gengzu Об этом я и писал.
Написать можно на чем угодно, зависит от рук.
А падающее убожество можно и на джаве и на шарпе написать.
Пользователь решил продолжить мысль 15 Сентября 2011, 23:06:39:

Вообще программы на ООЯП С++ очень трудны для чтения и подходят под определение.

"Трудны для чтения" кому?

[Axa-Ru]

Видимо не вам.

[Tonal]

Я думаю, что их не так уж и мало

SmartGit
OpenOffice
Netbeans
CoolReader, если не ошибаюсь
На www.r-project.org перечислено несколько GUI к R, написанных на яве (JaguaR)
Squirrel SQL Client
jsqsh

Что OpenOffice, что CoolReader написаны на С++.
При написании на Java выигрышей несколько:

• Большой выигрышь в переносимости бинарных сборок.
• Небольшой выигрыш в скорости разработки за счёт сборки мусора, более быстрой компиляции и развитой инструментальной поддержки (рефакторинг в иде) за счёт более простого и модульного языка, большого количества библиотек и компонент за счёт возможности широко распространять закрытые библиотеки в бинарном виде.

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

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

На счёт Антроида и прочих мобильников - тут большую роль играют вопросы безопасности.
Т. е. разработчик ОС стремится сделать так, чтобы установленная клиентом прога не убила ОС и устройство, не покоцала данных. Ну а этого для управляемых языков достичь существенно проще чем для С/С++.

[gengzu]

Те же открытые исходники и так гарантируют переносимость - так что самый большой плюс отпадает.

увы, но очень плохо гарантируют. переносимость исходников дело весьма муторное. из-за разных особенностей платформы код обрастает тоннами #define и другими костылями. а красивое и правильное кроссплатформенное ПО большинство разработчиков писать не умеет.

На счёт Антроида и прочих мобильников - тут большую роль играют вопросы безопасности.
Т. е. разработчик ОС стремится сделать так, чтобы установленная клиентом прога не убила ОС и устройство, не покоцала данных. Ну а этого для управляемых языков достичь существенно проще чем для С/С++.

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

[Tonal]

Те же открытые исходники и так гарантируют переносимость - так что самый большой плюс отпадает.

увы, но очень плохо гарантируют. переносимость исходников дело весьма муторное. из-за разных особенностей платформы код обрастает тоннами #define и другими костылями. а красивое и правильное кроссплатформенное ПО большинство разработчиков писать не умеет.

А не то же самое мы имеем с разными версиями Java + разные версии установленных библиотек?
Вон Java в Андроиде так просто бинарно не совместима с остальными - за что Oracle на него и наезжает ИМХО...
Или попробуй Eclipse под gcj пускануть - тоже то ещё веселье.
И про неумение разработчиков писать «красивое и правильное ПО» - дык это от языка не зависит.

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

Как-то всё в куче...
Ежели ВМ (виртуальная машина) не использует процессорные средства многопоточности, получится в лучшем случае кооперативная многозадачность - та, что была в Win 3.x и любой поток с тяжелыми вычислениями или вводом/выводом застопорит всю остальную ВМ.
А ежели использовать - дык непонятен профит от ВМ - те же переключения с сохранением/восстановлением + накладки виртуализации.

В многозадачке Java может выиграть только одним - у неё есть ключевое слово synchronized и базовая поддержка в стандартной jre. Т. е. не особо задумываясь можно быстро написать многопоточный код.
При этом не доступно тонкое управление потоками какое есть в некоторых ОС-ях.
Например, попробуй стандартными средствами задать размер стека потока или приоритет.
Так что грамотный код на нативных языках будет всяко производительнее.
Хотя и напортачить при этом легче.

К тому же самая быстрая ВМ заточенная на многозадачность не JVM а машина Erlang-а.

[Gengza]

Как-то всё в куче...
Ежели ВМ (виртуальная машина) не использует процессорные средства многопоточности, получится в лучшем случае кооперативная многозадачность - та, что была в Win 3.x и любой поток с тяжелыми вычислениями или вводом/выводом застопорит всю остальную ВМ.
А ежели использовать - дык непонятен профит от ВМ - те же переключения с сохранением/восстановлением + накладки виртуализации.

ты путаешь несколько потоков в пределах одного процесса, и несколько процессов. это разные сущности.
один процесс спокойно может паралелить выполнение своих потоков на разные ядра, при этом не переключая контекст выполнения. в этом и есть профит.
Пользователь решил продолжить мысль 16 Сентября 2011, 12:56:33:

А не то же самое мы имеем с разными версиями Java + разные версии установленных библиотек?
Вон Java в Андроиде так просто бинарно не совместима с остальными - за что Oracle на него и наезжает ИМХО...
Или попробуй Eclipse под gcj пускануть - тоже то ещё веселье.
И про неумение разработчиков писать «красивое и правильное ПО» - дык это от языка не зависит.

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

[Axa-Ru]

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

Ежели ВМ (виртуальная машина) не использует процессорные средства многопоточности, получится в лучшем случае кооперативная многозадачность - та, что была в Win 3.x и любой поток с тяжелыми вычислениями или вводом/выводом застопорит всю остальную ВМ.

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

Такая вот полемика с мнгновенной заменой предмета спора.

[Gengza]

Такая вот полемика с мнгновенной заменой предмета спора.

ты о чем? где тут подмена чего либо?