W dniu 2014-07-14 09:38, Maciej Sobczak pisze:
> I teraz powstaje pytanie, czy należy to robić w Pythonie.

Nie działałem w Pythonie. Ogólnie nie lubię języków dynamicznych. Są
mało czytelne. Gdy pracowałem kiedyś z odmianą Smalltalka, to widząc
parametry jakiejś funkcji nie było jasne co to za obiekty.
Poza tym ta powolność. Czy nie dałoby się kompilować Pythona? choć nawet
jak i na interpretację prędkość jest zbyt mała.

do góry

On Mon, 14 Jul 2014 00:38:49 -0700 (PDT), Maciej Sobczak
<s...@g...com> wrote:

>
>I teraz powstaje pytanie, czy należy to robić w Pythonie.

W Pythonie mozna robic to co mozan robic w Pythonie

A.L.

do góry

On 14/07/2014 08:38, Maciej Sobczak wrote:
> W dniu niedziela, 13 lipca 2014 21:05:40 UTC+2 użytkownik Andrzej
> Jarzabek napisał:
>
>> A np. firmy dzisiaj nie maj� 1000 razy wi�cej klient�w,
>
> Facebook, Twitter, Google, Amazon - zdaje się, że mają.
[...]
>> 1000 razy wi�cej pracownik�w
>
> Foxconn?

Pomijając, że użytkownicy Google, Twittera czy Facebooka nie są
klientami tych firm, pomijając że Foxconn raczej nie zatrudnia
dziesiątek milionów pracowników, to wydawało mi się, że z kontekstu
jasne jest, że nie o ten kwantyfikator chodzi. 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? To samo z ilością klientów (instytucjonalnych np.), ilością
produktów itd. I to nie tylko, że te firmy istnieją, ale raczej to one,
a nie Amazony i Foxconny są normą.

>> ani nie produkuj� 1000 razy wi�cej �rubokr�t�w.
>
> Śrubokrętów faktycznie nie produkują, bo teraz się produkuje
> smartfony

Poważnie? Nie tak dawno kupowałem śrubokręty, mówisz, że to wszystko
reszty z magazynów sprzed 30 lat?

> Natomiast pomijając te skrajności mamy inny problem - firmy, nawet te
> średnio-mniejsze, chcą *wiedzieć* 1000x więcej, niż kiedyś. 30 lat
> temu żadna firma nie śledziła ruchu gałek ocznych swoich klientów, a
> teraz wszyscy chcą to robić.

Nie wszyscy, np. ta firma, w której pracuję, wcale nie chce. Co więcej,
nawet gdyby chciała, to nie znaczy, że każdy kawałek oprogramowania
używany w firmie ma się akurat tym zajmować.

> I dlatego firma, która może w ciągu 30
> lat nie powiększyła swojego zatrudnienia i nie produkuje 1000x więcej
> śrubokrętów, potrzebuje (?) dzisiaj 1000x więcej mocy obliczeniowej.

To mówisz, że te śrubokręty, co je kupiłem, śledzą gałki moich oczu?

> Tzn. tylko mysli, że potrzebuje, ale w sumie z naszego (IT) punktu
> widzenia nie ma znaczenia, czy faktycznie potrzebuje, czy tylko myśli
> - tak czy inaczej trzeba im to przetworzyć.
>
> I teraz powstaje pytanie, czy należy to robić w Pythonie.

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?

do góry

Użytkownik "A.L." napisał w wiadomości grup
dyskusyjnych:p458s9pmpre4atdjk4hnm6sdili2ukr8fu@4ax.
com...

>W Pythonie mozna robic to co mozan robic w Pythonie

Mam odmienne zdanie: w Pytonie można ROBIĆ wszystko, ale większość z tych
rzeczy nie da się ZROBIĆ.

I to nie jest analogia do Asemblera (w którym wszystko można ZROBIĆ, ale
nikomu się nie chce tego ROBIĆ).

do góry

Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
dyskusyjnych:lq1agr$pdn$...@s...chmurka.net...

>jasne jest, że nie o ten kwantyfikator chodzi. 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

Kiedyś do wszystkiego wystarczyć musiał księgowy i zwykłe liczydło, takie
druciki z koralikami.

Ale jeżeli uważasz, że Kadry-Płace-Magazyn (gumowych szlauchów i kaloszy) to
szczyt twoich ambicji, to chyba jest mi ciebie żal.

>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?

I dlatego programy to automatycznego lądowania, oprogramowanie rozruszników
serca, ABS, obrabiarki CNC, kodeki wideo i gry FPP piszmy w Pythonie.
Urrra!

do góry

