На информационном ресурсе применяются cookie-файлы. Оставаясь на сайте, вы подтверждаете свое согласие на их использование.
Java vs C, C++
4240
20
tolstopuz
v.i.p.
Поднимаю тему в силу необходимости определиться какой набор инструментов принять для дальнейшей работы на ближайшие лет 10-15...
Дано: есть корпоративный софт, писанный на протяжении последних 15-и лет... В работе: ДОС/Paradox - C - .bat, Deplhi - C++ - InterBase, MySQL - PHP + ZF, есть много чего просто на Bash... общим количеством около 30 гигабайт недокументированного исходного кода... "около" - потому как общий набор ПО - неизвестен никому... у каждого сотрудника есть свои "любимые" прибамбасы, о которых уже мало кто помнит...
На сегодня, значительная часть ПО переведена в связку PHP-ZF-MySql... но выясняется, что реализация счетных алгоритмов на PHP - практически дает результат хуже чем под ДОС...
Для себя сейчас вижу архитектуру в виде:
С++ (счетные) - PHP(интерфейсы) - MySQL (хранение), но есть вариант вместо С++ применить Java... с последней не знаком, потому и возник интерес.
П.С. перечитал море холиваров на озвученную тему, но вынес из них 2 момента:
1. Java - гораздо требовательнее к ресурсам и может (потенциально) проигрывать в скорости. Плюс - скорость разработки - выигрыш "в разы". C++ - надежность, скорость, низкоресурсные решения (а стало быть большая масштабируемость в будущем) за счет скорости разработки...
2. Толковых прогеров на С++ - уже не осталось.
Дано: есть корпоративный софт, писанный на протяжении последних 15-и лет... В работе: ДОС/Paradox - C - .bat, Deplhi - C++ - InterBase, MySQL - PHP + ZF, есть много чего просто на Bash... общим количеством около 30 гигабайт недокументированного исходного кода... "около" - потому как общий набор ПО - неизвестен никому... у каждого сотрудника есть свои "любимые" прибамбасы, о которых уже мало кто помнит...
На сегодня, значительная часть ПО переведена в связку PHP-ZF-MySql... но выясняется, что реализация счетных алгоритмов на PHP - практически дает результат хуже чем под ДОС...
Для себя сейчас вижу архитектуру в виде:
С++ (счетные) - PHP(интерфейсы) - MySQL (хранение), но есть вариант вместо С++ применить Java... с последней не знаком, потому и возник интерес.
П.С. перечитал море холиваров на озвученную тему, но вынес из них 2 момента:
1. Java - гораздо требовательнее к ресурсам и может (потенциально) проигрывать в скорости. Плюс - скорость разработки - выигрыш "в разы". C++ - надежность, скорость, низкоресурсные решения (а стало быть большая масштабируемость в будущем) за счет скорости разработки...
2. Толковых прогеров на С++ - уже не осталось.
Требовательность у java к ресурсам относительная, плюс на всякие там вычисления процент времени небольшой уходит, дольше будете передавать/получать данные. Поэтому про скорость лучше не закорачиваться(если же найдется сильно узкое место, то его можно на C вынести). Про скорость разработки - это зависит от конечного исполнителя и что конкретно нужно, если с нуля начинать, то наверно на java разработка будет быстрее. Надежность С я бы не преувеличивал - она напрямую зависит от исполнителя, а найти опытного и толкового будет трудновато. Так что я за java.
общим количеством около 30 гигабайт недокументированного исходного кодаВнушает...
+1 за Java. Я в свое время перешел с С++ на Java и ни разу не оглядывался.
Понятно.
Меня как раз и интересует на что переносить чисто счетные задачи... ну вот на прошлой неделе, попробовали кое-что на Яве... внушает. Небольшой текстовый парсер (их есть у нас тоже) отработал на Яве со скоростью 3000строк в секунду... вместо 30 на софте, писанном еще под ДОС... и это на ООП, без какой-либо оптимизации кода. Писано было "в лоб". Щас, применим Касьянова...
Похоже, придется еще и Яву учить... просто, для меня лично С++ - старая, знакомая "лошадка".
Насколько, отсутствие множественного наследования Явы сказывается на "неудобности" программирования. В прошлом, на С++ - мне было очень удобно расширять классфы именно таким способом: "диван" - класс..., "чемодан" - класс, "раскладушка" - это наследник от ("диван","чемодан")... с соответствующим добавлением запретов для методов/акссесоров "спать", "занято" и "открыть/закрыть", "можно нести"...

Меня как раз и интересует на что переносить чисто счетные задачи... ну вот на прошлой неделе, попробовали кое-что на Яве... внушает. Небольшой текстовый парсер (их есть у нас тоже) отработал на Яве со скоростью 3000строк в секунду... вместо 30 на софте, писанном еще под ДОС... и это на ООП, без какой-либо оптимизации кода. Писано было "в лоб". Щас, применим Касьянова...

