blackfire

Ależ zgadzam się, że w gołym Pythonie nie pisze się tak wygodnie jak w django. Tyle że OIMW to mało kto to robi, a aplikacji pisanych w gołym PHP jest w cholerę i ciut ciut. Jeżeli piszesz coś od zera to wybierasz framework pod siebie, natomiast dostępne skrypty z reguły są jednak pisane w czystym PHP. Jak oceniasz -- wchodząc na losową stronę napisaną w PHP -- jaka jest szansa, że trafisz na np. Symfony? (BTW przyglądałem się kiedyś CakePHP i mnie nie oczarowało, ale DGCC). Z drugiej strony, PHP nadaje się właściwie wyłącznie do WWW -- w końcu to (było) Personal Home Page. Można byłoby więc przypuszczać, że wsparcie dla aplikacji webowych będzie ciutkę lepsze niż inline'owanie kodu HTML i automatyczne generowanie podstawowych nagłówków. @p: 1. A jutro napisze 10.8.2007? 2. Zepsułeś forum, ma teraz (u mnie przynajmniej) ze 3kpx szerokości 3. Ale w Malbolge to już na pewno nie napiszesz

#!/bin/bash echo "Content-Type: text/html" echo echo "Hello world! Dzisiaj jest" $(date +%Y.%m.%d) Eny kłeszczons? <podpucha>ale w Brainfucku nie napiszesz. Ani w Malbolge</podpucha> OT: pytanie o codeboxy było głupie

True. Jak się dobrze zastanowić, to większość aplikacji webowych to wariacja na temat CRUD, więc z reguły nikt Ameryki nie odkrywa, ale np. moje niedawne dzieło w Perlu (mimo że też jest w to sumie CRUD) to ciut ponad 100KLOC. W takiej ilości kodu potrzebna jest już jakaś struktura, wydzielone komponenty z określonymi interfejsami itp. PHP niestety sugeruje (choć nie wymusza) model, gdzie wszystko jest pomieszane ze wszystkim. Późniejsza opieka nad takim kodem robi się dość skomplikowana. Żeby nie teoretyzować: potrzebujesz jakiegoś drobiazgu, dajmy na to księgi gości. Czas start. <?php if (isset($_POST['tresc'])) { /* mysql_connect(...); print "..."; */ } else { /* itd. */ } ?> Później przydałoby się dodać np. walidację danych, email/imię/whatevera, może captcha jakieś, zalogowanych użytkowników itp. W pewnym momencie jedynym rozwiązaniem jest wyrżnięcie wszystkiego do gołej ziemi i napisanie na nowo, już jakoś bardziej cywilizowanie (MVC, szablony, jakaś abstrakcja bazy danych). Jeżeli spróbujesz coś takiego zrobić np. w RoR, to framework będzie z Tobą dość usilnie walczył, żebyś jednak użył MVC (a rzeczywisty kod, który będziesz musiał napisać to kilkanaście linijek). A ja jak chcę dodać jakąś kolumnę do bazy danych (w projekcie o którym wspomniałem na początku tego postu), dodaję linijki dwie: [ foobar => { type => 'integer', not_null => 1 }], # w modelu [ foobar => 'Liczba foobarów na metr kwadratowy' ], # w kontrolerze plus ewentualną dodatkową metodę walidacji (jeżeli np. liczba foobarów ma jakieś szczególne wymagania wykraczające poza bycie liczbą, bo to mam "z pudełka"). I nie muszę sprawdzać, czy na każdej stronie o foobarach ten parametr jest wyświetlany, czy nie machnąłem się w formularzu albo kontroli dostępu itd. Niestety, największy koszt związany z oprogramowaniem to jego utrzymanie. Tym większy, im bardziej na skróty było tworzone. A PHP ze względu na swoją niskopoziomowość (w porównaniu do współczesnych środowisk webowych) do takiego chadzania na skróty zachęca. OT: @admin: Czy te codeboxy muszą być takie duże?

