Friday, September 9, 2016

PaxPlot – cd.

Zaś, po dłuższej chwili milczenia, postanowiłem zabrać głos. Praca nad programem do rysowania wykresów jest od maja wstrzymana z powodu natłoku różnych spraw. Co nie oznacza, że nie zostanie nigdy wydany. Generalnie to miała być zabawka i trening dla samego siebie, ale doszedłem do wspaniałomyślnego wniosku, że dlaczego by nie dodać parę usprawnień... no właśnie. "Parę", a projekt kitłasi się do dzisiaj. Pomijając zrzut ekranu pokazujący, co program mniej więcej oferuje na obecną chwilę (a dokładnie na 24 maja), podzielę się pewnymi spostrzeżeniami, które mogą mieć uniwersalny charakter mimo, że odniosę je do hobby (i prawdopodobnie przyszłego zawodu), w którym usilnie staram się być z dnia na dzień lepszy. Ale najpierw zrzut ekranu, bo użytkowników kupuje się dzisiaj (przeważnie) błyskotkami:



Przywołam główna ideę, którą kieruję się, robiąc ten program. Pierwotnie, miał rysować wykresy bardzo szybko. I dalej rysuje szybko, bo jest napisany w assemblerze (jeżeli czyta to jakiś programista, to pewnie uzna mnie za masochistę, poniekąd słusznie). Ponadto, rysowanie prostych funkcji (wielomianowe, trygonometryczne, wykładnicze, logarytmiczne) miało być możliwie szybkie i wygodne - uważam, że jest. To za cenę dokładności – program kreśli wykresy numerycznie, tak samo będzie z wyznaczaniem miejsc zerowych i ekstremów. Pakiety takie jak Maple, Mathematica czy Matlab chodzą pewnie równie szybko, ale są drogie i często skomplikowane, bo ciężko zrobić program matematyczny, żeby był prosty (co dla mnie na początku wcale nie było takie oczywiste). Komercyjne oprogramowanie, pisane przez profesjonalnych matematyków, wyznacza miejsca zerowe analitycznie (tam, gdzie to możliwe). PaxPlot podaje przybliżenia, ale jestem przekonany, że do prezentacji przebiegu będzie szybki, prosty, wygodny i przystępny. Piszę to wszystko po to, żeby dać podstawę do wysunięcia wniosków, do których doszedłem i które dopiero teraz tak na dobrą sprawę rozumiem.

Zaprojektowanie i wykonanie skomplikowanej rzeczy wymaga dobrej pracy zespołowej

W sumie żadna rewelacja. Można robić coś takiego samemu, ale fajnie wtedy być zarazem znakomitym projektantem, programistą, wizjonerem, specjalistą od wizerunku. A na końcu wczuć się w użytkownika. Można, ale oprócz pracy trzeba jeszcze żyć. Bardzo lubię to, co robię. Nigdy nie miałem rewelacyjnych ocen w szkole, bo robiłem na boku różne takie dziwne pierdoły. Nikt mnie chyba nie zje za to, ale pracy zespołowej w szkole nie uczą w ogóle. Nie będę wdawał się w analizę tego, dlaczego tak jest - nie jestem żadnym ekspertem, ale mam czelność twierdzić, że potrafię stawiać proste diagnozy. A miewałem frekwencję dobijającą do 100%, więc nikt mi nie zarzuci, że bezwzględnie olewałem szkołę. :)
Następnym wnioskiem jest to, że...

Perfekcjonizm można uznać dziś za wadę

Poprawianie czegoś w nieskończoność, niedawanie sobie pola do popełnienia błędu. Strzelanie do muchy z bazooki. Żyjemy w bardzo dynamicznej technologicznie rzeczywistości. Jesteśmy bombardowani masą informacji; musimy umieć sprawnie odróżniać rzeczy ważne od tych mniej istotnych (concise and to the point).

Dobra organizacja czasu jest kluczowa

Trudno o to bez popełnienia błędów tak, by móc wyciągnąć konstruktywne wnioski i zrozumieć, dlaczego poprzednie podejście nie zadziałało (doświadczenie). Żyjemy coraz szybciej, dlatego dobra organizacja czasu jest ważna, żeby nie popadać w skrajności (na czym sam się złapałem, nie jestem alfą i omegą); znaleźć harmonię między pracą i całą resztą (zbiorcze określenie pozostałych obowiązków i rzeczy mniej istotnych). Umiejętność dobrego planowania jest bezcenna.
I najważniejsze...

Nie szukaj aprobaty dla swoich działań u znajomych

Naprawdę zawsze coś komuś nie będzie się podobało. Uodpornij się na drwiny i wyrazy wszelkiej wątpliwości ze strony znajomych, a nawet najbliższych. Wcale nie muszą odciągać Cię dlatego, że uważają, że to co robisz nie ma większego sensu. Przekazujesz im swoją WIZJĘ a to czy oni zobaczą ją tak, jak Ty to widzisz, nie jest oczywiste.


KONIEC CZĘŚCI GŁÓWNEJ WPISU :)




Co to jest ten assembler?

Assembler to już nawet nie język programowania, to ostatnia "warstwa abstrakcyjna" między programistą a maszyną. Człowiek mówi systemowi rozkaz po rozkazie, co ma robić. Kiedyś to był jedyny sposób pisania programów, obarczony ogromną szansą na popełnianie błędów nawet przez bardzo doświadczonych twórców oprogramowania.

