Java vs C, C++
3897
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 - практически дает результат хуже чем под ДОС...Вот это не понятно. В каком смысле результат "хуже"?
Сейчас читают
Перерегистрация авто
87817
21
Куда идти учиться после школы? Оставаться в 9 или идти до 11?
271667
227
Обсуждение конкурса "Массажист для пани Марки"
11052
133
реализация счетных алгоритмов на PHP - практически дает результат хуже чем под ДОСИмхо, чтоб это понять, не нужно было реализовывать на PHP
В ДЕЙСТВИТЕЛЬНО больших проектах, как ни парадоксально, я бы выступил тож за Яву... хотя Си, конечно, больше люблюСделали пробный перенос на Яву. Ну даже мне понравилось...
По скорости - так "на уровне", по объему - "терпимо", по ресурсам - "хотелось бы лучше, но пойдет", по времени писания - "просто круть"... правда, остается подозрение, что отдельные куски придется оставлять на чистом С.
Спасибо всем, тему можно закрывать.
По скорости - так "на уровне", по объему - "терпимо", по ресурсам - "хотелось бы лучше, но пойдет", по времени писания - "просто круть"... правда, остается подозрение, что отдельные куски придется оставлять на чистом С.
Спасибо всем, тему можно закрывать.
Ну вот небольшое разачоравание все-таки наступило. Нужна система событий... на Яве надо писать, а на С, С++ - есть "готовое" решение - библиотека QT3 Линукса... подходит "как родная"...
Нужна система событий... на Яве надо писать, а на С, С++ - есть "готовое" решение - библиотека QT3 Линукса... подходит "как родная"... :(QT3 - это библиотека GUI? А в Java вы используете что, Swing?
Я жабу вообще не знаю, почему и задавал вопрос... Просто на С, С++ - есть куча разных готовых решений, в той же стандартной поставке Линукса. Разрабатывая что-то свое - этим дегко можно пользоваться. А вот как с Явой с этим?
что вы понимаете под событиями?
В яве тоже многое есть, если не все.
В яве тоже многое есть, если не все.
Классику. Взаимодействие разных частей программы между собой "асинхронным" способом. В приложении к сайтостроению - пришел запрос с нажатым submit - сделали чего надо, вернули страничку (например "данные изменены") и "заодно" сгенерили событие. Которое обрабатывается другой частью ПО сайта "асинхронно" (например по результату изменения - запускается длинный цикл обработки "смежных" данных), например так.
Отнюдь, Qt это не только GUIЛюбопытно, что если мы откроем страницу Qt Jambi (что, как я понял, Qt для Java), то там Qt именуется "графическим фреймворком"
http://ru.wikipedia.org/wiki/Qt_JambiВключает в себя все основные классы, которые могут потребоваться при разработке прикладного программного обеспечения, начиная от элементов графического интерфейса и заканчивая классами для работы с сетью, базами данных и XML. Qt является полностью объектно-ориентированным, легко расширяемым и поддерживающим технику компонентного программирования.Я же написал "не только", а не "вапще не GUI"
А за формулировки аффтаров на педивикии я ответственности не несу 
Меня как раз и интересует на что переносить чисто счетные задачи... ну вот на прошлой неделе, попробовали кое-что на Яве... внушает.Может вам Скалу начать осваивать? Да и джавой и C# она интегрируется.
Посмотрел, спасибо. Хороший пакет, чувствуется основательность проектирования... может и то, что надо. Правда остался непонятным вопрос реализации МОМ сервера... он что, отдельный и платный?
Ну и как обычно для типовых библиотек - как основу использовать можно, но все равно допиливать напильником, пардон - программистом.
Ну и как обычно для типовых библиотек - как основу использовать можно, но все равно допиливать напильником, пардон - программистом.
ТОП 5
1
2
3
4