Forum PHP.pl

Witam.

Będąc na etapie programisty znającego php trochę lepiej niż średnio rozgarnięty szympans,
poszukuję frameworka, który nauczy mnie dobrych praktyk programistycznych i projektowych (projektowych tzn. odnośnie
całego projektu, włączając w to projekt w UML, coś jak rysunek techniczny dla architekta, tu projekt dla aplikacji).
W grę wchodzi Symfony i Zend - bo znam ludzi, którzy mnie pokierują, doradzą etc.
Wiem, że znajome mi osoby od ww FM zrobią wszystko w swoich narzędziach, bardzo je chwalą, nie chcieli by ich zmieniać.
I tu pojawia się na horyzoncie jeszcze jeden konkurent Symfony i Zend - mianowicie Ruby on Rails.

Przedstawię argumenty pehapowców i rorowców i prosiłbym o rozsądne rozstrzygnięcie, czy argumenty obydwu grup
są cokolwiek warte (pokrywają się z prawdą).
W nawiasach przedstawię własną opinię dot. danego punktu.
Chciałbym podkreślić, że argumenty za lub przeciw dot. wyboru któregoś z frameworków
mają na celu odpowiedzieć na pytania:
- czy nauka danego frameworka wniesie coś dla programisty odnośnie programowania ogólnie (nie zależnie od języka),
- czy nauka danego frameworka przyda się w praktyce (szybkie wdrożenie, hosting).

Proszę również o swoje argumenty odnośnie Symfony, Zend i Ruby on Rails.

1. Argumenty pehapowców za PHP:
- PHP jest prosty do wdrożenia na serwer produkcyjny.
- Miliony użytkowników, wielka społeczność.
- W PHP można zrobić wszytsko - od strony www dla cioci co ma stoisko na bazarze (proceduralnie)
do najbardziej zaawansowanych projektów jakie można znaleźć w sieci.
- Jest ogromna ilość podręczników do PHP po polsku.
- PHP jest kompatybilne wstecz (w rozsądnych granicach).
- Nowoczesne frameworki do PHP oferują wszystko to co konkurencja (Python Django, RoR, Merb i inne).
- Programista nie musi być jednocześnie administratorem serwerów, żeby wdrożyć projekt na hosting.

1a. Argumenty pehapowców przeciw Ruby on Rails.
- Brak polskich książek (te obydwie na rynku są do wersji przestarzałych).
- Hostowanie to dodatkowa praca, dodatkowy czas, dodatkowe problemy.
- Hostowanie to koszmar i drożyzna.
- Bez sensu używać do małych projektów (czyli przez conajmniej 50% programistów).
- Kłótnie w samym sercu założycieli frameworka (odszedł twórca serwera mongrel).
- Zdarza się przepiswyanie gotowych już projektów w RoR na PHP np.
a. http://www.wykop.pl
b. http://www.oreillynet.com/ruby/blog/2007/0...ack_to_p_1.html
- Jeśli coś już pójdzie nie tak, to będziesz szukał powodu conajmniej tygodniami w źródłach RoR.
- Brak kompatybilności jakiejkolwiek wstecz. Pojawienie się nowej wersji RoR grozi powrotem do korzeni (może nie trzeba uczyć się od nowa wyświetlania "Hello World", ale trzeba
douczyć się ogromnej ilości nowych rzeczy i zapomnieć o tych starych rozwiązaniach).
- Bardzo agresywny marketing, rodem z telezakupów "Mango", tu zacytuję dla przykładu:
książka "Rails Space" M. Hartl, A.Prochazka - Helion 2008,
str. 31
"Witryna Rails Space (wykonana w RoR) będzie miała wiele elementów kojarzonych z popularnymi sieciami społecznościowymi jak Facebook".
- ZARAZ ZARAZ - Facebook jest w PHP !
str. 26
" (...)stwierdził, że gdy porządnie przyjrzał się PHP, uznał, że jest do niczego(...)".
- brak argumentów.
- Programista RoR MUSI być jednocześnie administratorem serwerów, żeby wdrożyć projekt na hosting.


