Graficzny instalator

[Jakub Piotr Cłapa]

Cezary Krzyzanowski wrote:
> Jakub Piotr Cłapa wrote:
> 
>>Chodzi o to, że różnica w wydajności jest pomijalna. 
> 
> 20% bez wgłebiania się?

To jest pomijalnie mało, jeśli chodzi o program, za którego większość 
roboty wykonuje GTK+2, xft, freetype i serwer Xów. (zrób profile i 
sprawdź ile czasu program siedzieć będzie w kodzie Pythona, a ile w 
bibliotekach).

>>Po pierwsze
>>dlatego, że programy okienkowe zazwyczaj nie wymagają dużo mocy
>>obliczeniowej (nie na poziomie logiki programu --- jedynie na poziomie
>>renderingu, który przecież i tak jest w C).
> 
> Właśnie piszę implementację trójwymiarowego automatu komórkowego z
> wizualizacją w OpenGLu. PyGL pewno by sie zakrztusił. Zresztą, nawet
> Word ze swoimi automatami sprawdzania gramatyki/ortografii/składni już
> teraz jest poważnym zżeraczem zasobów. O aplikacjach
> naukowych/obliczeniowych/dyskowych już nie wspomnę.

Aplikacje naukowe w strasznie dużej ilości są pisane w językach 
interpretowanych (python, lisp, java) z wykorzystaniem bibliotek, które 
optymalnie wykonują najtrudniejszą część pracy (napisanych w C lub np. w 
Pyrexie). Użycie C/C++ do całego programu to typowe premature optimization.

Co do Twojego automatu komórkowego --- nie wiem jak by on chodził w 
Pythonie, ale prawdopodobnie używając mieszanki Pythona i Pyrexa 
napisałbyś go 2 razy szybciej (i miałbyś z miejsca 40% mniej błędów 
alokacji pamięci i takich tam).

Oczywiste jest, że nie każdy język jest optymalny do każdego zadania, 
ale gdyby czysta wydajność była jedynym czynnikiem, który bierzemy pod 
uwagę, to wszyscy pisalibyśmy w assemblerze. (który nota bene potrafi 
stworzyć pliki wykonywalne jeszcze 5 razy mniejsze niż C i wymagające 10 
razy mniej bibliotek ;).

> Zresztą, rozmawiamy tutaj o instalatorze, od którego zapewne wymaga się
> właśnie szybkości i platformy z jak najmniejszą ilością
> maszyn/bibliotek. 

Nie o taka szybkość nam chodzi. GUI instalatora musi chodzić jedynie 
znośnie szybko, a to spokojnie da się osiągnąć w Pythonie.

> C i C++ jest nieoddzownym elementem każdego linuxa i
> na pewno 80% bibliotek potrzebnych ew. instalaorowi i tak będzie na
> płytce, żeby obsłużyć wszystkie programy, z których korzystać będzie
> rzeczony instalator, a python w tym momencie to novum i trzeba go osobno
> obsłużyć.

Nie takie straszne novum, a w intalatorze to akurat wszystko jedno, bo i 
tak dostarczasz całą płytkę z własnym softem. Większy problem jest 
akurat w programach standalone, które mają się wpasować w istniejący 
system (ale tu też nie byłbym taki pewien... większosć binarek w C jest 
statycznych, autoconf i automake mają wiele swoich problemów... C/C++ 
jest mniej uniwersalny i neutralny platformowo)

>>Druga rzecz --- w swoim 
>>programie w C++ też będziesz potrzebował często zaawansowanych bajerów i
>>wtedy będziesz musiał pół maszyny wirtualnej Pythona napisać od nowa
>>tylko dla swojego programu i nie sądze, żebyś dostał coś lepszego niż
>>oryginał.
> 
> Co to znaczy 'zaawansowanych bajerów'?? Zdecydowanie prace z
> listami/stringami są na pewno notacyjnie łatwiejsze niż w C++, ale z
> odpowiednimi bibliotekami też narzekać nie będę. Wszystko kwestia
> bibliotek szczerze mówiąc i niczego wiecej.

Oczywiście, ale Mozilla jest napisana w C++ z dużą ilością fajnych 
bibliotek. Działa nadal tak diabelnie szybko?

>>Nie ma zbytnio kompilowanych wersji programów w Pythonie.
> 
> Pyexe i na linuxa pewno też jest jakiś odpowiednik.

To nie jest kompilator. :) To jedynie program, który pakuje pliki 
Pythona, dllkę interpretera i jeszcze trochę śmieci, do jednego pliku.
Był kiedyś Python_C, który udowodnił, że zamiana kodu Pythona na 
kompilowane C nie ma sensu --- większość czasu tracone jest na dynamice 
języka (np. to, że każda klasa może być zmodyfikowana runtime).

>>Aplikacje GUI to programy zdecydowanie I/O bound a nie CPU bound, więc
>>wydajność ma w nich drugorzędne znaczenie.
> 
> Słuchaj - prosta klikana przeglądarka do zdjęc dziewczyny z wakacji i
> brachola z psem pewno tak, ale w instalatorze na pewno wydajność się przyda.

Wydajność czego? Masz w instalatorze 20 ekraników, a całą trudną robotę 
robi za Ciebie poldek, rpm i bzip2. Prędkość języka w jakim zostanie 
napisane te 20 ekraników ma się nijak do prędkości instalatora. Ma się 
za to niesamowicie bardzo do tego, jak szybko ten instalator można 
napisać/poprawić.

> Na wydajność systemu składają się wszystkie jego elementy. Strata
> wydajności na jednej prostej klikance w pythonie jest niewielka, ale
> jakby napisali KDE czy Gnome'a w pythonie, to już by zabolało.
> 
> Zresztą, EOT, bo ja z kolei zaczynam wypisywać tutaj jakieś teorie n/t
> programowania. Chcesz tak bardzo pythona - z tego co słyszałem, piszą
> jakiś system unix-like w pythonie, więc nie ma problemu. My tu gadu gadu
> o pierdołach, a chłopaki instalator piszą - POWODZENIA!! EOT.

Piszą, ale mało to UNIX-like a i moim zdaniem Python się do tego mało 
nadaje (za wiele ma wbudowane w siebie).

-- 
z wyrazami szacunku,
Jakub Piotr Cłapa