Jakub Kaniewski wrote:

> Wszystko co jest napisane w Javie da
> się przepisać w C++. Tylko problemem jest złożoność implementacji -
> jeżeli podobny problem zajmie w C++ 100 linii kodu, w Javie 20, a w
> Rubym 5 to jednak nie opłaca się wybierać tego pierwszego języka.

Jakoś nie potrafię sobie wyobrazić realnego problemu, którego rozwiązanie w
C++ byłoby 5 razy dłuższe niż w Javie. Chętnie zapoznam się z przykładem.
(oczywiście zakładam, że w C++ korzystam nie tylko z biblioteki
standardowej, ale również z innych, dostępnych za darmo na licencjach LGPL,
BSD itp.)

do góry

Użytkownik "Jakub Kaniewski" <j...@c...gmail.com> napisał w
wiadomości news:fo0c1e$k8n$1@inews.gazeta.pl...
>ale są też takie do których się nie nadaje (modułowe systemy biznesowe)
Dokładnie. Tworzone obecnie systemy są na tyle duże, że zmuszanie programisty do
tego, by pisząc aplikację biznesową skupiał się na tym, jak zaimplemetować
kolejki, drzewka, jak żonglować wskaźnikami do wskaźnika na tablicę wskaźników
(częste zadanie z C++) byłoby dla niego katorgą, a dla firmy stratą czasu. Stąd
pojawienie się takich języków jak JAVA, gdzie oprócz składni dostajemy całą
strukturę reużywalnych klas, stąd pojawienie się frameworków typu AJAX, Spring,
Hibernate, których głównym zadaniem jest to, by programista mógł się skupić nad
biznesowym sednem rozwiązywanego problemu, a nie skupiał na rozwiązywaniu
powtarzalnych problemów natury technicznej.

do góry

Użytkownik "pw" <p...@o...pl> napisał w wiadomości
news:fo25o9$b77$1@atlantis.news.tpi.pl...
> Poza tym rynek ten rządzi się
> swoimi prawami, w którym szeroko pojęta ergonomia aplikacji dla
> użytkownika jak i łatwość jej rozwoju przez programistów są rzeczami co
> najwyżej trzeciorzędnymi.
I tu się mylisz. Sam od jakiś 3 lat zajmuję się rozwijaniem i utrzymywaniem
systemów, jakie wytworzyli programiści z działu produkcji firmy, w której
pracuję, i które to systemy pracują u klientów - wcześniej robiłem na produkcji.
I nie ma nic gorszego, gdy okazuje się, że wprowadzenie do aplikacji
rozszerzenia, które klient potrzebuje na gwałt i jest w stanie zapłacić dużą
kasę by mieć w krótkim terminie, wymaga przerobienia całej aplikacji. Dobry
projektant projektując aplikacje często potrafi przewidzieć, jakich rzeczy może
potrzebować klient w przyszłości i stara się tak ją zaprojektować, by dodanie
tych rozszerzeń dla firmy nie było kłopotliwe. Oczywiście klient dalej musi być
mamiony, że ta zmian a to Bóg wie ile roboty jest. Wiadomo, projektant nie
wróżka, tak samo jak klient zamawiając system nie zawsze wie, co mu z an lat
potrzebne będzie. Ale rozszerzalność i skalowalność to jedne z podstawowych cech
dobrze stworzonego systemu. Bo to, ze system działa, tzn. w akceptowalnym czasie
wypluwa prawidłowe wyniki, nie zawsze oznacza, że został prawidłowo
zaprojektowany i napisany.


> Jasne, że do przeglądarki C++ się nie nadaje, ale Java też nie, ze
> względu na zbyt niską ergonomię interfejsu użytkownika.
Oczywiście. Robienie GUIO czy wogóle aplikacji desktopowej w Javie to
nieporozumienie - to tak, jakby do pisania wypracowań używać photoshopa. Da się
:) Java jest do tworzenia przede wszystkim logiki biznesowej po stronie serwera

do góry

Użytkownik "Jakub Kaniewski" <j...@c...gmail.com> napisał w
wiadomości news:fo2c05$p2a$1@inews.gazeta.pl...
> Tylko problemem jest złożoność implementacji - jeżeli podobny problem zajmie w
> C++ 100 linii kodu, w Javie 20, a w Rubym 5 to jednak nie opłaca się wybierać
> tego pierwszego języka.
I tak samo nie wyobrażam sobie utrzymywania systemu finansowego, czy księgowego,
gdzie przykładowo na 100 linijek, 5 to zakodowane reguły biznesowe, a pozostałe
95 to np. przerzucanie bloków pamięci, czy jej odśmiecanie (to tak dla
przykładu, by pokazać skalę problemu)

do góry

Użytkownik "Jakub Kaniewski" <j...@c...gmail.com> napisał w
wiadomości news:fo2c05$p2a$1@inews.gazeta.pl...
> a najlepszą kasę trzepią teraz programiści COBOLA, bo ostało się ich
> niewielu, a polskie banki na trzy litery ciągle mają cześć systemów w tym
> napisaną :)
Ale jak w banku jest ktoś, kto potrafi liczyć, ale długofalowo, w perspektywie
minimum 5 lat naprzód, to często podejmowane sa w nim decyzje o zmianie systemów
w banku. Nie dlatego, że stary źle działa. Po prostu koszty jego utrzymywania i
rozwijania - w 5 letniej perspektywie - moga okazać się wyższe, niż koszty
przejścia na nowszą platformę, której utrzymanie będzie tańsze

do góry

