🚀 go-pugleaf

W dniu 2010-03-04 22:39, Andrzej Grażyński pisze:
>>
>> Jeżeli nie masz do czynienia wyłącznie z konserwacją tylko następuje
>> ciągły rozwój aplikacji, a chyba tak jest bo szkoda taki kod odłożyć
>> na półkę za rok czy dwa , to czy jednak nie lepiej wybrać coś bardziej
>> rozwojowego. W końcu powstają nowe systemy, procesory, 64 bity a z tą
>> niezawodnością to trochę wygląda na wymigiwanie się. Każde dodanie
>> nowego kodu generuje błędy.
>>
> Każde dodanie nowego kodu - owszem. To co powiedzieć o przepisaniu ok.
> 1,5 mln linii? Ile lat trzeba byłoby to testować, żeby ogarnąć błędy,

Ale mówimy "tylko" o zmianie kompilatora. Czyli konieczne jest 
przepisanie ok 0.1..10 % linii. Im lepiej kod napisany tym mniej.
A to już nie wygląda tak strasznie.



> które w związku z tym się pojawiły? BP7 znam na wylot, w końcu mam swój
> udział w jego powstawaniu (jak i wersji poprzednich począwszy od 4.0).
> Inne "rozwojowe" narzędzia są dla mnie wielkim nieznanym, nie wiadomo
> ile i jakie błędy kryją. A to stworzone w BP& potrafi KILKA MIESIĘCY bez
> przerwy iśc bez padnięcia (na FREE DOS-ie + mojego autorstwa driver do
> DPMI 0.9, bo dpmi16bi.ovl nie uwzględnia specyfiki nowych procesorów i
> czasem sie walnie). Więc po co przerabiać i ryzykować błędy? I tracić
> czas i forsę na dodatkowe testowanie?

Aby móc osiągnąć nową funkcjonalność, niedostępną przy obecnych 
założeniach. Sama wielkość nie determinuje Twojego podejścia.

Nie napisałeś co to jest za program. Nie interesuje mnie zastosowanie 
biznesowe, tylko założenia techniczne.

-- 
   Darek