2. Argumenty zwolenników Ruby on Rails:
- PHP to nakładka na język C.
- RoR jest w Ruby, a ten jest całkowicie obiektowy (moja uwaga: rozumiem, że programista RoR na co dzień wykorzystuje tą obiektowość
i tworzy sobie nowe klasy na bazie znaków "+", "-", "=", ";" itp. ).
- Sam język Ruby daje o wiele większe możliwości niż sam PHP ( moja uwaga: a mimo to, nikt nie używa samego rubiego bez frameworka do webaplikacji ).
- PHP ma koszmarną składnię.
- RoR daje duże możliwości w zakresie ORM, testów jednostkowych, MVC (moja uwaga: podobną funkcjonalność oferował już pięc lat temu CodeIgniter napisany w PHP4).
- Kto raz spróbował RoR nigdy nie wróci do PHP (moja uwaga: to zdanie można znaleźć wszędzie co ma związek z RoR, ale brak argumentacji).
- PHP to bajzel, PHP to zło.
- PHP jest dla dzieci i wieśniaków.
- Rorowiec zarabia więcej niż pehapowiec ( moja uwaga: jeśli zna tak dobrze RoR, że może porównac się z kimś kto np. 5 lat programuje w Zend
i na dodatek w swoim województwie uda mu się znaleźć pracę przy RoR to może rzeczywiście ).

Dziekuję za opnie, wskazówki, swoje uwagi i wszelkie komentarze.

Da się zrobić proste obejście, tak by każdy error będzie wyjątkiem (oczywiście poza fatalami). Dodatkowo dzięki temu obejściu możesz kontrolować, które błędny są istotne a które nie.

Huh, ja w swoim Frameworku mam w shutdown() wywołanie oddzielnej klasy. Tam wyciągam pełen backtrace. Pobieram kod źródłowy z plików i podświetlam linijki kodu, które wywołują błąd. Wygląda i działa to bardzo ładnie. Fakt, że php ma aż 2 klasy dla wyjątków(Exception oraz ErrorException) to jednak da się łatwo rozbudować pisząc własne.



Znów pokazujesz, że nie znasz php. Operacja goto weszła dopiero w wersji 5.3(pół roku temu) i ciężko jest znaleźć zespół programistów pracujący właśnie pod tą wersją(na serwerach hostingowych jest prawie zawsze 5.2). Tak więc pehapowcy nie mogą słynąć ze spaghetti code. No żechyba mówiąc o tym chodziło Ci o bezsensowne skakanie z funkcji do funkcji. To jednak można zrobić w dowolnym języku a pehapowcy wcale z tego nie słyną.

PHP to wcale nie jest tragiczne narzędzie jak to niektórzy przedstawiają. Jego problemem jest to, że jest zbyt prosty i reputację psują ludzie, którzy "programują" w nim od 3 dni i mają problem bo piszą grę internetową. Wrzucają śmieci w internet, a świat się śmieje z ogółu programistów php.

Android jakoś działa. Zresztą zdziwiłbyś się ile oprogramowania np. w takich dekoderach tv jest pisane w javie. Co nie znaczy, że byłbym fanem pisania gier AAA w javie na PS3 (IMG:style_emoticons/default/smile.gif)


No tu trochę pojechałeś, jest całkowicie odwrotnie.

BTW. tak patrze na te benchmarki i Ruby do demonów prędkości nie należy, a JRuby wydaje się jeszcze wolniejszy np. tu http://shootout.alioth.debian.org/u32/perf...est=binarytrees Na szczęście w web developerce to nie ma aż tak wielkiego znaczenia, ale jak widać są lepsze języki z porównywalnymi featuresami. I co teraz? Czy taki programista Rubego ma wszystko rzucić, olać swoje narzędzia i zacząć ewangelizować nowy język? Może troche zrozumienia dla PHPowców.

A teraz poszperaj sobie w tych benchmarkach (a które i tak są "biased") i zobacz jak mocno przyspieszył ruby od wersji 1.9. Nieźle, co? Wygląda na to iż to teraz php będzie najwolniejszy z trójcy php, python i ruby.
Co do jruby to nie wiem na jakiej podstawie sądzisz iż jest jeszcze wolniejszy? Wręcz odwrotnie, jest szybki.

