Это частный случай, когда пользователь и есть заказчик у разработчика. Т.е. ты отстаиваешь позицию заказчика. В большинстве случаев это не так. Пользователь не заказывает разработку софта, а лишь выбирает под задачу программу из доступных. И тут ему совершенно безразлично сколько времени заняла разработка. Кроме того, этому заказчику может понадобиться в будущем (с развитием бизнеса) грабить 830 караванов в минуту. И тут его дешёвая и быстронаписанная поделка может сдуться. Тогда возникнет необходимость обновлять аппаратное обеспечение. К слову, у меня на КПК Zaurus (64Mb RAM) 5и летней давности весьма шустро крутится софт последней версии, буквально на днях обновлялся. И как пользователь я очень ценю это. В то время, как какая-ть одна современная mono-поделка вроде пацанки съедает ~50мб памяти.

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

Это не вопросы надёжности/бещопасности

>А если слетело чего - так вот тебе полный стек вызовов, обанализируйся.

Вот тебе дебаг флаг и gdb.

>Ты упускаешь только то, что "мастерством автора" обычно называют то самое неоправданное лихаченье.

Не надо бросаться в крайности

Быстрее - я имел в виду в обслуживании быстрее: быстрее сделать, быстрее починить если сломалось..

> Софт на java исполняется примерно со скоростью аналогичного софта на С. При этом он на порядок больше ест памяти и значительно дольше стартует. Пользователь ликует.

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

Контраргументируй тоды :)

> Факт здесь один: на С проще сделать ошибку в работе с памятью.

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

> А конечный результат будет зависеть от мастерства автора и качества отладки. Если самолётом сложно управлять, это не значит, что пилот разобъётся быстрее водителя авто. Кто-то может летать десятилетиями, а какой-ть лихач разобъёт свой суперкар на первом повороте.

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

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

Да ну? Ну вот представь себе - ты конечный пользователь. Тебе нужна программа для того, что бы автоматизировать твои бизнес-процессы. Допустим программа должна.. ну, скажем, грабить корованы. В целом система, использующая данную программу должна грабить 83 корована в минуту. Какая тебе разница сколько извращался разработчик что бы получить нужный тебе функционал? Ты смотришь на цену. А цена у более простого решения будет ниже. Более того, простое решение будет надежнее и легче в поддержке, что тебе как пользователю немаловажно - ведь каждая минута простоя означает для тебя 83 неограбленных корована. > Насчёт стоимости - пользуемся open source и этот критерий отпадает.

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

не совсем так. С ростом сложности программы трудозатраты возрастают совсем не линейно. Если "хеловорд" по сложности примерно одинаково сотворить на любом наречии, то сложность реализации более сложных алгоритмов, типа например быстрой сортировки, на вменяемых языках на порядки (!) проще ( http://www.haskell.org/haskellwiki/Introduction ). Чем больше людей вовлечено в проект, тем сложнее им управлять. Свыше некоего порога сложности, зависящего от конкретного коллектива, главным образом способов руководства, проект данным коллективом реализовать практически невозможно. На пользователе "проще и дешевле" отражается в основном тем, что ползователь просто остаётся без надлежащего качества программ. Готовую, уже реализованную программу, ползователь конечно не может характеризовать по сложности и стоимости, точно так же как для дикаря нету разницы меж "Запорожцем" и "Ягуаром", это одна из проблем ИТ, порождающая такие угрёбища, как сабж.

> 2. С чего вдруг поделки на java надёжнее и безопаснее, чем, например, на С?

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

> 3. А про быстрее я не понял аргумента. Софт на java исполняется примерно со скоростью аналогичного софта на С. При этом он на порядок больше ест памяти и значительно дольше стартует.

Это так, да. Следует ещё учесть, что скорость выполнения обычно менее важна, чем потребление памяти. Современный проц на десктопных задачах на 99% свободен, а вот оперативы много не бывает. Это основная причина, по которой всё ещё продолжают юзать С/С++ на многих десктопных задачах.

Ну да, нормальные-то пишут программы на микрокодах, ну максим на ассемблере

> В каком смысле??

Следующие версии оракел открывать не собирается, а openjdk поддерживать они и не собираются.

А зачем объяснять? Всё и так очевидно.

>А что тормозят - таковы реалии, возьми современный автокад, ну ни на java он был написан, не кроссплатформенный он и что он не тормозит из-за этого?

А кто сказал, что он тормозит, лол? В 2000-м на селероне 300 просто летал. А сейчас, конечно, на net переписали поэтому и тормозит.

>Вот я поэтому и говорю, что java не идеал, но все-таки это лучше чем .NET.

Чем лучше? Ненативными виджетами и полузакрытостью? Алсо, gcc лучше их обоих. Зачем тащить это УГ?

а разве "произведения на С" уже включают в себя ОС с набором драйверов? Один хрен приходится ОС ставить. И компьютер, кстати, тоже приобретать надо - само по себе оно работать не будет :)

Ты это "партийным" объясни.

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

Ну опять не пойму, причем тут открытые и закрытые коды. Открытую прогу кто мешает компилить один раз под все платформы? А кто мешает писать закрытую на Qt/gtk+ и компилить для разных платформ? Инструмент тут совершенно не при чем.

