On 15/07/2014 08:56, Maciej Sobczak wrote:
> W dniu poniedziałek, 14 lipca 2014 21:20:45 UTC+2 użytkownik Andrzej
> Jarzabek napisał:
>
>> Kiedy� firmy, kt�re mia�y, powiedzmy, 20 tysi�cy
>> pracownik�w i obs�ugiwa�y wyp�aty dla nich wszystkich na
>> komputerze o mniejszej mocy obliczeniowej niďż˝ dzisiejszy smartfon
>> z dolnej p�ki programem napisanym w jakim� COBOLu czy innym
>> PL/I. Dzisiaj te� istniej� firmy takiej wielko�ci, a nawet
>> mniejsze, wi�c, czemu program napisany w Pythonie nie mia�by
>> daďż˝ rady robiďż˝ tego samego?
>
> Bo w ogóle kiepskim pomysłem jest samodzielne pisanie programu do
> liczenia wypłat. Znacznie taniej jest taki gotowy program kupić. I to
> jest powód, dla którego owa firma nie powinna tego robić w Pythonie.
> Tzn. w ogóle nie powinna tego robić, więc w szczególności nie powinna
> tego robić w Pythonie.

Wcale nie jestem pewien, czy to tak działa w przypadku korporacji, która
zatrudnia 20 tysięcy osób, działa w iluś tam różnych jurysdykcjach, na
różnych umowach, ma swoje algorytmy naliczania podwyżek czy premii i
jeszcze musi ten program zintegrować z innymi systemami.

Przyznam się, że nie znam się akurat na tej tematyce (z wyjątkiem tego,
że jako pracownikowi różne takie systemy naliczały mi wypłaty), ale
akurat pracuję w innej dziedzinie w modelu biznesowym "jak ktoś się
zajmuje X, to taniej niż samemu tworzyć program do X będzie mu kupić u
nas" i w przypadku skomplikowanego X-a wcale to tak różowo nie wygląda -
moim zdaniem dla bardzo wielu robiących tego naszego X-a bardziej opłaca
się zrobić własny program niż kupić od nas (dyplomatycznie nie wypowiem
się w temacie czy wśród tych wielu są nasi obecni klienci).

> Teraz pytanie, w czym powinien to zrobić producent programu, od
> którego rzeczona firma go kupi. Otóż producent, dla zmniejszenia
> własnych kosztów i aby być bardziej konkurencyjnym na rynku, nie
> będzie pisał osobno takiego programu dla każdego swojego klienta,
> tylko napisze jeden program i spróbuje go sprzedać różnym klientom.

I co to zmienia. Dla producenta takiego oprogramowania to, że program
obliczy pensje ułamek sekundy wcześniejnie będzie raczej szczególnie
istotnym selling point. A że jego program kupi akurat Foxconn (gdyby to
miało jakiekolwiek znaczenie, a przecież nie ma) szansa jest niewielka.

>> Je�li taniej i szybciej potrafisz dostarczy� temu, co my�li,
>> �e potrzebuje, to, co my�li, �e potrzebuje (albo potrafisz go
>> przekona�, �e potrzebuje), to czemu nie?
>
> Zgadza się. Pytanie więc, w czym jest taniej i szybciej.

Nie mam odpowiedzi na to pytanie, w ogóle nie wierzę, że istnieje jedna,
uniwersalna odpowiedź. Wiem, że ja osobiście spotykałem się wielokrotnie
z sytuacjami, gdzie dynamiczność języka albo fakt, że był interpretowany
oznaczała, że coś można było zrobić taniej i szybciej. A ja raczej piszę
w językach statycznie typowanych i kompilowanych - zapewne ktoś, kto
używa więcej języków skryptowych/dynamicznych dostrzega więcej takich
okazji.