ps. do tego istnieją inne implementacje rubiego, takie jak rubinius, maglev i ironruby, z których ten pierwszy wykorzystuje LLVM i ma zadatki do bycia najszybszym (ale jeszcze nie w tej chwili).

hipertracker, PHP przecież możesz wrzucić do klałda.
thek, taka mała uwaga: weź sobie czasem zanim nie napiszesz posta (szczególnie większość co napisałeś o C++, wielowątkowości, itd..) zweryfikuj chodź by w Wikipedii a potem dopiero kliknij w "Dodaj odpowiedź" (IMG:style_emoticons/default/smile.gif)

Wydaje mi się, że tutaj chodziło o burdel w większości skryptów PHP. Tego nie można kwestionować. Wzięło się to stąd, że PHP jest jednym z prostszych języków programowania i już po kilku godzinach nauki można pisać skrypty. Przez to mamy wysyp kodów wątpliwej jakości pisanych przez osoby bardzo początkujące.

Nie pamiętam już kto to pisał, ale GC wcale nie jest lekiem na problemy z pamięcią i nie zwalnia z myślenia o niej.
.NET ma świetnego GC a ostatnio jak pisałem małego tool-a w C# to spędziłem kilka godzin nad wyciekami pamięci (co prawda w C++ częściej to by się zdarzało, dużo częściej, ale jednak).

Android działa... A widziałeś jego wymagania? Uświadomię Cię (IMG:style_emoticons/default/smile.gif) Wymagania sprzętowe dla platformy Android przedstawiają się następująco - 200 MHz procesor, 32 MB RAMu i 32 MB pamięci flash. To jest mało? Tyle to posiadały stacjonarne komputery na poziomie PentiumMMX i Pentium2 (sam na takich pracowałem i uczyłem się, programowałem zresztą także na 286, który JAVY by już nie udźwignął zapewne), czyli około 15 lat temu i serwery hulały na tym. Ten drugi procek wraz ze swoim chłodzeniem był porównywalny wymiarami do obecnych urządzeń, na których Android jest uruchamiany. Nie wierzysz? Popatrz -> http://www.zgapa.pl/zgapedia/data_pictures...um_II_front.jpg bo akurat na tej fotce jest postawiony koło linijki. To jest tylko procek i jego system chłodzenia (były połączone)

Na obecnych maszynach z Androidem uruchomisz dużą część oprogramowania z tamtego okresu. JVM sama w sobie wymaga podobnej konfiguracji jak Android. Oczywiście wersja Java na komórki/telewizory czy innego typu zestawy już będące embedded ma je niższe, ale też i oferuje nieco inne możliwości. Dlatego Java Micro Edition i normalna Java są niezbyt porównywalne i podciąganie obu pod to samo jest zwyczajnym nadużyciem. Wersja ME jest bardziej ograniczona kosztem wykonywalności na innym typie urządzeń.

Nie mam racji? W takim wypadku zapytam inaczej. Jak ma się optymalizować dynamicznie aplikacja, skoro wciąż zmieniają się jej choćby dostępne zasoby czy obciążenie? Dynamiczne kompilowanie w takich wypadkach ma ciągle zmieniające się parametry pracy i co rusz musi modyfikować swoje ustawienia. W przypadku "skoków" nie zareaguje odpowiednio, gdyż musi się przestawić, co także trochę czasu potrwa. Ale moim zdaniem to już bardziej wtedy wchodzimy w "co by było gdyby babcia miała wąsy". Możemy wyszukiwać przypadki kiedy rozwiązanie ma sens i takie, kiedy go nie ma. A to sprawia, że rozmywamy temat i zaczynamy się czepiać możliwości JVM zamiast samego Ruby'ego i jego frameworków.

