Jak zapewne większość się zorientowała, jestem z natury podejrzliwym pesymistą, który zawsze szuka drugiego dna. Tak też jest z zaskakującym ruchem firmy Microsoft, produkującą systemy z rodziny Windows, które postrzegane są przez młodych, bądź tych bardziej fanatycznie nastawionych, jako wrogowie Linuksa. Mianowicie Microsoft sponsoruje imprezę Linuksową. Na pierwszy rzut oka wygląda na to, że twórcy Windows chcą wkupić się w środowisko OpenSource. Moim zdaniem MS chce sprawdzić czy łatwo się Linuksowcy sprzedadzą swojemu "wrogowi".
UWAGA SPOILER KSIĄŻKI SREBRO STEVENA SAVILE
Ale mam też ciekawą teorię, dużo ciekawszą. Za "dobre wyniki w nauce, bardzo dobre zachowanie oraz ogromne zaangażowanie w życie klasy i okazaną pomoc [podwójna spacja] w roku szkolnym 2009/2010" otrzymałem książkę Stevena Savile'a pod tytułem "Srebro". Ta książka opowiada o pewnych złych ludziach "sykariuszach", których taktyką było zaprzyjaźnić się z ofiarą, a następnie zaatakować z skutkiem śmiertelnym i wołać dla niepoznaki o pomoc dla ofiary, jak by to zrobił prawdziwy przyjaciel. Microsoft też próbuje się zaatakować podobną taktyką.
2010-08-15
Qt Creator - on_nazwaObiektu_sygnal
Dzisiaj odkryłem kolejną fajną rzecz w origranue Qt Creator. Mianowicie, gdy mam obiekt w formularzu z desingera, który np. nazywa sie loadButton i jest typu QPushButton, więc ma sygnał clicked(), mogę napisać w sekcji slots "void on_loadButton_clicked()", a Qt sam mi podłączy sygnał do slotu. Dzięki tej "sztuczce" łatwiej mi rozwijać swoje mikro projekty.
Wpis króciutki, ponieważ to co chciałem napisać nie mieściło się na blipie. Takie wpisy będą oznaczane specjalnym tagiem "miniblog", a linki do nich będą na blipie.
Wpis króciutki, ponieważ to co chciałem napisać nie mieściło się na blipie. Takie wpisy będą oznaczane specjalnym tagiem "miniblog", a linki do nich będą na blipie.
2010-07-30
Obiektowe boom i puchnący kod
Niektórzy wiedzą, że jestem już w zaawansowanym stadium osobistego projektu żartobliwie nazwanego "JAVATAR", który polega na poznaniu JAVA w stopniu pozwalającym, na napisanie przeciętnej aplikacji. Co prawda mam już niewielkie opóźnienie, ale nie i tym będzie dzisiejszy wpis.
W czasie nauki C++ często zauważałem jak wychwalano obiekty. Rzeczywiście, często ułatwiają prace, ponieważ operowanie na nich jest "wygodniejsze i bardziej intuicyjne". Podejrzewam, że ten pogląd bierze się stąd, że programista pod jedną nazwą ma dostęp do funkcji, zwanych metodami i danych. Mi, osobiście, się to jednak nie podoba, ponieważ daje złudny obraz obiektu, jako danych i kodu w jednym miejscu. W rzeczywistości jednak są to stare, dobre funkcje z wskaźnikiem na stukture w pierwszym, niewidocznym dla programisry argumencie. Myśle, że fakt, iż kod nie jest bezpośrednio połączony z danymi, jest istotny, jednak często nasi nauczyciele, nie ważne czy to są ludzie, czy kursy lub książki, "zapominają" nas o tym poinformować. Może przyczyną takiego stanu rzeczy jest to, że cała magia OOP nagle znika? Doświadczony programista zaraz by zwrócił uwagę na "przewspaniałą" możliwość dziedziczenia. Niestety, to tylko doklejanie kolejnych pòl do struktury i wywołanie metody o innej nazwie. Przeciążone funkcje też nie są magiczne, suma(int, double) to sumaid, a suma(int, int) to sumaii. Nie, nie twierdze, że obiektowość jest zła czy nie potrzeba, ponieważ z pewnością ułatwia zarządzanie zasobami ludzkimi i kodem projektu. Na kilku spotkaniach ustalane są podstawowe obiekty, ich interfejsy, oraz zależności, a później można przejść do tego, do czego programiści są stworzeni, czyli do klepania kodu w własnym zakresie. Do tego system szablonów skutecznie ułatwia pisanie uniwersalnych i łatwiejszych w zarządzaniu, więc też utrzymaniu, projektów.
Kazdy się z pewnością domyśla, że im mniejszy jest kod (mniej ma linijek), tym łatwiej nim zarządzać, jednak twórcy JAVA chyba o tym zapomnieli. Samo OOP wymaga napisania dodatkowego kodu dla każdej z klas i zachowując "dobre maniery" programowania obiektowego (np. dodawanie set i get dla zmiennych do których użytkownik ma określony dostęp) okazuje się, że kod, który powinien zajmować 2kB, nagle zajmuje 6 kB. W przypadku większych projektów pewnie tak tego nie widać, ale nawet przy założeniu, że kod urośnie o 30% mnie przeraża. Nie chodzi mi tutaj o to, że kod musi być przeciskany przez wolne łącza lub zajmuje dużo miejsca na dysku, zawsze może być skompresowany, ale o to, że programista, który dołącza się do projektu musi przeczytać prawie o 1/3 kodu więcej, by ogarnąć całość programu i systemy nim rządzące. W rzeczywistości jest to duża strata czasu, na którą pewnie niektórzy się nie godzą i nie czytają całego kodu, więc z pod ich palców wychodzą znaczki, które robią to, co już ktoś inny napisał. Kod jeszcze bardziej puchnie, a gdy taka sytuacja się zdarza to już po krótkim czasie dochodzi się do tego, że trzeba przepisać kod. Jednak komu chce się przepisać aplikacje, która ma miliard linii kodu? Dla firmy jest to nie do pomyślenia, ponieważ zatrzymuje rozwój całej aplikacji, stwarza nowe miejsce dla błędów i nie gwarantuje, że stare się nie powtórzą.
Całkiem inną rzeczą, która mnie w JAVA irytuje jest to, że nie ma szablonów funkcji, ani, sądząc po podstawowym api JAVA, żadnych mechanizmów pozwalających na wykorzystanie tego samego kodu w nieco innej sytuacji. Powstae niezdrowa sytuacja, w której trzeba przeciążyć funkcje dla każdego typu podstawowego osobno. Jest to szczególnie denerwujące gdy w naszej obsłudze któregoś z typów wkradnie się malutki błąd, którego zauważenie często zajmuje sporo czasu. Jeszcze musi być odzielna wersja dla obiektów... Nagle oskazuje się, że niepotrzebnie trzeba napisać o połowę więcej kodu.
W JAVA nie da się też przeciążać operatorów, co w przypadku np. BigDecimals. Nie dość że jest bardzo nieintuicyjne, to jeszcze sprawia, że kod jest mniej przejrzysty i bardziej zagmatwany. Człowiek widząc "a > b" szybciej zorientuje się o co chodzi niż składnia wywołująca "compareTo", której szczerze jeszcze nie rozumiem...
W czasie nauki C++ często zauważałem jak wychwalano obiekty. Rzeczywiście, często ułatwiają prace, ponieważ operowanie na nich jest "wygodniejsze i bardziej intuicyjne". Podejrzewam, że ten pogląd bierze się stąd, że programista pod jedną nazwą ma dostęp do funkcji, zwanych metodami i danych. Mi, osobiście, się to jednak nie podoba, ponieważ daje złudny obraz obiektu, jako danych i kodu w jednym miejscu. W rzeczywistości jednak są to stare, dobre funkcje z wskaźnikiem na stukture w pierwszym, niewidocznym dla programisry argumencie. Myśle, że fakt, iż kod nie jest bezpośrednio połączony z danymi, jest istotny, jednak często nasi nauczyciele, nie ważne czy to są ludzie, czy kursy lub książki, "zapominają" nas o tym poinformować. Może przyczyną takiego stanu rzeczy jest to, że cała magia OOP nagle znika? Doświadczony programista zaraz by zwrócił uwagę na "przewspaniałą" możliwość dziedziczenia. Niestety, to tylko doklejanie kolejnych pòl do struktury i wywołanie metody o innej nazwie. Przeciążone funkcje też nie są magiczne, suma(int, double) to sumaid, a suma(int, int) to sumaii. Nie, nie twierdze, że obiektowość jest zła czy nie potrzeba, ponieważ z pewnością ułatwia zarządzanie zasobami ludzkimi i kodem projektu. Na kilku spotkaniach ustalane są podstawowe obiekty, ich interfejsy, oraz zależności, a później można przejść do tego, do czego programiści są stworzeni, czyli do klepania kodu w własnym zakresie. Do tego system szablonów skutecznie ułatwia pisanie uniwersalnych i łatwiejszych w zarządzaniu, więc też utrzymaniu, projektów.
Kazdy się z pewnością domyśla, że im mniejszy jest kod (mniej ma linijek), tym łatwiej nim zarządzać, jednak twórcy JAVA chyba o tym zapomnieli. Samo OOP wymaga napisania dodatkowego kodu dla każdej z klas i zachowując "dobre maniery" programowania obiektowego (np. dodawanie set i get dla zmiennych do których użytkownik ma określony dostęp) okazuje się, że kod, który powinien zajmować 2kB, nagle zajmuje 6 kB. W przypadku większych projektów pewnie tak tego nie widać, ale nawet przy założeniu, że kod urośnie o 30% mnie przeraża. Nie chodzi mi tutaj o to, że kod musi być przeciskany przez wolne łącza lub zajmuje dużo miejsca na dysku, zawsze może być skompresowany, ale o to, że programista, który dołącza się do projektu musi przeczytać prawie o 1/3 kodu więcej, by ogarnąć całość programu i systemy nim rządzące. W rzeczywistości jest to duża strata czasu, na którą pewnie niektórzy się nie godzą i nie czytają całego kodu, więc z pod ich palców wychodzą znaczki, które robią to, co już ktoś inny napisał. Kod jeszcze bardziej puchnie, a gdy taka sytuacja się zdarza to już po krótkim czasie dochodzi się do tego, że trzeba przepisać kod. Jednak komu chce się przepisać aplikacje, która ma miliard linii kodu? Dla firmy jest to nie do pomyślenia, ponieważ zatrzymuje rozwój całej aplikacji, stwarza nowe miejsce dla błędów i nie gwarantuje, że stare się nie powtórzą.
Całkiem inną rzeczą, która mnie w JAVA irytuje jest to, że nie ma szablonów funkcji, ani, sądząc po podstawowym api JAVA, żadnych mechanizmów pozwalających na wykorzystanie tego samego kodu w nieco innej sytuacji. Powstae niezdrowa sytuacja, w której trzeba przeciążyć funkcje dla każdego typu podstawowego osobno. Jest to szczególnie denerwujące gdy w naszej obsłudze któregoś z typów wkradnie się malutki błąd, którego zauważenie często zajmuje sporo czasu. Jeszcze musi być odzielna wersja dla obiektów... Nagle oskazuje się, że niepotrzebnie trzeba napisać o połowę więcej kodu.
W JAVA nie da się też przeciążać operatorów, co w przypadku np. BigDecimals. Nie dość że jest bardzo nieintuicyjne, to jeszcze sprawia, że kod jest mniej przejrzysty i bardziej zagmatwany. Człowiek widząc "a > b" szybciej zorientuje się o co chodzi niż składnia wywołująca "compareTo", której szczerze jeszcze nie rozumiem...
Subskrybuj:
Posty (Atom)