Komentowana treść: Ruby 1.9.0 dla MorphOS-a
17.02.2007 15:49
[#1]
Re: Ruby 1.9.0 dla MorphOS-a
Tak sobie z ciekawości poczytałem co nieco o tym języku. Muszę powiedzieć, że jako programistę wychowanego na języku C i później C++, przerażają mnie pomysły w rodzaju wskakiwania do dowolnego miejsca funkcji, "przedłużania żywota" zmiennym lokalnym, przeciążanie metod pojedynczym obiektom a nie całym klasom. Moim zdaniem to przepis na bałagan, a jeszcze jest garbage collector, czyli kolejny sposób na lekceważenie zasady zwalniania użytych zasobów. Co prawda Ruby to język interpretowany i najczęściej używany do aplikacji WWW, tak jak PHP, ale tolerancja tych języków na lenistwo i niekompetencję programistów wyjaśnia może zachwycający z reguły poziom bezpieczeństwa ich dzieł...
Niemniej należy się cieszyć, że taki jest na MOS-a wybór języków programowania. Od przybytku głowa nie boli, choć ja raczej użytkownikiem Ruby się nie stanę.
Niemniej należy się cieszyć, że taki jest na MOS-a wybór języków programowania. Od przybytku głowa nie boli, choć ja raczej użytkownikiem Ruby się nie stanę.
17.02.2007 20:05
[#5]
Re: Ruby 1.9.0 dla MorphOS-a
@MinisterQ, post #3
Myślę, że to jest kwestia zastosowań.
Danego języka należy użyć jeśli jest on w danej sytuacji dobrym lub jedynym rozwiązaniem. Tak np. nieinterpretowalne języki dawałyby zbyt dużą swobodę twórcom programów na komercyjnych wielo-kontowych serwerach (nad skryptem interpretowalnym kontrolę ma mechanizm wykonujący, który jest zazwyczaj szeroko konfigurowalny i umożliwia definicję zabezpieczeń i ograniczeń). Tu np. zastosowanie znajduje PHP czy takie Ruby.
Jeżeli w programie nie ma też elementów, w których ważną cechą jest szybkość działania, to języki skryptowe umożliwiają automatyczne wykonywanie wielu zadań tylko dzięki znajomości prostych zasad działania języka, jego składni (np. skrypty bash, AmigaDOS, Arexx).
Oczywiście zastosowania swoje znajduje też język bardzo niskopoziomowy jak Assembler. W końcu ktoś musi oprogramować niskopoziomowe partie niektórych systemów, sterowników, ktoś musi napisać kompilator (a jak to zrobić bez znajomości kodu maszynowego procesora docelowego)? Swoją drogą pisząc kiedyś oprogramowanie dla komórki (programy albo wstawki do firmware) przekonałem się jak dużo można zdziałać mając znajomość asma (i jak wiele można z takiej komórki wycisnąć sztuczkami w stylu 10 instrukcji procesora a cuda na kiju się dzieją). ;)
Szerokiego zastosowania popularnego języka C/C++ nawet chyba nie trzeba tłumaczyć (przy czym wybór pomiędzy użyciem C a C++ także nie powinien polegać na upodobaniu a na przewidywanej konstrukcji programu).
Tak czy owak każdy język programowania ma uzasadnienie swojego istnienia w postaci pewnych (choćby bardzo wąskich) zastosowań i dyskusja na temat wyższości jednego nad drugim (gdzieniegdzie popularna) wydaje mi się bezcelowa.
Danego języka należy użyć jeśli jest on w danej sytuacji dobrym lub jedynym rozwiązaniem. Tak np. nieinterpretowalne języki dawałyby zbyt dużą swobodę twórcom programów na komercyjnych wielo-kontowych serwerach (nad skryptem interpretowalnym kontrolę ma mechanizm wykonujący, który jest zazwyczaj szeroko konfigurowalny i umożliwia definicję zabezpieczeń i ograniczeń). Tu np. zastosowanie znajduje PHP czy takie Ruby.
Jeżeli w programie nie ma też elementów, w których ważną cechą jest szybkość działania, to języki skryptowe umożliwiają automatyczne wykonywanie wielu zadań tylko dzięki znajomości prostych zasad działania języka, jego składni (np. skrypty bash, AmigaDOS, Arexx).
Oczywiście zastosowania swoje znajduje też język bardzo niskopoziomowy jak Assembler. W końcu ktoś musi oprogramować niskopoziomowe partie niektórych systemów, sterowników, ktoś musi napisać kompilator (a jak to zrobić bez znajomości kodu maszynowego procesora docelowego)? Swoją drogą pisząc kiedyś oprogramowanie dla komórki (programy albo wstawki do firmware) przekonałem się jak dużo można zdziałać mając znajomość asma (i jak wiele można z takiej komórki wycisnąć sztuczkami w stylu 10 instrukcji procesora a cuda na kiju się dzieją). ;)
Szerokiego zastosowania popularnego języka C/C++ nawet chyba nie trzeba tłumaczyć (przy czym wybór pomiędzy użyciem C a C++ także nie powinien polegać na upodobaniu a na przewidywanej konstrukcji programu).
Tak czy owak każdy język programowania ma uzasadnienie swojego istnienia w postaci pewnych (choćby bardzo wąskich) zastosowań i dyskusja na temat wyższości jednego nad drugim (gdzieniegdzie popularna) wydaje mi się bezcelowa.
18.02.2007 02:55
[#8]
Re: Ruby 1.9.0 dla MorphOS-a
@Grzegorz Kraszewski, post #7
heh, wyaje mi sie ze nigy nie uzywales bardziej wysokopoziomowych frameworkow. ruby nie opiera sie na jezyku. istnieja systemy aka ruby on rails (bardzo przednie, ale jeszcze mlo popularne) ktore niszcza wszystko o czym my storzy programisci slyszelismy. zachecam do dyskusji na forum. moze wyproduujemy cos wartosciowego:)
18.02.2007 10:21
[#9]
Re: Ruby 1.9.0 dla MorphOS-a
@kiero, post #8
coz, termin edycji minal wiec wyedytuje w nowym komentarzu. z tym niszczeniem to moze nieco przegiecie (popre 'alkomat przy kazdym komputerze', nowy projekt ministra edukacji:), ale ogolnie frameworki (php to nie framework krashan:) powoduja ze tworzenie aplikacji staje sie prostsze. czasami kosztem wydajnosci, ale cos. zawsze mozna dorzucic wiecej procesorow:)
Ostatnia edycja: 18.02.07 10:22:34
Ostatnia edycja: 18.02.07 10:22:34
18.02.2007 12:24
[#12]
Re: Ruby 1.9.0 dla MorphOS-a
@Grzegorz Kraszewski, post #1
Chodzi o to aby dać możliwość zrobienia jak najwięcej i uczynić pracę projektanta/programisty jak najwygodniejszą. Sprowadza się to między innymi do tezy iż im mniej kodu należy napisać tym lepiej. Te mechanizmy, o których wspominasz nie są po to żeby używać ich na siłe tylko po to żeby użyć ich gdy to jest potrzebne i przynosi wymierne korzyści. Wtedy przeważnie nie wpływają negatywnie na strukturę i czytelność programu. Dobrze zaprojektowany program ma tendencję do tego że pewne cechy wynikają w nim nie z kodu a z samego projektu a kolejne rozszerzenia, które dodajemy naturalnie się do niego wpasowują. Program to nie monolit a kolejne warstwy, które korzystają z siebie tworząc dla każdej następnej środowisko w którym działa. Mechanizm GC jest również elementem odciążającym programistę, w bardziej złożonym programie zwolnienie wszystkich zasobów jest bardzo kosztowne, nie tylko jeśli chodzi o ilość czasu potrzebny do wyśledzenia w kodzie zależności i ustalenia kto będzie w danym momencie właścicielem obiektu ale również jest to koszt w trakcie wykonywania potrzebny na każdy warunek sprawdzajacy czy to co mamy zwolnić w ogole zostało zaalokowane. W pewnych sytuacjach z prostej funkcji mającej 3 linijki robi się mało czytelny potworek długi na 15 - w C++ musimy uwzględnić, że w zasadzie w każdym miejscu możemy dostać exception a niestety - i tu jeden z nielicznych ale minus tego języka - w C++ nie ma finally.
I jeszcze jedna rzecz na koniec. Może Cię to zdziwi ale technika z której korzystasz przy pisaniu klas MUI czyli BOOPSI daje takie możliwości, które jak napisałeś powyżej niepodobają Ci się. Jeżeli dispatchera zamiast na switchu zrobisz na mapie i dasz możliwość modyfikacji tego mapa to pojawia się możliwość dodawania a nawet usuwania dynamicznie metod dla całej klasy lub dla pojedynczych obiektów. Podobnie można też zorganizować atrybuty co umożliwi ich dynamiczne modyfikowanie. Mozna tez bez problemu wyobrazić sobie zastosowanie takich konstrukcji. Zamiast dziedziczyc i tworzyć 10 różnych klas gdy część funkcjonalności musi być osiągalna przez wywołąnie metody klasy potomnej z klasy bazowej, tworzymy obiekty jednej klasy i ustawiamy im odpowiednie metody - 1 linijka kontra zrobienie klasy i dopisanie gdzies przy starcie wywolania jej tworzenia. Wykonalismy mniej pracy (mniej linijek kodu), uzyskany efekt robi to samo a rozwiazanie to jest czytelniejsze i mnej podatne na bledy. W jednym miejscu widzimy co sie dzieje i nie musimy analizować co robi 10 klas gdy wrócimy do tego kodu po kilku miesiącach.
I jeszcze jedna rzecz na koniec. Może Cię to zdziwi ale technika z której korzystasz przy pisaniu klas MUI czyli BOOPSI daje takie możliwości, które jak napisałeś powyżej niepodobają Ci się. Jeżeli dispatchera zamiast na switchu zrobisz na mapie i dasz możliwość modyfikacji tego mapa to pojawia się możliwość dodawania a nawet usuwania dynamicznie metod dla całej klasy lub dla pojedynczych obiektów. Podobnie można też zorganizować atrybuty co umożliwi ich dynamiczne modyfikowanie. Mozna tez bez problemu wyobrazić sobie zastosowanie takich konstrukcji. Zamiast dziedziczyc i tworzyć 10 różnych klas gdy część funkcjonalności musi być osiągalna przez wywołąnie metody klasy potomnej z klasy bazowej, tworzymy obiekty jednej klasy i ustawiamy im odpowiednie metody - 1 linijka kontra zrobienie klasy i dopisanie gdzies przy starcie wywolania jej tworzenia. Wykonalismy mniej pracy (mniej linijek kodu), uzyskany efekt robi to samo a rozwiazanie to jest czytelniejsze i mnej podatne na bledy. W jednym miejscu widzimy co sie dzieje i nie musimy analizować co robi 10 klas gdy wrócimy do tego kodu po kilku miesiącach.
18.02.2007 16:43
[#13]
Re: Ruby 1.9.0 dla MorphOS-a
@smith, post #11
Nie ma żadnego powodu żeby wybrać C zamiast C++ jeżeli dysponujemy obydwoma kompilatorami.
Jeżeli chodzi o kompilator to tak, bo w tym przypadku akurat kompilator C++ kompiluje bez problemów kod C.
Chodziło mi jednak raczej o kod, a właściwie rozwiązania programistyczne implementowane do programu. W pełni obiektowa metoda programowania, czyli główny ficzer jaki wprowadziły dwa plusy do zwykłego C, nie w każdym programie wydaje się sensowna. Szczególnie w malutkich programach nie ma większego sensu opakowywać wszystko w klasy na siłę.
Jeżeli chodzi o kompilator to tak, bo w tym przypadku akurat kompilator C++ kompiluje bez problemów kod C.
Chodziło mi jednak raczej o kod, a właściwie rozwiązania programistyczne implementowane do programu. W pełni obiektowa metoda programowania, czyli główny ficzer jaki wprowadziły dwa plusy do zwykłego C, nie w każdym programie wydaje się sensowna. Szczególnie w malutkich programach nie ma większego sensu opakowywać wszystko w klasy na siłę.