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


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ź"

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ę 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? 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 Ś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ł?


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

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.

Ś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 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 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

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 .

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 ) 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 )

2. Odnośnie struct i tego, że strukt miałby cokolwiek wspólnego z klasami, to już dementuję 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).

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

W C# jest podobnie tylko ze struktura jest juz bardziej rozbudowana od tej w C, w C to tylko kontener na dane roznego typu.

@nasty akurat w poniedzialek i wczoraj mialem poprawki w szkole ;] wiec czasu nie mialem, a w linku podanym jest wszystko napisane wystarczy przeczytac te 15 stron

Marcio, umówmy się, że jak znowu zaczniesz pieprzyć głupoty to potem o nich poczytasz, żebyś mógł grzecznie przeprosić, że się mylisz. Bo widzę, że nie mam co liczyć na to żebyś najpierw się dowiedział a dopiero potem pisał.

Klasa i struktura w C# to to samo? Mylisz się.

Jedną z podstawowych różnic jaka jest pomiędzy klasą a strukturą w C# jest taka, że klasy w pamięci lądują na stercie, razem z innymi klasami. Inaczej są zarządzane, inaczej są obsługiwane ich zasięgi, inaczej są czyszczone przez GC.
Struktury lądują na stosie, czyli tam gdzie lądują inty, double, bool, i inne take "prymitywne" typy. Jest traktowana na równi z nimi pod każdym względem. Dlatego też, inaczej są tworzone kopie a referencje na klasy. i też z bardzo podobnego powodu struktury nie mogą być nullem a muszą być zainicjalizowane. to się sprowadza to tego czym one są.
Tak jak powiedziałem, struktura to tylko jest po to, żeby nie przekazywać 15 intów, 8 wskaźników i kilku floatów jak się przekazuję to gdzieś dalej.

Dlatego jeszcze raz proszę, zamiast myśleć, że jesteś fajny jak wyguglujesz mi zaraz znowu jakieś nowe forum, najpierw wiedz o czym mówisz a dopiero potem mów albo przynajmniej jak już to zaczynaj zdania od "wydaje mi się" a nie "niektórzy tego nigdy nie zrozumieją". To Ty nie rozumiesz.

Tyle, że mi nie chodzi o optymalizacje, które zaciemniają kod, ale takie, gdzie ich sens jest po prostu wątpliwy. Przykładowo używamy zmiennych, których kopie w programie zaczynają się mnożyć, zamiast być raz i koniec, bo zmienne lokalne mają szybszy dostęp i ktoś myśli, że jak ma zmienną z $_GET i pchnie je do nowej lokalnej to mu to znacząco przyspieszy kod. A gdy tę zmienną jeszcze znowu gdzieś w pętli wyżej walnie to też będzie jeszcze szybszy, zamiast normalnie i po ludzku ciągle z potraktowanej filtrami GET korzystać Przez takie coś tylko pamięć zużywa, zaciemnia faktycznie kod (wiele wersji tej samej zmiennej). Ja nie jestem zwolennikiem szarpania się na 1/100 sekundy. Kod może być odrobinę wolniejszy jeśli zachowuje jakąś sensowną strukturę. Też nie jestem zwolennikiem udziwniania na siłę, tylko po to, by coś było minimalnie tylko szybsze. Tak mogą się bawić maniacy-entuzjaści.

Dlatego cieszę się, że póki co hipertracker zszedł z retoryki "php to jedynie zło" ( ) i zamiast tylko wychwalać Ruby i jego implementacje rozmowa toczy się może nieco offtopem, ale jednak wokół szerszego grona języków i ich przydatności oraz możliwościach. To na pewno redukuje napięcie wywołane forsowaniem argumentacji, która często pasowała do wielu języków, a była przypisywana jedynie Ruby'emu i odnosiła się głównie do pewnych stereotypów czy zachowań ludzkich, a nie języka czy frameworków. Zresztą chyba pewne głosy tutaj dały nieco innym do myślenia, że jednak php-owcy to ludzie nie tylko na jeden język ukierunkowani i mający wiedzę z szerokiego spektrum. Jak w każdym języku są mniej i bardziej uzdolnieni, jednak łatka php-owca jako niezbyt rozgarniętego i małoletniego kolesia o wąskich horyzontach jest dla pewnego grona po prostu krzywdząca. Zwłaszcza tych, którzy potrafią wiele z tego języka wycisnąć poza typowy CRUD. Nie każdy zaczynał programowanie od php i nie każdy na nim skończy. Duża część zna techniki oraz rozwiązania, których w php po prostu nie ma lub nie planuje się wdrożyć, a te które właśnie teraz wchodzą, są im od lat znane. Wystarczy spojrzeć na namespace'y, którymi już od początku w C++ operowałem (wtedy jeszcze wedle słów prowadzącego: "To ma być. Z czasem Wam wyjaśnimy co to i po co, ale póki co piszcie by się program skompilował."), a które dopiero co weszły. Potrafią nieźle namieszać i całkowicie zmienić jego działanie (choćby przeciążanie funkcji, także tych wbudowanych).