Похоже, придется еще и Яву учить... просто, для меня лично С++ - старая, знакомая "лошадка".
Насколько, отсутствие множественного наследования Явы сказывается на "неудобности" программирования. В прошлом, на С++ - мне было очень удобно расширять классфы именно таким способом: "диван" - класс..., "чемодан" - класс, "раскладушка" - это наследник от ("диван","чемодан")... с соответствующим добавлением запретов для методов/акссесоров "спать", "занято" и "открыть/закрыть", "можно нести"...

Насколько, отсутствие множественного наследования Явы сказывается на "неудобности" программирования.Ну по этому поводу наломали уже кучу копий, если кратко - то все через интерфейсы нормально делается. А если подробно - то в любой толковой книге.
Насколько, отсутствие множественного наследования Явы сказывается на "неудобности" программирования.Множественное наследование - зло. Все "выигрыши" и "красивые в теории решения" разбиваются о крайне высокую сложность поддержания такого кода, а именно это самое дорогое и актуальное в реальных системах, задача которых крайне отличается от примеров в учебниках и сборников этюдов.
PS
Я б лично в таком варианте на C# глядел. На нем интерфейс в нормальных клиентах (Win32) проще делать. Правда, если все это web-страницы - то тут придется посмотреть на стоимость содержания серверов, тут юникс скорее всего будет дешевле, серверная винда не дешевая, а на юниксе шарпа можно сказать нет.
но выясняется, что реализация счетных алгоритмов на PHP - практически дает результат хуже чем под ДОС...Вот это не понятно. В каком смысле результат "хуже"?
Сейчас читают
От независимой прессы.Обзор.
68943
467
Ночной дозор
270375
3204
Тигирькино гетто (вход на экскурсию только милым людям, флудить можно)
218350
999
реализация счетных алгоритмов на PHP - практически дает результат хуже чем под ДОСИмхо, чтоб это понять, не нужно было реализовывать на PHP

Сделали пробный перенос на Яву. Ну даже мне понравилось...
По скорости - так "на уровне", по объему - "терпимо", по ресурсам - "хотелось бы лучше, но пойдет", по времени писания - "просто круть"... правда, остается подозрение, что отдельные куски придется оставлять на чистом С.
Спасибо всем, тему можно закрывать.

По скорости - так "на уровне", по объему - "терпимо", по ресурсам - "хотелось бы лучше, но пойдет", по времени писания - "просто круть"... правда, остается подозрение, что отдельные куски придется оставлять на чистом С.
Спасибо всем, тему можно закрывать.
Ну вот небольшое разачоравание все-таки наступило. Нужна система событий... на Яве надо писать, а на С, С++ - есть "готовое" решение - библиотека QT3 Линукса... подходит "как родная"...

Нужна система событий... на Яве надо писать, а на С, С++ - есть "готовое" решение - библиотека QT3 Линукса... подходит "как родная"... :(QT3 - это библиотека GUI? А в Java вы используете что, Swing?
Я жабу вообще не знаю, почему и задавал вопрос... Просто на С, С++ - есть куча разных готовых решений, в той же стандартной поставке Линукса. Разрабатывая что-то свое - этим дегко можно пользоваться. А вот как с Явой с этим?
что вы понимаете под событиями?
В яве тоже многое есть, если не все.
В яве тоже многое есть, если не все.
Классику. Взаимодействие разных частей программы между собой "асинхронным" способом. В приложении к сайтостроению - пришел запрос с нажатым submit - сделали чего надо, вернули страничку (например "данные изменены") и "заодно" сгенерили событие. Которое обрабатывается другой частью ПО сайта "асинхронно" (например по результату изменения - запускается длинный цикл обработки "смежных" данных), например так.
Отнюдь, Qt это не только GUIЛюбопытно, что если мы откроем страницу Qt Jambi (что, как я понял, Qt для Java), то там Qt именуется "графическим фреймворком"

Включает в себя все основные классы, которые могут потребоваться при разработке прикладного программного обеспечения, начиная от элементов графического интерфейса и заканчивая классами для работы с сетью, базами данных и XML. Qt является полностью объектно-ориентированным, легко расширяемым и поддерживающим технику компонентного программирования.Я же написал "не только", а не "вапще не GUI"


Меня как раз и интересует на что переносить чисто счетные задачи... ну вот на прошлой неделе, попробовали кое-что на Яве... внушает.Может вам Скалу начать осваивать? Да и джавой и C# она интегрируется.
Посмотрел, спасибо. Хороший пакет, чувствуется основательность проектирования... может и то, что надо. Правда остался непонятным вопрос реализации МОМ сервера... он что, отдельный и платный?
Ну и как обычно для типовых библиотек - как основу использовать можно, но все равно допиливать напильником, пардон - программистом.
Ну и как обычно для типовых библиотек - как основу использовать можно, но все равно допиливать напильником, пардон - программистом.