Użytkownik "mihau" <m...@g...com> napisał w wiadomości
news:069aa21d-5708-4825-865c-b6477bcc9b70@e4g2000hsg
.googlegroups.com...
On 2 Lut, 00:22, pw <p...@o...pl> wrote:

> Za Javą też nie przepadam, ale jej powszechności to nie zmniejszy. Co
> do Pythona, to daje możliwość błyskawicznego stworzenia sporej
> aplikacji, której pisanie w C/C++ zajęłoby wielokrotnie więcej czasu.
> Dość przydatne, gdy wydajność kodu nie jest bardzo istotna. A jak
> jest, można łatwo dołączyć moduły w C. I stąd moja zachęta do poznania
> kilku języków.
Jest jeszcze jedna rzecz, która przemawia za tym, że w obecnych realiach z
pojedynku java : c++ to ta pierwsza wychodzi zwycięsko. Wyobraź sobie, że
zamawiasz system do firmy. Ma to być rzecz w architekturze klient - serwer.
Pomijam już fakt, że zrobienie webServices, czy platformy webowej w javie będzie
prostsze. Ale wyobraź sobie, że jest to system do obsługi jakiegoś produktu,
jaki sprzedajemy klientowi: pożyczek, ubezpieczeń itp. I na początku
zakładaliśmy, że klientów będzie kilkuset (to tak dla przykładu). I postawiliśmy
to na pececie. I nagle okazuje się, że niedoszacowaliśmy tempa przybywania
klientów, i zapada decyzja przeniesienia na jakąś niekompatybilną platformę. W
przypadku Javy sprawę załatwi (a przynajmniej teoretycznie powinna) kwestia
maszyny wirtualnej. A jak system będzie natywny, napisany w C++ ?

do góry

Dnia Sun, 3 Feb 2008 23:47:35 +0100, jaQbek napisal(a):
> przypadku Javy sprawę załatwi (a przynajmniej teoretycznie powinna) kwestia
> maszyny wirtualnej. A jak system będzie natywny, napisany w C++ ?

To na co Ty chcesz to przenosić ?

--
*| __ _ ___ __ |*
*| / / / ___/ __/ Łukasz Jagiełło - lukasz<at>jagiello<dot>org |*
*| / /_ / /__/ _/ I'm raving till the sweat drops has |*
*| /____/\___/_/ fallen down off me...I'm raving, I'm raving |*

do góry

jaQbek wrote:

> Dokładnie. Tworzone obecnie systemy są na tyle duże, że zmuszanie
> programisty do tego, by pisząc aplikację biznesową skupiał się na tym, jak
> zaimplemetować kolejki, drzewka, jak żonglować wskaźnikami do wskaźnika na
> tablicę wskaźników (częste zadanie z C++)

Może to i jest częste zadanie z C++, ale jedynie na uczelniach, a nie w
przypadku pisania zwykłego programu, który ma działać, a nie tylko podobać
się prowadzącemu.
Jeśli gdzieś trzeba żonglować wskaźnikami do wskaźnika na ... to znaczy, że
w Javie w ogóle człowiek nie będzie w stanie tego problemu rozwiązać.

do góry

Użytkownik "Lukasz 'LCF' Jagiello" <L...@...LOVE.SPAM> napisał w wiadomości
news:slrnfqcho9.36n.LCF@somewhere.in.heaven...
> Dnia Sun, 3 Feb 2008 23:47:35 +0100, jaQbek napisal(a):
>> przypadku Javy sprawę załatwi (a przynajmniej teoretycznie powinna) kwestia
>> maszyny wirtualnej. A jak system będzie natywny, napisany w C++ ?
> To na co Ty chcesz to przenosić ?
Pisząc "pececie" miałem na myśli architekturę 8086. A na co można przenosić?
Sun, Spark, różnego rodzaju architektury RISC, o których nawet pojęcia nie mam.
Sedno tkwi w wirtualnej maszynie, na której ma działać aplikacja. System, który
obecnie tworzę, bez problemu testuję na windowsach, jak i u klienta na maszynie
z linuxem. I działa tak samo (no, może u klienta szybciej :) ). Zrób to samo z
C++, powodzenia

do góry

Dnia Mon, 4 Feb 2008 00:55:43 +0100, jaQbek napisal(a):
>>> przypadku Javy sprawę załatwi (a przynajmniej teoretycznie powinna) kwestia
>>> maszyny wirtualnej. A jak system będzie natywny, napisany w C++ ?
>> To na co Ty chcesz to przenosić ?
> Pisząc "pececie" miałem na myśli architekturę 8086. A na co można przenosić?
> Sun, Spark, różnego rodzaju architektury RISC, o których nawet pojęcia nie mam.
> Sedno tkwi w wirtualnej maszynie, na której ma działać aplikacja. System, który
> obecnie tworzę, bez problemu testuję na windowsach, jak i u klienta na maszynie
> z linuxem. I działa tak samo (no, może u klienta szybciej :) ). Zrób to samo z
> C++, powodzenia

Żaden ze mnie programista, ale wydaje mi się że przy założeniu
muliplatformowości nie powinno być problemu z przenoszeniem kodu. Jak
kompilator nie jest jakiś udziwniony w zależności od architektury, a
programista ma świadomość różnic architektur to przecież się da. Poza
tym x86,spark to jeszcze lapie, ale co ma do tego SUN ?

--
*| __ _ ___ __ |*
*| / / / ___/ __/ Łukasz Jagiełło - lukasz<at>jagiello<dot>org |*
*| / /_ / /__/ _/ I'm raving till the sweat drops has |*
*| /____/\___/_/ fallen down off me...I'm raving, I'm raving |*

do góry