Co do Haskella i innych języków to wiadomo, że nigdy jeden człowiek nie pozna wszystkich języków. Aczkolwiek czytając o tym pierwszym, wygląda na całkiem udaną formę niejawnie przekształcającą kod do formy rzeczywiście równoległej. A przynajmniej mu się to w jakimś stopniu udaje, bez znajomości przez programistę przetwarzania równoległego Akurat jestem po uczelni, gdzie zagadnienia równoległości i współbieżności były mocno akcentowane i jako uczelnia wysoko nie tylko w tym stoi, ale i faktycznie tę wiedzę studentom chce wpajać i wpaja (współbieżność - Java, równoległość - MPI). Niezależnie od wyboru specjalizacji. Do dziś pewnie niektórym śnią się koszmary, gdzie główną rolę grają MPI_Scatter i MPI_Gather

Ze strukturą jest właśnie to co mówiliśmy oboje. Publiczny dostęp do atrybutów, ale to nadal tylko kontener na inne typy. Od strony budowy, na poziomie kontenera danych, jedynie to je różni. Dalej już klasa ma cały wachlarz możliwości. Tego już strukturze brak i stąd nazwałem ją prymitywną klasą czy też jej protoplastą. Nic więcej nie chciałem strukturze przypisywać, gdyż brak jej nie tylko wszystkich elementów obiektowości jak i choćby możliwości utworzenia w jej ciele metody. Jest tylko kontenerem innych typów danych. Brzmi to może nieco dziwnie, ale jest tylko i aż: Prostym typem złożonym.

@nasty po pierwsze nie powiedzielem ze struktury i klasy to to samo.
po drugie nie interesuje mnie to jak to wyglada od strony kuchni.
po 3 jak robia takie porownania w ksiazkach i tutorialach cos w tym jest, nie mowie tak bo tak pisza w necie jakby nie patrzec na "strukture" oby "typow" to i jedna i druga moga byc kontenerami na dane i tyle to jest to co je upodabnia do siebie.

Przyznam że na początku trochę mnie zjeżyły wypowiedzi hipertrakera i Raderka, bo sugerowały mi że ostatnie 5 - 7 lat przyswajania PHP idzie w cholerę, ale na dobrą sprawę żaden programista PHP nie ma się co tym przejmować. Uważam że nie ma co się wdawać w dyskusje na temat GC i serwerów aplikacji i tego gdzie one są lepsze, a gdzie ich w ogóle nie ma, bo to jest jak dyskutować o gustach. Oba te aspekty można w obu językach dopracować lub w przypadku serwera aplikacji dla PHP po prostu napisać. Na upartego można nawet stworzyć JPHP jeśli będzie to potrzebne. Natomiast jeśli idzie o metodykę programowania to już można się trochę pospierać.

Przyznaję że dla mnie takie (po)twory jak Joomla, Wordpress, PhpBB o PHPFusion nie wspominając nawet to jest kompletna bzdura i horror. Są jednak metodologie frameworków jak Kohana czy Sy(m)fony - skoro już rozmawiamy o Rails - które narzucają dobre praktyki i specjalnego znaczenia nie ma w nich interpretacja MVC.

Dlatego ( tutaj moja odpowiedź na pierwszy post Wiktor P. ) - Jeśli masz się czegoś uczyć, a znasz już PHP to odpuść sobie Ruby i zajmij się Kohaną oraz koniecznie skoro będziesz miał jakichś tutorów Symfony i Zend'em. Nauczą cię praktyk które zaobserwowałem również w innych językach, a przerzucenie się na te "inne języki" będzie tylko kwestią przyswojenia drobnych różnic. Słowami Rugbisty ( no musiał za tą tonę pomyj jakoś odpłacić ) - Brnij w to bagno dalej. - Jeśli chcesz być dobry to nauczysz się w nim pływać.

Przyznaję, nie piszę tego z punktu widzenia mistrza klawiatury z Bóg wie jakim doświadczeniem, ale z punktu widzenia osoby dla której przyswajalność metodyki jej zrozumienie i prostota ma dosyć istotne znaczenie. Uważam że większość języków jest do siebie bardzo podobna i jeśli bym miał się czymś teraz zająć na poważnie to bez zastanowienia wybrałbym C++. Liznąłem go trochę podobnie ja Ruby, Javy, SmallTalka i ASM'a ( sic! ) i tak na prawdę programiści ( nie Pr0Gr4mi5ćy ) tego języka nie zaznają chudych lat jeszcze przez bardzo długi okres czasu. Natomiast wiedza zdobyta przy PHP na pewno mi/ci pomoże i ułatwi to zadanie.

- Miał być cholera krótki wstęp żeby nie było nie na temat...
Tak na prawdę nie o tym chciałem napisać. ( Tak jakoś samo wyszło. )
Ostatnio usłyszałem o nowym wynalazku developerów Google Corp., a mianowicie o języku GO. Jako że w tym temacie już wypowiadają się osoby z wyższej półki tego forum ( i tak was nienawidzę ) i ścierają się z miłośnikami innego języka których opinie też chciałbym poznać. Uprzejmie zapytowywuję: Warto?

Youtube: The Go Programming Language Rob Pike 30 Października 2009