🚀 go-pugleaf

Qertoip wrote:
> Na początek uczciwie zaznaczę, że jestem w Pythonie początkujący. Nie
> licząc różnych "wprawek", napisałem około 1000 wierszy działającego kodu
> (wątki, sockety, XML). Inną część tej samej aplikacji (również: wątki,
> sockety, XML) piszę w .NET (VS2003).

Ja osobiście w dotnecie dotarłem do etapu hello world i tam poległem, 
dokładnie z tego samego powodu, dla którego Ty wolisz C#... Mi się 
wydaje, że to jest jednak w większym stopniu kwestia 
przyzwyczajeń/doświadczeń/traum.

> Tym samym miałem okazję porównać swoją produktywność na tych dwóch
> platformach. Podkreślę - nie tyle językach, co *platformach*.
> 
> Zauważyłem, że choć Python jest bardziej ekspresywny niż C#, to jednak
> wydajność tworzenia oprogramowania jest istotnie większa w tym drugim...
> 
> Spostrzegłem, że składają się na to dwie prozaiczne rzeczy:
> - bardzo słaba (w porównaniu do MSDN) dokumentacja bibliotek Pythona

To fakt, nie jest z tym najlepiej. Nie ukrywam, że zdarza mi się np. 
zerkać do sorców żeby wykumać, jak to wszystko jest poskładane i co się 
dzieje w "corner cases".

> - niemożność wylistowania składowych obiektu (w VS: Ctrl+Space) wraz z
> podręczną dokumentacją dla każdej składowej (metody, atrybuty). Osoby
> piszące w nowoczesnych IDE wiedzą o co mi chodzi.

Ja nie wiem, ostatnio jadę pod windą w Notepad2 a tradycyjnie joe'm (od 
którejś tam wersji ma fajne podświetlanie składni Pythona). Mi inspektor 
obiektów nie jest z reguły potrzebny, chociaż wiadomo, co osoba to inne 
preferencje.

> To drugie wynika z faktu, że w Pythonie rzadko kiedy da się statycznie
> ustalić typ obiektu (jeśli się da, najlepsze pythonowe IDE potrafią
> wylistować składowe).

Nie ma problemu z inspekcją metod klasy i atrybutów klasowych. Natomiast 
fakt, w praktyce sprawdzenie atrybutów w teorii i praktyce jest poza 
runtimem właściwie niemożliwe. Jakimś tam lekarstwem na to są sloty w 
składni 2.4, ale to półśrodek. Python jest językiem młodym i ciągle 
ewoluującym, a ta sprawa właśnie (bardziej statyczna obiektowość) jest 
co chwilę poruszana wśród jego tfurców, bodajże nawet sam BDFL Guido się 
do tego skłania.

Zobaczymy, co nadejdzie z Py3K. Chociaż ja osobiście wolałbym dobrze i 
wydajnie zaimplementowaną maszynę wirtualną dla 2.4, no ale cóż...

> Niby pierdółki... ale *naprawdę* ma to zasadniczy wpływ na wydajność.

Kwestia gustu, acz oczywiście rozumiem i po części podzielam Twoje obiekcje.

> Jestem głodny Waszych uwag na ten temat. 
> Czy da się jakoś zniwelować powyższe problemy?

Kwestia paradygmatu inżynieryjnego i organizacji pracy w grupie. Uwierz 
mi, brak statycznych prototypów dla klas nie jest największym problemem 
przy współpracy grupowej. Są poza tym różne podejścia próbujące to w 
pewnym sensie niwelować (PyProtocols chociażby).

To w ogóle taki temat trochę szeroki, bo trzebaby najpierw zdefiniować, 
czym na prawdę jest atrybut obiektu i czy ma konkretny związek z klasą 
obiektu - Guido i spółka przyjęli, że tak nie jest, większość reszty 
świata, szczególnie z korzeniami w C, jest innego zdania...

> Jak porównujecie swoją wydajność w Pythonie do wydajności w innych
> nowoczesnych językach?

Ja mogę z osobistego doświadczenia porównać to schematycznie tak:

Angielski > Polski > Python > C ~ C++ > asembler x86 ;) > Java > Perl 
 >>>>> PHP

od najwydajniejszych dla swojej klasy zastosowań do najmniej wydajnych 
;) co przekłada się bezpośrednio na jakość "ideologiczną" języka.