Java vs C, C++ - обсуждение на форуме НГС Краснодар

НГС.Форум Компьютеры Интернет Связь Околокомпьютерные темы

Java vs C, C++

4047

20

v.i.p.

15 октября 2010

Поднимаю тему в силу необходимости определиться какой набор инструментов принять для дальнейшей работы на ближайшие лет 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. Толковых прогеров на С++ - уже не осталось.

Ответить

P

activist

15 октября 2010

Требовательность у java к ресурсам относительная, плюс на всякие там вычисления процент времени небольшой уходит, дольше будете передавать/получать данные. Поэтому про скорость лучше не закорачиваться(если же найдется сильно узкое место, то его можно на C вынести). Про скорость разработки - это зависит от конечного исполнителя и что конкретно нужно, если с нуля начинать, то наверно на java разработка будет быстрее. Надежность С я бы не преувеличивал - она напрямую зависит от исполнителя, а найти опытного и толкового будет трудновато. Так что я за java.

Ответить

guru

15 октября 2010

общим количеством около 30 гигабайт недокументированного исходного кода

Внушает...

+1 за Java. Я в свое время перешел с С++ на Java и ни разу не оглядывался.

Ответить

v.i.p.

18 октября 2010

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

:миг:

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

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

:улыб:

Ответить

P

activist

18 октября 2010

Насколько, отсутствие множественного наследования Явы сказывается на "неудобности" программирования.

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

Ответить

K

guru

18 октября 2010

Насколько, отсутствие множественного наследования Явы сказывается на "неудобности" программирования.

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

PS
Я б лично в таком варианте на C# глядел. На нем интерфейс в нормальных клиентах (Win32) проще делать. Правда, если все это web-страницы - то тут придется посмотреть на стоимость содержания серверов, тут юникс скорее всего будет дешевле, серверная винда не дешевая, а на юниксе шарпа можно сказать нет.

Ответить

K

guru

18 октября 2010

но выясняется, что реализация счетных алгоритмов на PHP - практически дает результат хуже чем под ДОС...

Вот это не понятно. В каком смысле результат "хуже"?

Ответить

v.i.p.

19 октября 2010

Дольше или так же.

Ответить

v.i.p.

19 октября 2010

реализация счетных алгоритмов на PHP - практически дает результат хуже чем под ДОС

Имхо, чтоб это понять, не нужно было реализовывать на PHP :улыб:

:улыб:

В ДЕЙСТВИТЕЛЬНО больших проектах, как ни парадоксально, я бы выступил тож за Яву... хотя Си, конечно, больше люблю

Ответить

v.i.p.

21 октября 2010

Сделали пробный перенос на Яву. Ну даже мне понравилось... :миг:

:миг:

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

Спасибо всем, тему можно закрывать.

Ответить

v.i.p.

26 октября 2010

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

:хммм:

Ответить

guru

26 октября 2010

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

QT3 - это библиотека GUI? А в Java вы используете что, Swing?

Ответить

A

guru

27 октября 2010

Отнюдь, Qt это не только GUI

Ответить

v.i.p.

27 октября 2010

Я жабу вообще не знаю, почему и задавал вопрос... Просто на С, С++ - есть куча разных готовых решений, в той же стандартной поставке Линукса. Разрабатывая что-то свое - этим дегко можно пользоваться. А вот как с Явой с этим?

Ответить

veteran

27 октября 2010

что вы понимаете под событиями?

В яве тоже многое есть, если не все.

Ответить

v.i.p.

27 октября 2010

Классику. Взаимодействие разных частей программы между собой "асинхронным" способом. В приложении к сайтостроению - пришел запрос с нажатым submit - сделали чего надо, вернули страничку (например "данные изменены") и "заодно" сгенерили событие. Которое обрабатывается другой частью ПО сайта "асинхронно" (например по результату изменения - запускается длинный цикл обработки "смежных" данных), например так.

Ответить

veteran

27 октября 2010

jms посмотрите

Ответить

guru

27 октября 2010

Отнюдь, Qt это не только GUI

Любопытно, что если мы откроем страницу Qt Jambi (что, как я понял, Qt для Java), то там Qt именуется "графическим фреймворком" :миг:

:миг:

http://ru.wikipedia.org/wiki/Qt_Jambi

Ответить

A

guru

28 октября 2010

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

Я же написал "не только", а не "вапще не GUI" :миг:

:миг:

А за формулировки аффтаров на педивикии я ответственности не несу :tease:

:tease:

Ответить

member

28 октября 2010

Меня как раз и интересует на что переносить чисто счетные задачи... ну вот на прошлой неделе, попробовали кое-что на Яве... внушает.

Может вам Скалу начать осваивать? Да и джавой и C# она интегрируется.

Ответить

v.i.p.

29 октября 2010

Посмотрел, спасибо. Хороший пакет, чувствуется основательность проектирования... может и то, что надо. Правда остался непонятным вопрос реализации МОМ сервера... он что, отдельный и платный?

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

:миг:

Ответить

НГС.Форум Компьютеры Интернет Связь Околокомпьютерные темы