Test jaki zarzuciłeś jednoznacznie pokazuje jedno. Języki oparte o JVM (ale także PHP, które ma kiepskie zarządzanie pamięcią z racji i tak czyszczenia wszystkiego wraz zakończeniem skryptu) "żrą" pamięć kilkukrotnie bardziej niż inne. Wystarczy popatrzeć na pierwsze kilka od góry jak wariacje na temat Java i Scala. Inna sprawa, to taka, że zrobiono według mnie jeden karygodny błąd: wypisywanie danych do strumienia wyjścia. To jest jedna z najbardziej spowalniających operacji w jakimkolwiek języku. Jeśli strumieniem byłby dodatkowo plik to jazda byłaby konkretna. Dodatkowo na całość wpływają użyte komendy. mamy GCC, to czemu użyto choćby printf, a nie cout? (IMG:style_emoticons/default/winksmiley.jpg) Tak więc po prawdzie to wiele zależy od piszącego kod. Napisze dobry - pójdzie szybko. Napisze gorzej - poleci w benchmarku.

A ja programowałem na C64 i co z tego (IMG:style_emoticons/default/tongue.gif) Świat idzie do przodu, to że coś działało szybko na pentium2 nie znaczy, że się będzie ładnie i prosto skalować na 100 rdzeniach. O procesorach wykonujących bytecode Javy kolega słyszał? (IMG:style_emoticons/default/smile.gif)


Bo printf jest szybsze? To jest gra, każdy próbuje napisać jak najszybszy kod, czytelność kodu się nie liczy. Masz jeden problem i możesz nad nim myśleć ile chcesz. W webdeveloperce jest inaczej, masz tysiąć problemów na minute, które musisz rozwiązać jak najszybciej i żeby to wszystko było czytelne oraz podatne na zmiany.

Że niby JVM żre pamięć, przecież nie robi tego na złość użytkownikowi, tylko dzięki temu masz dodatkową funkcjonalność. Jak byś chciał mieć takie same możliwości w C++ to byś musiał to dopisać i też by żarło. Pamięć nie używana jest marnowana (IMG:style_emoticons/default/winksmiley.jpg)

Wedlug mnie takie dyskutowanie nie ma sensu.
Jezyki kompilowane zawsze bede szybsze od maszyn w. JVM/CLR lub jezykow interpretowanych bo maja zawsze przynajmniej jeden etap mniej w fazie uruchomienia aplikacji ;]

Niestety sa ludzie ktorym nie da sie wmowic i beda promowac Jave a tym bardziej ruby'iego nawet jesli to nie ma sensu.

Ten post edytował marcio 7.09.2010, 10:54:59

Świat idzie do przodu, ale to nie oznacza, że można pisać niechlujnie, bez zwracania uwagi na dostępne zasoby, pod pretekstem: "i tak tanio to mogę rozbudować". Co do skalowalności na 100 rdzeniach, to zapewne rozumiesz problematykę wielordzeniowości, sekcji krytycznych, monitorów i tak dalej. Tak więc jestem w pełni świadom tego, że 100 rdzeni jest nic nie warte gdy program nie jest do ich obsługi przystosowany. Czy będzie ich 100 czy 1 i tak wykona się całość w tym samym czasie. Akurat to był przedmiot na studiach, gdzie ćwiczenia i problematyka była dla mnie zabawą. Potrafię "myśleć równolegle". O procesorach wspomnianych nie słyszałem.

Jak to nie ma przełączania się między serwerami, dynamicznej zmiany konfiguracji? Wystarczy, że serwer jest obsługiwany przez kilka zmultiplikowanych maszyn do tego samego zadania lub kilku uniwersalnego przeznaczenia (IMG:style_emoticons/default/smile.gif) Pewne pracują, inne nie. Wiele zależy od tego czy któryś nie jest obciążony zanadto lub ma chwilową awarię. Odpowiednia automatyzacja po prostu.

Nasty. Wielowątkowość to nie wieloprocesorowość. To dwa zupełnie różne zagadnienia. Zapoznaj się z MPI i przetwarzaniem równoległym. To co jest związane z wątkami to działka pod nazwą przetwarzanie współbieżne. Oba typy problemów wałkowałem z takimi klasycznymi zadaniami jak problem filozofów czy lotnisk. Ten drugi jest mniej znany. X lotnisk z Y hangarami i Z samolotami krążącymi pomiędzy nimi. To są problemy idealne dla rozwiązywania w przetwarzaniu współbieżnym, ale niekoniecznie równolegle. Wystarczy że zauważysz jak mało softu tak naprawdę korzysta z więcej niż 1 rdzenia. A jeśli już to robi, to w bardzo ograniczonym zakresie, a to "tylko" współbieżność. Te jadące na wielowątkowości to nic czego byś nie widział na codzień. I C++ też ma biblioteki do wielowątkowości, ale najpierw trzeba się przestawić na myślenie w nich. Myślenie w obu jest podobne, ale są pewne różnice, które trzeba poznać.