Dzisiaj dużych programów się w assemblerze nie pisze, bo jest to czasochłonne mimo wszelkich udogodnień na miarę XXI wieku. Dla unaocznienia, co to jest assembler, przejdź następujący proces. Piszesz program w C++, wybierasz opcję "kompiluj". Kompilator zamienia twój kod w C++ najpierw na assemblerowy, a potem assembler tłumaczy rozkazy na kod maszynowy. Inaczej, osoba pisząca dzisiaj w assemblerze robi robotę za kompilator.

Pisanie w assemblerze wiąże się ze ścisłym uzależnieniem tego, co piszemy, od architektury urządzenia, na jakim nasz program ma działać. W inny sposób napiszesz aplikację pod iPhone'a (ARM jeżeli się nie mylę?), w inny pod Linuksa, w inny pod Windowsa. Nie mieszam do tego kwestii czy piszesz pod system 32- lub 64-bitowy, bo wtedy zaczyna się totalna jazda. To dodatkowy argument, dzięki któremu assembler nie jest dzisiaj popularny. Teraz dąży się do tworzenia rozwiązań, które są platform-agnostic, to znaczy, piszesz jeden kod w zestandaryzowanym języku programowania i możesz go skompilować pod Windowsem, Linuksem, Mac OSX'em, na systemach osadzonych. Nie musisz wnikać w takie szczegóły jak to, czy parametry do funkcji są przekazywane przez rejestry czy przez stos, jaka jest konwencja wywoływania funkcji, czy funkcja czy wywołujący funkcję sprząta stos po wywołaniu... czy architektura w ogóle zakłada stos.

Postęp technologiczny uabstrakcyjnia sposób, w jaki tworzy się oprogramowanie a co za tym idzie - otaczającą nas rzeczywistość. Mimo wszystko, assembler jest używany do zadań specjalnych. Są sytuacje, w których rozmiar ma znaczenie. Wtedy człowiek może upleść bardzo wąski kawałek kodu na miarę własnych potrzeb mając tę przewagę nad kompilatorem, że potrafi myśleć i stosować nieszablonowe rozwiązania. Algorytmy do przetwarzania obrazu, dźwięku są czasami pisane w assemblerze, albo przynajmniej te części algorytmu, które wykonują lwią część obróbki danych.

Co można wynieść, pisząc programy w assemblerze?

  • Nieziemską cierpliwość i hartowanie w usilnym dążeniu do celu.
    Wściekasz się, jak kompilator C++ wywala Ci jeden błąd? Spróbuj napisać prosty program w assemblerze pokazujący okienko tak, aby się nie wysypał. Assembler puści płazem bezsensowne rozkazy. Program napisany w assemblerze zrobi absolutnie wszystko, co mu rozkażesz.

  • Głębsze rozumienie tego, jak działa oprogramowanie.
    Abstrakcja i uogólnianie mogą być pożądane ze względu na niemożliwie szybko rosnącą złożoność wszystkiego, ale posiadanie zbyt wielkich luk w pojmowaniu tego, co się robi, nie jest dobre.

  • Szacunek do pracy, techniki, języków wysokiego poziomu oraz pokorę.
    Ponadto, jeżeli masz ambicję do stworzenia programu, który będzie napisany w 100% przez Ciebie i uda Ci się takowy stworzyć, to satysfakcja na końcu jest nie do opisania.


Jakie są zasadnicze wady pisania w assemblerze?

  • Jest nieprzenośny ze względu na architekturę urządzeń.
    Trzeba pisać oddzielny kod dla 32-bitowych systemów, trochę inny dla 64-bitowych, zazwyczaj kompletnie inny dla urządzeń mobilnych. Dla małych rzeczy może i fajne, ale dla większych - szkoda życia.

  • Rozmiar kodów źródłowych puchnie wraz ze wzrostem funkcjonalności.
    Pisanie bardziej rozbudowanych programów (nie mówiąc o dużych) jest trudne, bo trzeba redefiniować każdą elementarną operację i makra tutaj za bardzo nie pomagają. Przykład? Jak PaxPlot zbliżył się do 11000 (jedenastu tysięcy) linii, musiałem podjąć decyzję, aby go rozbić i pogrupować funkcje, bo, w szczególności po długiej przerwie, ogarnięcie własnego programu bez schematów stanowiło nie lada wyzwanie. Poniżej zrzut ekranu pokazujący, jak kod źródłowy rośnie w czasie, a wcale nie robi kosmicznych rzeczy.



  • Tworzenie programu assemblerowego naprawdę trwa. PaxPlot to pod względem "architektonicznym" jak na razie najbardziej skomplikowany twór, jaki udało mi się upleść. Dla porównania, patch dla Windows 7 x64 (SuppressDwm64) ma prawie 7000 linii, mój pierwszy bardziej rozbudowany program Drive Policies Management Toolkit – blisko 5000. A to nie są duże programy.

Dlaczego więc PaxPlot jest rozwijany w assemblerze?

Miał stanowić zabawkę, trening dla samego siebie. W pewnym momencie prace poszły na tyle daleko, że uznałem przejście np. do C++ za bezsensowne wobec ilości pracy, jaką włożyłem. Końcowy rezultat to suma założeń i tych rzeczy, które wyszły "w praniu". Nie przewidziałem, że program tak "urośnie". To prawdopodobnie ostatni program, który tworzę w taki sposób.

No comments:

Post a Comment