On 15/07/2014 00:58, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:lq1agr$pdn$...@s...chmurka.net...
>
>> jasne jest, że nie o ten kwantyfikator chodzi. 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
>
> Kiedyś do wszystkiego wystarczyć musiał księgowy i zwykłe liczydło,
> takie druciki z koralikami.

Ale pewnie i obliczenia wynikające z przepisów były prostsze. Ale OK,
powiedzmy, że dla 20 tysięcznej korporacji możnaby obliczyć wszystkie
wypłaty, podatki, zusy itd. liczydłem. Nadal zastosowanie komputera ma
sens, bo wychodzi taniej (czas księgowego kosztuje, pomyłki księgowego
mogą bardzo kosztować). Natomiast zastosowanie "szybszego" języka
niekoniecznie ma sens - różnica w czasie obliczeń jest bez znaczenia, bo
tak czy inaczej całość generuje się w kilka sekund i róznice w kosztach
są infitezymalne.

> Ale jeżeli uważasz, że Kadry-Płace-Magazyn (gumowych szlauchów i
> kaloszy) to szczyt twoich ambicji, to chyba jest mi ciebie żal.

Co moje ambicje mają do rzeczy? Takie programy są potrzebne, ktoś
zapłaci, żeby je zrobić. Zapewne nie mi, ale za odpowiednią stawkę mogę
to zrobić, choćby i w Pythonie (chociaż nie znam Pythona).

>> 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?
>
> I dlatego programy to automatycznego lądowania, oprogramowanie
> rozruszników serca, ABS, obrabiarki CNC, kodeki wideo i gry FPP piszmy
> w Pythonie. Urrra!

A potrafisz napisać tak, żeby działały zgodnie z wymaganiami?

do góry

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.

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 znowu mamy to samo pytanie: czy powinien to robić w Pythonie. Ale teraz nie
patrzymy z punktu widzenia użytkownika (czyli firmy produkującej śrubokręty), tylko z
punktu widzenia producenta oprogramowania obsługującego wiele różnych takich firm.

Oczywiście zawsze może się znaleźć pasjonat w firmie produkującej śrubokręty, który
postanowi na własną rękę rozwiązywać problemy IT swojego pracodawcy, ale przy
pasjonatach trudno podawać racjonalne reguły. Jak się uprze, to napisze w czymkolwiek
- nie będzie to jednak punktem odniesienia dla innych takich firm, bo inne firmy będą
miały innych pasjonatów albo racjonalnie kupią gotowy program.

> 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.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

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.

do góry

Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
dyskusyjnych:lq2gv8$7sc$...@s...chmurka.net...

>Co moje ambicje mają do rzeczy? Takie programy są potrzebne, ktoś zapłaci,
>żeby je zrobić. Zapewne nie mi, ale za odpowiednią stawkę mogę to zrobić,
>choćby i w Pythonie (chociaż nie znam Pythona).

Złożoność obliczeniowa programu do obliczania płac jest... niech zgadnę
nadwykładnicza? ;)

I zwykle takie obliczenia dla wszystkich 10 tysięcy pracowników robi się co
najmniej dwa razy na godzinę? ;)

(Tak, to jest ironia.)

A może prawidłowe odpowiedzi to: O(N), N < 10000, raz na miesiąc, jest co
najmniej godzina na obliczenia?

Podsumowując: cała sytuacja przypomina "sportową rywalizację pomiędzy
zwierzyną a myśliwym" - i to w polowaniu na ślimaki winniczki.

do góry

Użytkownik "Maciej Sobczak" napisał w wiadomości grup
dyskusyjnych:2e5dd6da-ed91-46c4-9824-04db9268f1b6@go
oglegroups.com...

>Bo w ogóle kiepskim pomysłem jest samodzielne pisanie programu do liczenia
>wypłat. Znacznie taniej jest taki gotowy program kupić.

Ba! Ale wiesz, że ten program który kupujesz jakiś "ktoś" jakieś "gdzieś"
musiał napisać? Czy nadal wierzysz, że programy przynosi św. Mikołaj?

>I znowu mamy to samo pytanie: czy powinien to robić w Pythonie. Ale teraz
>nie patrzymy z punktu widzenia użytkownika (czyli firmy produkującej
>śrubokręty), tylko z punktu widzenia producenta >oprogramowania
>obsługującego wiele różnych takich firm.

Która to firma software'owa musi, naturalnie, zatrudniać co najmniej 1500
ludzi, w tym 150 informatyków, 20 prezesów, 300 kierowników, 900 prawników i
jeszcze może fryzjera? I w ramach outsorcingu większość konkretnej roboty to
w Indiach (software) lub/i PRC (hardware)? A efektem jej działania jest
program, który de facto dałoby się zastąpić arkuszem w MS Excelu? ;)

do góry