To co piszesz o JVM i pochłanianiu pamięci dla mnie jest "problematyczne" zwłaszcza przy dużym obciążeniu. Wtedy każdy wolny zasób jest na miarę złota. Dorzuć do tego problematykę innej kategorii. Jakiego? Choćby sens wzywania hydraulika do zakręcenia zaworu wody w mieszkaniu, czy elektryka by wyłączyć korki i wymienić przepaloną żarówkę. Specjalista ma umiejętności których wymagasz oraz 100 innych. Ale nie zapłacisz tylko za błahe wykonane owych 2, ale dodatkowo za ruszenie jego tyłka z kanapy (IMG:style_emoticons/default/winksmiley.jpg) Z czasem ten narzut w prostych rzeczach staje się uciążliwy także ekonomicznie. Każda dodatkowa warstwa pomiędzy kodem a jego wykonaniem na maszynie to dodatkowy narzut i o tym wie każdy programista. Chcesz pisać lepiej, wydajniej? Redukuj liczbę poziomów abstrakcji do minimum niezbędnego dla danego zagadnienia.

Wiesz jakie zadanie ma CLR? co robi? pisałeś kiedyś w czymkolwiek natywnym? Bo wydaję mi się, że skoro wypowiadasz się na ten temat to musisz mieć wystarczająco szeroką wiedzę, żebyś mógł takimi stwierdzeniami rzucać i z taką stanowczością.

Ja może mniej się znam od Ciebie, dlatego poproszę Cię o wytłumaczenie mi dlaczego dwa identyczne programy, jeden napisany w C# drugi w C++, to ten w C# działa szybciej od C++, nawet po optymalizacji C++? i C++ zaczyna działać szybciej od C# (= mniej niż 60ms - czyli czas potrzebny na uruchomienie CLR-a) dopiero wtedy kiedy zaimplementujemy własny mechanizm alokacji pamięci + własny mechanizm operowania na stringach? (http://blogs.msdn.com/b/jonathanh/archive/2005/05/20/optimizing-managed-c-vs-native-c-code.aspx)

Chętnie bym posłuchał Twoich wypowiedzi.


Thek, nie nie nie. Nie o to mi chodzi, tylko o stwierdzenia typu, że można napisać aplikację desktopową w jednym wątku albo, że klasy w C++ to kolejny krok ewolucji struktur w C (IMG:style_emoticons/default/smile.gif)

Ten post edytował nasty 7.09.2010, 11:41:14

Co zyskuje na tym klient? Zmiany zrobisz szybciej i taniej niż w PHP?

Rozumiem, ze programiści ogarniający Ruby są tańsi i (przepraszam za wyrażenie) i bardziej dostępni niż programiści PHP?

Ponawiam pytanie o realne korzyści. Twierdzisz, że nanoszenie takich zmian jest tańsze/szybsze?

Śmiem twierdzić, że w dużej mierze omawiasz teraz problem programisty - nie technologii. Chyba, że system obsługi błędów działa tak "samodzielnie" jak piszesz. Jeżeli tak, to mogę spokojnie zaliczyć to jako punkt dla Ruby przy aspekcie biznesowym (IMG:style_emoticons/default/smile.gif) .

Ja nie wiem jak jakiekolwiek oprogramowanie/metoda/procedura sprawi, ze "lepiej dogadam się" z klientem. Ja mam doświadczenie, że próba pójścia "na skróty" odbijała mi się czkawką i to ze zdwojoną mocą. Co z tego, że wymagania mają formę fajnej (i rzekomo czytelnej dla osoby nietechnicznej) specyfikacji, skoro i tak przyjdzie mi to omówić z klientem. Chyba, że owe niedomówienia czy błędne rozumienie funkcjonalności zwalimy wtedy na klienta i obciążymy go kosztami...?