Rozwija się tu piękny flejm, więc aż się dołączę 1. Szybkość wykonywania instrukcji. W przypadku języków skryptowych opartych o VM to jeden kij, Java jak się rozbuja (JIT, HotSpot), jest sporo szybsza 2. Szybkość tworzenia skryptu wykonującego daną operację. Przykłady poniżej. Przekraczając etap "Hello, world" PHP zostaje IMHO daleko w tyle 3. Programiści PHP... wiem że to uogólnienie, ale miałem kontakt ze sporą próbką populacji tychże. Całkiem niemała część powinna mieć zakaz zbliżania się do komputera. (żeby nie było -- nie jest to wycieczka osobista, takie sobie spostrzeżenie). Co prawda nie jest to java, ale: #!/usr/bin/perl -T use warnings; use strict; use CGI::Fast; while (my $cgi = new CGI::Fast) { print "Content-Type: text/html\n\n"; print "Hello world!", scalar localtime; } Krócej niż rejestracja na tym forum (która i tak przebiegła szybko i sprawnie). Działa jako CGI i FastCGI. YPB? Dodaj do tego jakiś cywilizowany ORM, trwałe połączenia do bazy danych "z pudełka", szablony cache'owane w pamięci współdzielonej, brak narzutu na kompilację przy każdym requeście (bez wynalazków a'la eaccelerator, który ZTCW psuje wyjątki, albo mmcache, w którym sam poprawiałem optymalizator i loader). A może Ruby (trochę na skróty, ale nie za bardzo)? Zrobisz prostego CRUD'a szybciej? rails . script/generate scaffold Model Kontroler Javę znam bardzo biernie, dlatego nie będzie kodu OIMW, Java nie jest przeznaczona do "Hello world", tylko do dużych aplikacji, gdzie 10KLOC rusztowania i pół tony XMLa nie robi nikomu różnicy, a aplikacja ma po prostu działać i się skalować. Może będzie flejmogennie, ale PHP traktuję jako pryszcz na dupie języków używanych na WWW. Z co bardziej denerwujących rzeczy: - model programowania a'la CGI, z profesjonalną metodą projektowania URLi przez przenoszenie plików między katalogami. mod_rewrite ratuje tu sytuację, ale (IMNSHO) jest to obejście problemu, którego w ogóle nie powinno być - poczucie bezpieczeństwa, które ma dać open_basedir i safe_mode (co chwila znajduje się moduł, w którym komuś zapomniało się dodać magicznego ifa przed fopen -- ostatnie było bodajże bz2, ale mogę się mylić) - szkolne błędy w kodzie interpretera i biblioteki standardowej - biblioteka standardowa, która rosła "tak se", bez żadnego projektu, w związku z czym burdel w niej jest niesamowity - mysql_connect. Wystarczy. - niepoważne podejście do zgłaszanych błędów. Zgłosiłem bodajże 3 (w czasach jak php4.4.4 było dżezi, czyli jakiś rok temu), z propozycjami łat itp. Do tej pory wszystkie są otwarte. Żeby nie było, nie chodzi mi o zignorowanie moich (!!11jeden!) zgłoszeń, patrząc po bugs.php.net jest to nagminne (jak również udowadnianie zgłaszającym, że to nie jest błąd, mimo że ewidentnie jest, i to exploitowalny) - kompatybilność? A co to takiego? Upgrade z x.y.z na x.y.z+1 może być ciekawym przeżyciem Ogólnie PHP zdobyło popularność dzięki swojej prostocie, ale ta popularność chyba przerosła język, który cały czas jest na etapie właśnie "Hello world, dziś jest 31 luty 107". PHP dalej cechuje się niską barierą wstępu, ale gdy później trzeba napisać aplikację (zamiast garści skryptów), byłbym skłonny stwierdzić, że role się odwracają. Tak, wiem że w PHP można napisać dużą, elegancką, rozbudowaną i szybką aplikację. Ale po co tak się męczyć?