Dodatkowo, myślę że dobrym pomysłem było by przeniesienie projektu z Deplhi na np. C++ lub javę...
Aż wczoraj sprawdziłem z ciekawości... Obecna biblioteka ma ponad 16,3 tys linii kodu. Paweł zaczął pracę nad nią w 2007 roku. Także wybacz, nie zgadzam się z Tobą. Przeniesienie wszystkiego na inny język to nie jest praca polegająca na wrzucenie do Google Translate... To jest konieczność napisania wszystkiego od nowa, z uwzględnieniem bardzo wielu różnic, jakie występują pomiędzy Delphi, Javą i C++ i oczywiście koniecznie trzeba by kod zoptymalizować. To jest wytężona praca programistyczna. Zakładam, że jesteś kozak w C++ i Javie, skoro tak usilnie to proponujesz, ale i tak to zbyt wiele pracy dla jednego programisty, aby we w miarę racjonalnym czasie (a być może i w ogóle) doczekać się oprogramowania symulatora pod nowym silnikiem.
...z Deplhi na np. C++ lub javę, które w przeciwieństwie do Delphi i Pascala umożliwiają stworzenie (w przypadku C++ kompilację) wersji dla np. Linuxa
Sorry... ale muszę zadać Ci kłam
. Gadasz bzdury. Czy kiedykolwiek zapoznawałeś się z projektem zwanym Lazarus? To narzędzie umożliwiające zakodowanie multiplatformowych aplikacji w języku Delphi. Jest to na tyle świetne narzędzie, że można kod napisać jeden raz i bez żadnych poprawek kompilować pod Lazarusem w Linuxie, Windowsie aplikacje przeznaczone dla konkretnych systemów operacyjnych.
Jakie są zatem racjonalne przesłanki, żeby przepisywać ponad 16 tys. linii kodu napisanego w Delphi na inny język programowania. Tylko nie mów proszę, że wydajność C++ lub Java jest wyższa, bo będę musiał znowu zadać Ci kłam.
Po pierwsze. To dziecinne argumenty osób, które przymierzały się do pisania gier w Delphi wykorzystując gotowe pakiety do programowania 3D. Faktycznie wydajność takich gier była zdecydowanie niższa, niż gier 3D pisanych w C++. Ale szczerze? Nie znam porządnego programisty, który pisząc gry 3D z prawdziwego zdarzenia korzysta z gotowych komponentów. Takie gry nie będą nigdy wydajne, bo oprócz tego, co jest tam potrzebne znajdzie się tam mnóstwo kodu absolutnie niepotrzebnego. Każdy szanujący się programista 3D sam oprogramowuje sobie tylko to, co jest mu potrzebne.
Po drugie. ISDR jest prostą aplikacją okienkową, nie obciążającą zanadto zasobów systemowych. W takich aplikacjach pojęcie wydajności jest w ogóle bardzo mało istotne.
Takie jest moje zdanie
