Интересно чем вызваны такие ограничения ??? сэкономить ведь на STL все равно нельзяСообщение от homo ludens
Переносимость ? Всмысле ? Java что плохо переносится, а переносимость С++ отличается от С ?
| ||
Тема: Язык программирования
Интересно чем вызваны такие ограничения ??? сэкономить ведь на STL все равно нельзя
Переносимость ? Всмысле ? Java что плохо переносится, а переносимость С++ отличается от С ?
Сообщение от homo ludens
Но то, что я видел лично - там, где требуется гарантированная переносимость в сочетании с эффективностью и полнотой языка - ни С++, ни джава не работают.
Увы.
Скажи год, в который ты работал, инструментарии и версию ждки.
Имеет ли смысл проходить сертификацию ? Если имеет то какую ?
Для джавистов слышал престижной считается сертификация Sun, а какая для сишников ?
Этономия в первую очередь на шаблонах, но и на STL сэкономить очень даже можно и многие это делают.Интересно чем вызваны такие ограничения ??? сэкономить ведь на STL все равно нельзя
Несколько лет назад провел такой эксперимент - взял случайный кусок Сизифа - большой русский репозиторий пакетов для Linux.
Выделил оттуда пакеты для разработки.
Из них написано на С - подавляющее большинство.
Выбрал те, что написаны на С++. Их оказалось немного.
Выкинул оттуда пакеты-оболочки, которые не создают функциональности, а лишь являются адаптерами к необъектным библиотекам.
Осталось почти ничего, на фоне которого ярко сиял mysql. ;-)
Затем попробовал выбрать из них те, которые используют STL.
ИХ ПОЧТИ НЕ БЫЛО!!! Практически все пакеты пытались использовать собственные хеши и деревья!!!
Странно, почему бы это?
Эксперимент наверное устарел, кроме того сегодня С++ все-таки более зрелый. Однако факт имел место быть.
Как я писал - гарантированная переносимость в сочетании с эффективностью. Джава эффективна?
А переносимость С++ действительно отличается от С, все таки С++ моложе будет.
Последний раз видел разное поведение шаблонов под неймспейсами в разных версиях компилятора, каждая из которых соответствовала C++98.
Работал очень давно, когда джава только появилась. Концепция понравилась, но мои задачи тогдашняя джава не решала, выглядела сыро, поэтому наваяв пару апплетов про нее забыл.
А вот потом мне пришлось встать по другую сторону баррикады - со стороны заказчика. После того как я там постоял некоторое время у меня сложилось очень четкое мнение по поводу ОО вообще и джавы в частности.
Если интересно могу рассказать пару success story.
The future is already here - it is just unevenly distributed. (c) W. Gibson
Рассказывай
Все имена и трейдмарки пропущены.
success story #1 - backoffice
В прошлом году закончила свой рабочий цикл одна моя поделка - скромный такой сервер для расчета и распределения аналитики в реалтайме. Делал я ее 7 лет назад и это был мой первый продукт, написанный после длительного ухода из программирования. Потому написан был ногами и с сорванными сроками. Но написан и работал много лет, пережив несколько смен хостингов. Время прошо - готова принципиально новая версия, а этот код радостно идет на свалку.
И я решил его продать. Полазив по инету нашел арабов из относительно известной на американском рынке софтовой конторы, которым было интересно, они заинтересовались покупкой по кускам и показали их аналог, предназначенный для продажи на рынках US. Написанный на джаве.
Официальные требования к аппаратуре - Quad Xeon, 4G RAM в расчете 100 одновременных клиентских подключений.
Однако этого мало, так как на всякий случай нужен запасной сервер, работают они в паре (кластером?).
Я не смог продать свое творение арабам. Мой сервер был написан на С и они просто не знали бы, что с ним делать. В 2000-м году я не знал сколько клиентов он в одиночку тянет, но время показало - что несколько сотен на обычном гиговом пне с 0.5Г памяти точно, а больше просто никогда и не было. Запаска ему была не нужна.
Если бы тогдашний заказчик взял что-то на джава - он не смог бы организовать те бизнес-процессы, которые у него есть. Более того, если бы сегодня ему пришлось повторить этот выбор - результат был бы тот же.
У заказчика была такая возможность, но он от нее отказался и сегодня слово джава воспринимает как ругательное.
success story #2 - frontoffice
Есть одна уважаемая зарубежная финансовая фирма. Очень большая. Цифры на сайте не смотрел, но со слов людей, которые пользовались их услугами - суточный оборот 6000 M$. Т.е. до фига ;-)
Тем, кто соневается в цифре - 6 миллиардов доларов в сутки объясню, что компания специализируется в т.ч. и на деривативах.
Доступная клиенту часть их софта - это терминал, который рассчитан на постоянное получение информации в реал-тайме (десятки информационных посылок в секунду) и на отдачу распоряжений. Тоже в реалтайме.
Терминал, как терминал, все работало неплохо, но вот фирма решила провести модернизацию. Опять таки по словам ее клиентов - стоимость модернизации софта - десятки М$. Тоже неслабо.
Сказано - сделано. Результат - джава-терминал, который весит более 40 Мб и запускается на средней машине до 15 минут!
Те несколько человек моих знакомых, которые работали с этой фирмой - заморозили отношения с ней в течении недели. Если я произнесу при них слово Джава - меня просто побьют.
Притом сам терминал в логике и исполнени неплох - только очень уж громоздок.
Поэтому когда я читаю про быструю кваку на джаве, я не то что не верю, мне это пофиг.
Есть realworld, realbiz и realmoney.
Если бы я был програмистом или системным интегратором я бы продавал системы на джаве - это очень выгодно по срокам и затратам. Но если бы я был заказчиком - я бы их просто не покупал. ;-)
The future is already here - it is just unevenly distributed. (c) W. Gibson
За 5 лет многое поменялось, и как я вижу на сегодняшний день 8 фирм из 10 пишут на яве.
homo ludens,
Если руки ростут из чуть ниже спины , то при чём тут java ?
В опровержение всего одно слово ebay
Один из самых больших Java проектов в public интернете.
Около 212.000.000 зарегистрированных пользователей.
Около одного биллиона фотографий.
Количество просмотров превышает 1 биллион страниц в день.
Ebay хранит около двух петабайт информации ( 2.000.000.000.000 ).
26 биллионов SQL запросов ежедневно.
http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
И теперь спрашивается, при чём тут java?
homo ludens,
и кстати сравнивать например javу 1.2 и java6 mustang просто нет смысла.
Не стоит оперирировать фактами семилетней давности.
homo ludens,
http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf
Заглавие 15(16)-ой страницы тебя и THRESHE очень сильно озадачит.
Чото я не заметил причин перехода с С++ на Java разве что :
Оно и понятно с развитием сайта необходимо было привлекать новых программеров, а разбираться в огромном и написанном чужыми руками коде нехотелось да и код устарел. Вот и решили старое ядро переписать. Дешевле это сделать на Java. Вот и результатAllowed for rapid training and deployment of new engineers
Да кстати вот еще вспомнил кое что со слов знакомого Java-программера работающего в Америке. В 2000-2002 был бум на Java-программистов. Их привлекали со стороны обучали и.т.п Потом бум прошел, но машина уже раскрутилась и был переизбыток тех же Java-программеров. Вот и eBay наняли их подешовке...
THRESHE,
cмена технологий и репозитория сама по себе уже не может быть дешёвой.
Спорить дальше на эту тему у меня желания нет.
Считаете себя первой нацией программистов на свете - флаг в руки.
А мне надо работать .. просто работать.
Да не считаю я себя "первой нацией программистов на свете". Мы же обсуждаем различия плюсы и минусы... Не понимаю я такой категоричности
1. 7-ми летней давности была моя прикладуха, у арабов был продукт в прошлом году. Может они его писали 10 лет, не знаю.
2. frontoffice той крутой фирмы был переписан где-то 2004-й или 2005-й.
По поводу современного состояния дел.
Я не утверждаю, что Джава -это плохо. Наоборот, я считаю, что это красивый язык, дающий много возможностей программисту, гораздо менее эклектичный, чем С++.
Но, на основании ЛИЧНОГО опыта (ебэй юзал только из Web-интерфейса) могу повторить.
1. Программисту он выгоден.
2. Заказчику он выгоден только с предельно коротким временем жизни ПО. Иначе - скрытые расходы, иногда очень большие вплоть до невозможности практического использования софта. Про это программист заказчику предпочитает не напоминать.
И еще. Есть такая ниша - RAD. Когда-то в этой нише рулили Дельфи и VB. Теперь к ним присоединилась Джава (и дотнет платформы).
Соответственно качество приложений в области RAD всегда будет ниже, чем в других - это обусловлено не столько качеством языка, а бизнес-процессами скоростной разработки программ.
Я привел только два примера, с которыми повторяю - сталкивался лично. В связи с чем теоретические публикации фанатов и материально заинтересованных лиц пропускаю мимо ушей. Покажите продукт, который быстрее и экономичнее, чем аналогичная реализация на С(++) программистами той же квалификации, продукт, который лучше реализует бизнес-процесс и более выгоден для заказчика в долгой перспективе. Кваку не предлагать.
PDF с Ebay посмотрел, только там проблема не в С++, а в базах данных. Работать на SQL в таких масштабах - самоубийство.
Опять таки, никак не противоречит тому что я сказал - Джава очень хорошо выглядит, если у вас стоит Deep Blue.
А что у нас стоит на eBay? Внимательно посмотрели? ;-)
Теперь следующий момент по eBay и С++: "hitting compiler limits on number of methods per class".
гм. это был правильный дизайн??? Я понимаю, проблема разбиения графа в применении к таксономии ни у Буча, ни у GOF не рассматривается. А жаль. ;-)
PS для сравнения как разные крупные компании решают свои проблемы предложу сравнить рекламку eBay с более серьезной статьей google file system:
http://labs.google.com/papers/gfs-sosp2003.pdf.
The future is already here - it is just unevenly distributed. (c) W. Gibson
homo ludens, THRESHE,
"Странный этот мир, где двое смотрят на одно
и то же, а видят полностью противоположное"
http://www.orator.ru/rass14.html
Лучше займитесь работой.
Удачных проектов.
Работать увы не могу - в отпуске, сижу на чемоданах, потому и клаву здесь топчу.
Чжуан Чжоу:
Удачи.Положим, мы затеяли с тобой спор, и ты победил меня, а я не смог
переспорить тебя, значит ли это, что ты и в самом деле прав, а я на самом деле не прав? А если я победил тебя, а ты не смог переспорить меня, значит ли это, что прав именно я, а ты не прав? Обязательно ли кто-то из нас должен быть прав, а кто-то не прав? Или мы можем быть оба правы и оба не правы? И если мы сами не можем решить, кто из нас прав, а кто нет, то другие люди тем более не сделают этого за нас. Кто же рассудит нас? Если придет кто-нибудь, кто согласится с тобой, то как ему рассудить нас? А если кто-то третий будет согласен со мной, то и ему не удастся нас рассудить. Если же, наконец, позвать того, кто не согласен ни со мной, ни с тобой, то такой человек тем более не поможет нам установить истину. А если позвать того, кто согласится
со мной и с тобой, то мы опять-таки не доберемся до истины. Выходит, ни я, ни ты, ни кто-либо другой не можем установить общую для всех истину. На кого же нам надеяться?
Противоречивые суждения о вещах друг друга поддерживают, а если они перестают поддерживать друг друга, следует привести их к равновесию на весах Небес.
The future is already here - it is just unevenly distributed. (c) W. Gibson
У меня каникулы, тоже делать нечего
А napTu3aHа явно на философию тянет
Последний раз редактировалось THRESHE; 31.01.2007 в 13:34.
с чем это связано ? я думал что у gcc переносимость одинаковая для с и с++
Я тоже так думал. ;-)
Последний раз лично видел как не компилировался код между разными версиями gcc (3 и 4), правда при флаге GNU_SOURCE, что может что-то объяснить.
Кроме того часто сталкивался с фразой типа
(с) wxwidgets FAQ.Not all compilers can handle templates adequately so it would dramatically reduce the number of compilers and platforms that could be supported.
Специально несовместимости не исследовал, надо было код делать, но вот сейчас нашел в старом коде
#define GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)
#if GCC_VERSION >= 40000
namespace xxx
{
namespace yyy
{
#endif
template <> int abstRec<zzzzz>::import(char* q)
{
...
}
....
#if GCC_VERSION >= 40000
}
}
#endif
явно что-то было связано с переносимостью. ;-)
обычный С с флагом ansi у меня компилировался всегда и везде.
Исключение - если неверно сделать список #include,
где-то например где-то можно не включать
#include <string.h>
для строковых функций, так как файл уже вложен в stdlib.h, включенный ранее. А где-то потом на другой платформе эти грабли сработают. Но этой ситуации я лично не видел - люди рассказывали.
В принципе С++ развивается и рано или поздно эти несовместимости уйдут. Когда-то я показывал знакомым код, генерируемый конструктором С++ - и люди уходили в ужасе. ;-) Сейчас там все нормально.
Проблема возраста.
The future is already here - it is just unevenly distributed. (c) W. Gibson
Ваши права
Ответить с цитированием
Социальные закладки