bardzo ładne podsumowanie.
Z jednej strony jestem nieco zawiedziony, że trafiłem tu już w momencie kiedy ów wybór mam za sobą, z drugiej szalenie miłym zaskoczeniem był fakt, że zupełnie niezależnie, w rezultacie podobnej analizy dokonałem tego samego wyboru.

To czego mi we wpisie zabrakło, to nieco większe rozwinięcie tematu frameworków. Wybór odpowiedniego bynajmniej nie jest to banalną sprawą, a tymczasem mam wrażenie, że autor po tak długim wpisie potraktował sprawę nieco po macoszemu.
Może jest to potencjalny materiał na kolejny wpis?
Jedno z podstawowe pytanie, przy frameworkach powinno IMHO dotyczyć ilości i przede wszystkim jakości wdrożeń o nie opartych. Nie na darmo mówi się, że lepiej uczyć się na cudzych błędach, a co za tym idzie raczej nie warto opierać projektu o rozwiązanie, które nie sprawdziło się jeszcze w produkcyjnych warunkach na dużą skalę.

BTW Pod kryteriami dla których odpadł Perl podpisuję się z całym przekonaniem

Czekam na kolejne informacje z frontu

Co do szukania programistów Python-owych, to mam nadzieję, że jak już do tego punktu dotrzemy, to współpraca z MFI pomoże nam zaadresować ten punkt

Zgadzam się także, że w temacie tego rodzaju aplikacji web-owych królują „PHP-owcy” (w temacie hostingu zresztą też), ale część z nich zaczyna dostrzegać ograniczenia tego języka i rozglądając się za czymś dojrzalszym migrują w stronę Ruby lub właśnie Python-a.

Tego typu ciekawych punktów do dyskusji jest mnóstwo – może za jakiś czas, jak uzbieramy bardziej pokaźny bagaż doświadczeń, porównać i przemyśleń pokusimy się o jakąś prezentację na SPIN-ie (bo na JUG-a to temat chyba nie specjalnie by się nadawał).

A co do języków do tego rodzaju aplikacji, to wydaje się że duo: Groovy+Grails też byłoby warte bliższej analizy.

- Mikołaju fajna analiza, brak tendencyjności Javowej w ocenach:)

- piszecie o doborze optymalnego narzędzia do wykonania/osadzenia serwisu; narzędzie zwykle dobiera się do parametrów zadania, które nie wynikają z kontekstu; Michał pisze o „armatach i muchach” – armaty przeanalizowane, tylko jaka jest ta mucha:)

- co do wyboru Pythona i Django, to wydaje się niezłym zestawem do średniej wielkości serwisów; problemem może być znalezienie programistów „z doświadczeniem”, jeżeli projekt ma się rozwinąć aż tak; od jakiegoś czasu uczę Pythona na MFI ale pewnie na rynku lekkich rozwiązań wciąż królują „fachowcy” od PHP; oczywiście porównanie Pythona z PHP nie ma sensu … chociaż jako parametr analizy warto wziąć łatwość integracji z innymi rozwiązaniami

- prócz doboru „armat”, trzeba jeszcze zrobić dobry projekt, niby oczywistość, ale widziałem już kilka projektów, które przestawały sobie radzić z własnym rozwojem; skutki opłakane choć rozciągnięte w czasie

To tyle moich 3gr.
Fajnej przygody z Pythonem.
Będę trzymał kciuki, Tomek

@Michał
Oczywiście zgodzę się z Twoimi dodatkowymi kryteriami wyboru – co więcej zgodziłbym się jeszcze ze sporą ich ilością. Moim celem było opisanie naszych kryteriów… a tu na szczęście nie mamy żadnych specjalnych zewnętrznych ograniczeń – sky is the limit
Zgadzam się także, że Apache to pamięciożerne stworzenie, ale są alternatywy w postaci lighthttpd, nginx i nawet testy porównawcze ich wydajności – choć po lekturze linka, którego zapodałeś, do tego rodzaju testów podchodzę z jeszcze większą rezerwą niż dotychczas. Tym samym napisanie miarodajnych testów porównawczych Tomcat versus lighthttpd+fcgi+python nie wydaje się być trywialnym zadaniem… więc może poprzestańmy na stwierdzeniu, z którym się zgadzamy, tj. „szybkość developmentu” przemawiająca za językami typowanymi dynamicznie.