А что тормозят - таковы реалии, возьми современный автокад, ну ни на java он был написан, не кроссплатформенный он и что он не тормозит из-за этого? Да тормозит еще как из-за того что был на .Net написан. Дак уж лучше бы он был тогда на java написан, тормозил бы точно также как и на .NET, но хоть на никсах бы можно было его без проблем пользовать. Вот я поэтому и говорю, что java не идеал, но все-таки это лучше чем .NET. Лучше уж худая кроссплатформенность чем вообще никакой, но тоже с тормозами из-за "современных тенденций" на примере современного автокада.

Каких зол? Есть gcc, зачем выбирать?

>А почему java продукт для проприетарщиков?

А для кого же ещё? Закрытую поделку надо компилить только один раз, а не под все платформы. То, что из-за этого прога жрёт память и тормозит - их не волнует. Главное впарить.

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

А с моной и джавой - на них мало писать, их программы исполняются в их среде. Т.е. для "проигрывания твоего произведения", пользователю придётся как-то приобретать произведение, которое сможет проигрывать твои произведения.

Согласен, сам сижу на генте :-)

>Нафига такой изврат?

Прок очевиден: при удобствах работы с памятью в яве получаем скорость исполнения кода близкую к С. Короче говоря, разрабатывать проще (читай дешевле), а на конечных пользователей навалить.

>Жесть какая-то.

Согласен, я сам не фанат явы, моны и всех аналогов.

Да я и сам Qt люблю, все таки приверженность к kde обязывает любить Qt. Дак ведь заставь лентяев хоть на той же Qt писать, сразу расплачутся, что все рано C# и .NET проще, дак пусть хоть на "неполитизированной" java уж тогда ваяют, вместо .NET/Mono, как говорится из двух зол меньшее. :)

>Так, жалкое полузакрытое поделие для пропитетарщиков

А почему java продукт для проприетарщиков? Проприетарщину никто не мешает писать и на Qt/gtk+ так как это уже решение разработчика. А открытую программу можно и на MFC писать. Тут не причем используемая технология совершенно.

В каком смысле??

Она и ява не нужна. Так, жалкое полузакрытое поделие для пропитетарщиков. Открытый софт компилится под все платформы, где есть gcc. Зачем искусственно тормозить прогресс? А если уж речь зашла про простоту разработки, то на том же Qt можно наваять гуй не копаясь в кишках с++, не говоря уж про всякие питоны и перлы.

Может тогда лучше сразу генту поставить? Нафига такой изврат? Алсо, программ на моне практически нет, поэтому если хранить каждую из 5000 да ещё в кэше. Жесть какая-то.

А хуле там ещё делать?

а про функцию daa() уже забыли??

Это ты про JIT? Только ты не забывай, что её надо копмилить и ещё хранить в памяти. Вопрос только в том, ради чего?

и часто ты у знакомых или в интернет-кафе пускаешь веб-сервера?

А что не читерство? Запуск виртуальной машины вместо использования нативного софта? Алсо, у разрабов фф руки из жопы. Это давно известный факт. Не удивлюсь, что они намеренно его тормозят под не-вындовс осами.

Если мне с собой таскать столько софта, то маленькое ядро линукса притащить не проблема.

Это читерство :) Я слышал, что вендовый файрфокс под вайном работает быстрее нативного ффокса

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

А ещё проще писать под виндовс и вместо виртуальной машины юзать вайн.

Да у меня какбэ весь дистрибутив из них состоит. Зачем мне поддержка виндовс, костыли в виде вм и поделки тупых студентов?

А что, у нас ядро исполняет *.exe напрямую?

То-есть MONO-тест в виртуалке скомпиленой gcc работает на AMD быстрее, чем c-тест скомпиленный icc.

Великолепно.

Много ты знаешь linux-only приложений? Кому нужны такие приложения?

Кстати, жаво поддерживать проще чем сишный софт.

Как виртуальная машина на си может выполнять код быстрее си?

А зачем нужно жаво для linux-only приложений?

Любая реклама вводит заблуждение людей, далёких от понимания предмета рекламы.

ЗЫЖ особенно порадовала аргументация в виде

1. "содержит современные возможности вроде сборщика мусора, который делает очень легким написание кода по сравнению с malloc()-счастливчиками C и C++"

2. "Студенты, изучающие Visual Studio .NET в университетах, могут использовать полученные навыки и напрямую применять их для создания и улучшения свободного ПО в новых дистрибутивах Ubuntu"

Итого: автор статьи вводит заблуждение людей, далёких от программирования. Дискас.

2. С чего вдруг поделки на java надёжнее и безопаснее, чем, например, на С? Спорный вопрос. Факт здесь один: на С проще сделать ошибку в работе с памятью. А конечный результат будет зависеть от мастерства автора и качества отладки. Если самолётом сложно управлять, это не значит, что пилот разобъётся быстрее водителя авто. Кто-то может летать десятилетиями, а какой-ть лихач разобъёт свой суперкар на первом повороте.

3. А про быстрее я не понял аргумента. Софт на java исполняется примерно со скоростью аналогичного софта на С. При этом он на порядок больше ест памяти и значительно дольше стартует. Пользователь ликует.