Powtórzę się: realna korzyść. Jak powiesz klientowi, ze Rails jest szybszy od dowolnego frameworka PHP to zada Ci jedno pytanie: "co z tego?"

Wybacz, ale serio uważasz, że klientowi spędza sen z powiek fakt, że jego aplikacja może za 10 lat utknąć w martwym punkcie?

I to wszystko tylko dzięki Ruby?

Widzę, że się nie rozumiemy trochę. Pytam: czy Ruby sprawi, że:

1. Aplikacja będzie tańsza dla klienta? Mówię o wdrożeniu/podstawowym testowaniu/poprawy błędnych założeń w specyfikacji.
2. Koszty utrzymania będą niższe?
3. Zaoszczędzimy na czymkolwiek? Np. na szkoleniu użytkowników z obsługi napisanego systemu?
4. Przedmiot umowy powstanie szybciej (i czy nie niesie to za sobą dodatkowych kosztów)?
5. Klient na myśl o swojej aplikacji będzie się co rano uśmiechał? Oczywiście żartuję.

@hipertracker - nie uważasz, że zachowujesz się trochę niekulturalnie? Silisz się na złośliwości praktycznie wobec każdego, kto nie podziela Twojego zdania (np. "miszczu"). Traktujesz, chyba większość tutaj z góry, tak jakby dla Ciebie zarezerwowane były prawdy absolutne. Przecież możesz nas zgnieść potęgą argumentu - zamiast usilnego dowodzenia, że to wszyscy wkoło nie mają racji. Dla mnie wartościowa opinia o chociażby technologii zaczyna się wtedy, gdy mimo zauważania jej ułomności - chwalimy ją, bo właśnie te zalety sprawiają, że jesteśmy w stanie przełknąć wady.

Nasty. To, że narzędzie potrafi w tle samo coś na kilka wątków zamienić, a to, że Ty oprogramowujesz aplikację wielowątkowo z założenia, to dwie różne rzeczy. Zauważ, że normalnie każda aplikacja jest jednoprocesowa, jednowątkowa. Można pisać wielowątkowe, ale to już wymaga albo pisania jej z takim założeniem, albo zdać się na środowisko uruchomieniowe/kompilator, który ją na kilka wątków rozłoży. Normalnie jednak GUI będzie szło w kolejce z innymi operacjami i stąd "zamrożenia" GUI aplikacji gdy coś robi ona. Tak więc aplikacja desktopowa normalnie jest jednowątkowa i to nie jest moja fanaberia czy wymysł.To, że programista może oddzielić pewne wątki od siebie to inna sprawa i tej nie neguję absolutnie.

Co do struct i class, to porównaj ich działanie. Nie jest to co prawda napisane w jakimkolwiek manualu, ale można strukturę nazwać bardzo uproszczonym modelem klasy o prywatnym specyfikatorze dostępu do atrybutów. Dla mnie po działaniu przypomina ona protoplastę tego, co potem zostało w C++ wprowadzone jako klasa. Tak samo jak nie pisze się w manualu wielu rzeczy bo są oczywiste, tak i tutaj wystarczy spojrzeć by zauważyć analogie. I nie mówię tutaj, że class jest w jakimś stopniu zależny od struct (dziedziczenie), ale że jest bardzo mocno rozbudowaną odmianą.

Eee, mówisz, że pisanie w językach działajacych na wirtualnych maszynach jest niechlujne, czy ja coś źle zrozumiałem? Ja nigdzie nie pisałem, żeby nie zwracać uwagi na zasoby, ale ty chyba mylisz mikro optymalizacje pod sprzęt z lepszym doborem algorytmów. Wiadomo, że jak będzie ch**owy algorytm, to i asm nie pomoże.


A pokusiłeś się o sprawdzenie jak to wygląda w językach funkcyjnych, gdzie możesz mieć równoległość niejako za darmo (bez synchronizacji)? Czy bawiliście się w to jak wygląda współbieżność w Erlangu? Pewnie nie, bo to kolejna, zła warstwa abstrakcji.

@nasty masz poczytaj: http://forum.gamedev.pl/index.php/topic,5069.0.html