@Lukasz
Zgodzę się z tezą wychwalania tego czego jeszcze nie znamy, ale pozwolę sobie nie zgodzić się z częścią pozostałych tez.

Być może napisalibyśmy to szybciej w czystym PHP-ie (ale IMHO nie byłyby to 10x, ani nawet 5x). Jednak problem jest gdzie indziej – pisanie w samym PHP-ie (czy też w JSP ze skrypletami sięgającymi bezpośrednio do bazy – co na początku też było nagminnie stosowane), bez użycia żadnego framework-a, który m.in. wymusi separację warstw, nie najlepiej się sprawdza, w momencie jak aplikacja zaczyna się rozrastać. Jej utrzymanie i dalszy rozwój stają się coraz bardziej kosztowne: próba zmiany struktury jakiejś tablicy może oznaczać konieczność przekopania dziesiątków plików, próba dołożenia jakiegoś standardowego sprawdzenia dla każdego żądania to samo, że o testach jednostkowych nie wspomnę… przykłady można by mnożyć.

W związku z tym, uważam że warto ponieść koszt wdrożenia framework-a, bo w dłuższej perspektywie taka inwestycja się zwraca (no, chyba że mamy noc na napisanie programu na zaliczenie i nigdy więcej nie zamierzamy go oglądać ) Stąd też w naszej sytuacji tak czy inaczej z jakimś framework-iem powinniśmy się zapoznać – więc dlaczego nie z Django/Python, które zdają się mieć zdrowe podstawy

Co do przygody, to jak najbardziej masz rację… na pewno miało to swój wpływ na decyzję – ale cóż byłoby warte hobby/praca, ba życie, które nie jest jedną wielką przygodą (że pozwolę sobie na odrobinę filozofii )

@Marcin
Cóż… pozostaje mi się zgodzić z każdym zdaniem, które napisałeś, ale…
Przyjrzyjmy się aplikacją webowym, one nie mają tysięcy klas biznesowych… jeśli chodzi o logikę biznesową są one dużo prostsze od ich tak zwanych „korporacyjnych” odpowiedników.
Jedyne więc co chciałem zasygnalizować, to fakt że w przypadku pisania pewnych (np. webowych) aplikacji języki typowane dynamicznie wydają się lepiej sprawdzać.

Jeszcze raz dziękuję wszystkim za feedback – na pewno nie omieszkamy podzielić się naszymi przemyśleniami za jakiś czas, gdy nabierzemy więcej doświadczeń w tej materii…
Zapraszamy więc do śledzenia dalszych losów naszej było, nie było przygody

W przypadku większego systemu (kilka tysięcy klas) jawne określanie typu ułatwia poznawanie nieznanych fragmentów i chroni przed wątpliwościami typu czy pole Termin zawiera liczbę dni, czy datę graniczną. Typ pola w klasie trwałej to przecież nic innego jak element logiki biznesowej, z którego można korzystać na przykład przy tworzeniu interfejsu użytkownika. I tu wielki plus dla Django, że typy pól określane są na poziomie modelu w sposób jawny, i że framework potrafi z tych informacji skorzystać generując UI.

Ponadto określanie typów pozwala na uniknięcie całej masy błędów, wobec których testy jednostkowe nie sprawdzają się najlepiej. Mam tu na myśli sytuację, w której funkcji zostanie przekazany parametr nieprawidłowego typu, bądź w polu obiektu pojawi się wartość innego typu niż spodziewany. Oczywiście możliwe jest dodanie kodu sprawdzającego parametry funkcji, czy też wartości przypisywane do pól obiektów, jednak oznacza to po części własną iterpretację funkcjonalnego odpowiednika statycznej kontroli typów. No ale w końcu DRY nie zakazuje powtarzania rozwiązań wymyślonych przez innych…

Trzymam kciuki za powodzenie projektu!