@marcio, to nie jest odpowiedź. Jakiś wątek na forum wygooglowanym na poczekaniu przez anonimowych użytkowników nie jest żadną odpowiedzią. (który w dodatku pokazuję, że Java i C# są szybsze niż C++, bzdury). W moim pytaniu prosiłem Cię o argumentację Twojej (stanowczej i pretensjonalnej) tezy dotyczącej tego, że przez to, że masz JVM/CLR masz od razu wolniejszy program. (w UNIX-ach fopen() jest zaimplementowana jako nakładka na kernelowe open() co bezpośrednio otwiera plik i działa na niższym poziomie - czyli wg Twojej tezy powinna być wydajniejsza. Teraz, porównaj sobie wydajność fopen() i open() i zastanów się dlaczego (IMG:style_emoticons/default/smile.gif) ) albo udowodnij, że jest inaczej.

Domyślam się, że masz dużo ważnych spraw na głowie, że nie masz czasu i chęci żeby marnować swoje cenne uderzenia w klawiaturę, ale mimo wszystko fajnie jakbyś podał jakąś argumentację tego co twierdzisz.


@thek:
1. (zaraz wyedytuje zredagowane (IMG:style_emoticons/default/smile.gif) )

2. Odnośnie struct i tego, że strukt miałby cokolwiek wspólnego z klasami, to już dementuję (IMG:style_emoticons/default/smile.gif) struct to jest po prostu wygodny sposób na przekazywanie zmiennych. Jest po to, żeby można było przekazać powiązane ze sobą logicznie zmienne w prosty sposób zamiast przekazywać ich jako luźnych 5 intów, 3 double i 2 wskaźniki. To nie ma nic wspólnego z obiektówką.
Klasy natomiast pozwalają na położenie wyraźnej linii pomiędzy logiką aplikacji a jej stanem, co jest z kolei podstawowym filarem obiektówki i z którego wywodzi się cała reszta, jak dziedziczenia, i inne takie przyjemne zwierzątka.

Te dwa pojęcia, z pozoru podobne, nie mają ze sobą nic wspólnego. (na marginesie, to nawet taki double czy float to struct wewnętrznie - nawet w C/C++, bo w końcu musi być podzielony na części, żeby mógł trafić do rejestrów a keyword "double" jest po prostu ułatwieniem, żeby nie mieć 2 intów - przed i po przecinku, ale tu już za bardzo zbaczamy z tematu).

Ten post edytował nasty 7.09.2010, 14:32:46

Nie napisałem, że pisze się niechlujnie (w znaczeniu spaghetti code czy tego typu atrakcji), ale że używając nowych języków programiści przestają zwracać uwagę na optymalizowanie kodu, wychodząc z założenia, że zasoby (RAM, dyski, łącze) są tanie jak barszcz i można olać optymalizację niemal zupełnie. Potem powstają konstrukcje pisane na szybko, które są mało wydajne. Programista zaczyna liczyć na te optymalizacje narzędzia za bardzo bo wie, że jego błędy najprawdopodobniej będą poprawione "w locie". Kod może wyglądać na pierwszy rzut oka w porządku, ale nie musi tak być faktycznie.

Co do Erlanga to nie uczyłem się tego języka, więc nie wiem jak to w nim wygląda. Nie zmienia to jednak znaczenia całego pierwszego akapitu w moim poprzednim poście. Zrzuciłeś użycie współbieżności na narzędzie. Nie wiem w jakim stopniu język ten wymaga kodu od strony programisty by owej współbieżności używać, ale sądząc z pewności swej, zapewne nie musisz nic więcej niż "zasugerować" maszynie/kompilatorowi, by jej używał i na tym cała Twoja praca się kończy. Jeśli tak, to skąd wiesz na ile Twój program jest w Erlangu faktycznie współbieżny? Jeśli bowiem jest sekwencyjny do granic możliwości, to żaden język tego na więcej niż 1 wątek nie zamieni, choćby się miał komp spalić.

I nie równoległość. Powtarzam po raz kolejny, że to dwie różne rzeczy... Erlang jest językiem implementującym współbieżność, więc nie stosuj tych terminów zamiennie bo to nie jest to samo. Równie dobrze ja mógłbym twierdzić, że C++ i C# to także to samo, co jest nieprawdą i dobrze o tym wiesz.

A i owszem... Klasa pozwala na wiele różnych, ciekawych rzeczy i faktycznie pozwala ładnie przenieść rzeczywistość na kod. Ale zrób jedna rzecz... Wywal z niej mechanizmy obiektowości ograniczając jedynie do przechowywania danych. Staje się ona pojemnikiem na dane. Można powiedzieć, że kompozycją obiektów o typach znanych jej, najczęściej typów wbudowanych. Tylko pod takim kątem rozpatrywałem strukturę jako protoplastę klasy. Nie zamierzałem jej ponad taką baaaardzo prymitywną wersję klasy wynosić. Brak jej choćby metod najbardziej prymitywnych. Jest jedynie kolejnym typem, podobnie jak int czy double. Klasa także jest typem, ale znacznie bardziej "inteligentnym".

Erlan ma bardzo lekkie procesy (actors) które komunikują się ze sobą za pomocą wysyłanych komunikatów. Erlang (Haskell też) to język czysto funkcyjny (pure FP), na poziomie składni uniemożliwia pisanie w stylu imperatywnym (z efektami ubocznymi). Dzięki temu, każda funkcja jest niezależna od czasu i kolejności wywołania, bo zawsze zwróci tą samą wartość, jeśli zostaną jej wysłane te same parametry wejściowe. I to powoduje, że taki kod łatwo się skaluje na wielu rdzeniach, maszynach. Można z automatu wrzucić po jednej funkcji na oddzielny rdzeń tak aby maksymalnie równolegle wszystko działało. Erlang jako język nie jest jakimś demonem szybkości, ale doskonale się sprawdza tam gdzie trzeba uruchomić tysiące, czy setki tysięcy, równoległych procesów. W języku pure FP sytuacja się tylko komplikuje, kiedy trzeba użyć dostępu do obszaru który nie może być traktowany jako pure. No, dosyć trudno obejść się bez np. I/O. Erlang zdaje się korzysta wtedy ze swojej bazy Mnesia. Ale się nie wgłębiałem.

Z tego, co wiem, to Scala jako język jest dużo szybsza od Erlanga. Posiada również wbudowaną bibliotekę implementującą funkcjonalność aktorów (zresztą o składni wzorowanej na Erlangu). Jest także ciekawy framework napisany w Scali (Akka) który ma nie tylko 4x szybszą implementację aktorów od tych natywnych w Scali (w nowej wersji Scala ma to wchłonąć) i na dodatek można je odpalać zdalnie. Akkę można zintegrować z webowymi frameworkami Lift (Scala) czy Play (Java, Scala). Ogólnie języki silnie wspierające FP (poza wymienionymi, można by wspomnieć o Clojure i F#) znacznie uproszczają pisanie kodu wykorzystującego wiele procesorów. Czyli w sam raz na nasze czasy i trendy. Nie rośnie już częstotliwość procesorów, za to rośnie ilość ich rdzeni...

Tak, ale jest też coś takiego jak przedwczesna optymalizacja, na którą niepotrzebnie się traci czas.


A czy lepszy jest kod, który wygląda biednie, najeżony mikrooptymalizacjami, gdzie logika jest zaciemniona? Jak coś chodzi za wolno to po to powstały profilery, żeby likwidować wąskie gardła. Nie wszystko jest symulacją w czasie rzeczywistym. Czas programisty sporo kosztuje.


Przepraszam za pisanie skrótami, chodziło mi o równoległość w takich językach funkcyjnych jak np. Haskell i jak niemutowalny stan ją upraszcza oraz model współbieźności na aktorach opisany wyżej przez hipertrackera. Oczywiście cudów nie ma i kompilator sam nie przerobi algorytmu na wersje równoległą.

Może cała ta dyskusja o klasach i strukturach wzieła się stąd, że o ile pamiętam, w C++ słowo kluczowe struct od class róźni się tylko tym, że struct ma elementy oznaczone domyślnie jako public, a class jako private (IMG:style_emoticons/default/winksmiley.jpg)