On 2013-10-11 17:31, Sylwester Łazar wrote:
> To jest zły przykład. Ja nie hoduje sobie kryształka kwarcu, a potem z niego
> robię procka.
> Zapytam tak:
> Czy kupujesz gotowy projekt domu z muratora za 1000zł,
> czy projektujesz sobie dom w taki sposób jakim chciałbyś go mieć?
> S.
>

Może zostawmy analogie budowlane na boku - to nie był zbyt szczęśliwy
pomysł.

Generalnie to jest tak, że przy programach (systemach) nieco bardziej
skomplikowanych niż "Hello world" wybudowanie wszystkiego od początku
nie ma ani sensu ekonomicznego, ani (najczęściej) nie spełnia kryteriów
jakościowych. Przy czym przez kryteria jakościowe rozumiem również
dotrzymanie terminów.

Dlatego między innymi wymyślono takie "wynalazki" jak biblioteki,
komponenty, frameworki i inne cuda wianki.

Piotrek

do góry

> Jak myślisz dlaczego w Androidzie użyto kernel Linuxa? Najprostszy
> przykład jaki mi przyszedł do głowy.
>
> --
> Marek
To akurat proste.
Główny projektant nie miał swoich własnych bibliotek do obsługi
4''wyświetlacza LCD,
rezystancyjnego panelu dotykowego, Wi-Fi, USB i karty SD.
Uznał, że skoro tak, to potrzebuje systemu operacyjnego, bo tam ma już
uruchomione wszystkie biblioteki razem, które jakoś działają.
Tutaj miał do wyboru:
Windows ze swoimi bibliotekami - razem ze 300MB
Linux, gdzieś ze 30MB
Jego syn, będący w 1 klasie podstawówki, słusznie zauważył:
"Tato bierz ten Linux! Tylko głupiec pakowałby się w system 10x większy i
bardziej zawodny."
No i dorzucił trochę koloru do Linuxa i zmieścił się w procku.
Teraz po naciśnięciu książki telefonicznej czeka tylko 100ms i już ma 10
pierwszych numerów z bazy danych na ekranie.
A mógł mieć to wszystko w ASM przy 1MB i czasie reakcji na wyjątek 1ms
:-)
S.

do góry

On 2013-10-11 17:43, Sylwester Łazar wrote:
> A mógł mieć to wszystko w ASM przy 1MB i czasie reakcji na wyjątek 1ms

Chyba nie doceniasz znaczenia testowania. Zwłaszcza przy deploymencie na
miliony (różnych) urządzeń ...

Piotrek

do góry

> Dlatego między innymi wymyślono takie "wynalazki" jak biblioteki,
> komponenty, frameworki i inne cuda wianki.
>
> Piotrek
Zauważ, że te biblioteki możesz mieć swoje lub obce, a nawet swojo-obce,
czyli kolegi, z którym jeszcze się nie pokłóciłeś.

Jeżeli ja mam bazę swoich projektów/bibliotek, do których interfejsy mam
znane,
potrzebuję tyle samo lub mniej czasu, niż ktoś kto wchodzi do zasobów
globalnych,
szuka biblioteki, wgłebia się w interfejs, includuje a na koniec
uruchamia....

Jeżeli jednak ktoś, kto pisał 10 lat w C i 3 razy w asm,
pragnąłby napisać kod na 32-bitowy uC w ASM - nie da rady.
Polegnie na opisie sprzętowego 8xPWM.

Jeden lubi Hi-level z milionami kolegów, a inny Extream z małą ekipą.
Nic nie poradzisz. Dopóki nie musisz...
S.

do góry

> > A mógł mieć to wszystko w ASM przy 1MB i czasie reakcji na wyjątek 1ms
>
> Chyba nie doceniasz znaczenia testowania. Zwłaszcza przy deploymencie na
> miliony (różnych) urządzeń ...
>
> Piotrek
Może.
Skomentuj proszę te 100ms.
S.

do góry

On 2013-10-11 11:59, Sylwester Łazar wrote:
> Nawyk dokumentowania kodu mam już od 15 roku życia.

Ja od 12-go, mając w ręku ZX Spectrum - Z80, przez 6502, 8051, 680x0,
8086, arm, mips. Znam(łem) assemblery wszystkich i we wszystkich
pisałem. I obecnie programuje ogromna aplikację w C++ na duzym systemie
i w wolnych chwilach roluje bity na GPIO AVRka. Skażenie asm nie
przeszkodziło mi znajdywać zalety zarówno programowania
wysokopoziomowego jak i asm, dosuje obie techniki, wliczając to takie
ciekawoski jak programowanie deklaratywne czy constrains a nawet
ostatnio kawalek w prawie-prologu się trafił (na uC :). Używam wielu
narzedzi, a nie tylko młotka asm, bo problemy mam różne więc i narzędzia
też.

> Jednak wyrobienie sobie takiego nawyku przez kilkanaście lat pracy,
> powoduje, że teraz to idzie szybko.

Mam znajomego ktory niezwykle szybko kopie doły łopatą. Do tego stopnia
ze konkuruje z minikoparkami. Czy jesteś pewny że kopanie łopatą ma
jednak przyszłość? Bo ja tak, sprawdza mi się w ogródku.

> Wiadomym jest, że jak stukasz w klawiaturę wpisując ~destruktory w C++,
> czy inne konstrukcje, nie dodając żadnych komentarzy zawsze będzie to
> szybsze,
> niż rysowanie algorytmu, dokładanie opisu słownego po polsku czy angielsku,
> kopiowanie tekstu, czy tworzenie historii zmian.

Szybsze będzie tworzenie unit testów, abstrakcji oraz czytelnego kodu
które pozwolą w pełni przetestować kod zamiast pisania komentarzy które
po miesiącu nie mają nic wspólnego z rzeczywistością bo nie istnieje
żadnej przymus aby były synchronicznie zmieniane z kodem. W "zespole"
jednoosobowym bywają z tym problemy. Wobraź sobie jak to wygląda w
zespole N>1.

> a) przyjemność zabrania się za analizę kodu przedstawionego na kolorowym
> algorytmie,

Ja mam przyjemnośc nie analizowania kodu tylko stwierdzenia jakie
warunki brzegowe ma realizować widząc testy. Implementacja ma tylko tyle
na znaczeniu że musi mieć założoną złożoność bądź restryckje czasowe.

> b) poprawianie, czy adaptacja kodu nie zabiera już tyle czasu, a wręcz
> przyspiesza.

Refaktoring kodu przyspiesza kiedy masz testy.

> c) uruchamianie jest już formalnością i czasem jest tak, że rysujesz/piszesz
> program 3 dni,
> a samo uruchamianie z oscyloskopem czy analizatorem stanów - kilka godzin.

Patrz, zupełnie jak przetestowany kod in virto.

> Gdy znajdziemy błąd, często pada od razu po spojrzeniu w dokumentację
> zdania:
> " No tak... śmieszny błąd"

Albo jak padnie unit test to patrzymy w kod i naprawiamy.

> Dzieje się tak, gdyż poświęcając dużo czasu na przygotowanie kodu, zanim
> zacznie się pisać słowa w dowolnym języku programowania, już wcześniej
> korygujemy wiele błędów natury logicznej, składni, nazwy, czy zwykłych
> pomyłek.

Dzieie się tak gdy przygotujesz sobie test suide na długo przed
napisaniem pierwszego słowa kluczowego algorytmu.

> Po wpisaniu kodu - jest on już niemal pewny.

Ba, przetestowany kod jest nie tylko pewny, ale i *przetestowany*.

> Zmiany zwyczajowo dokonują się poprzez poprawę kilkunastu znaków w kodzie.
> A w większości pewnie w komentarzach i historii zmian.

Która to historia znajduje się w systemie kontroli wersji który bez
watpienia używasz.

> Samo wpisanie daty 2013103 to już 7 znaków :-)

Tym bardziej że zbędne.

> Odpowiadając na Twoje zapytanie - tak kod jest zawsze rozwojowy.
> I tak miało być w założeniu.

Nie wątpie że łopata można kopać dziury różnych kształtów.

> W związku z tym czasem podrzucam żonie mój algorytm sprzed nastu lat na
> 8051,
> a żona przerabia go na PIC32 zmieniając (bardzo optymalnie zresztą) kod.

Zupełnie jak kompilator pawie każdego języka.

> Uczę tej pracy też dzieci, więc już trójka z mojej całej piątki opanowała
> rysowanie algorytmów,
> choć są dopiero na poziomie <liceum.

3 łopaty kopią szybciej niż jedna :P

Odkryłeś kwadratowe koło i je pielęgnujesz piłując pieczołowicie rogi aż
wyjdzie romb. Bez wątpienia warsztat masz znakomity, znajomość asm w
jednym palcu, ale czy na pewno widziałeś jak wygląda warsztat
przeciętnego programisty poza twoim domem? Wiesz ile i jakich narzędzi
używa, jak pracuje w zespole bądź samotnie, ile twoich problemów
rozwiązano w latach 70-tych i gdzie obecnie znajdują się jezyki
programowania? Programiści embedded to czesto skansen osobliwości i
rozwiązań poroblemów które albo nie istnieją albo zostały rozwiązane
dziesięciolecia temu. Nie dalej jak miesiac temu trafilem na mistrza
ktory programuje 8051 w edytorze hex pod dosem znając na pamięc kod
*maszynowy*. Nie dalej jak wczoraj musiałem zmagaś się z
systemverilogiem w którym ktoś intensywnie wymyśla nowe "lepsze"
programowanie obiektowe ignorując to co wiemy od smalltalka.

Nie zrozum mnie źle: szanuje Twoją pracę i wiedzę. Ale proszę, dla dobra
ludzkosci, nie przedstawiaja jej jako wzorca dla kogokolwiek. Jesli Ci
pasuje to ok, jesli sprawia radość to tym lepiej.

Koniecznie obejrzyj to:

http://vimeo.com/71278954

Od 4:00 jest pouczający kawałek na temat "assembler jest najfajniejszy
do wszystkiego".

Tak, ten film to rodzaj żartu, ale czy nie ciekawy? Polecam dla
wszystkich aby to obejrzeć do końca.

do góry

On 2013-10-11 16:35, Sylwester Łazar wrote:
>> Co do objętości kodu to się zgodzę, że w C jest większy, ale bez
>> przesady - nie 5kB->10MB! Jeśli w bibliotece są niewykorzystane funkcje
>> to linker może je po prostu wyciąć z automatu.
> Czasem jedna błędna deklaracja typu w C powoduje, że brakuje Ci pamięci.
> No może to skrajny przykład,
> ale 5kB w ASM i 50kb w C to chyba się zgodzisz?

Bzdura. Kod wynikowy zajmuje tyle ile powinien, nawet w skrajnie
popsutych współczesnych kompilatorach jest ciągle nieźle a nie 10x
gorzej bez powodu.

do góry

On 2013-10-11 17:43, Sylwester Łazar wrote:
> No i dorzucił trochę koloru do Linuxa i zmieścił się w procku.
> Teraz po naciśnięciu książki telefonicznej czeka tylko 100ms i już ma 10
> pierwszych numerów z bazy danych na ekranie.
> A mógł mieć to wszystko w ASM przy 1MB i czasie reakcji na wyjątek 1ms

Po 10 latach pisania kodu. Taki system operacyjny i GUI w asm nie
istnieje *nigdzie* jako działający poważnie produkt. Nie dlatego że się
nie da tylko dlatego że nie ma to żadnego sensu.

do góry

On 2013-10-11 17:55, Sylwester Łazar wrote:
> Może.
> Skomentuj proszę te 100ms.

A co tu komentować?

W podanym przez Ciebie przykładzie kompletnie nie ma sensu ściganie się,
w celu przyspieszenia wyświetlania książki telefonicznej w ciągu 1ms.

Główne z tego powodu, że i tak userowi zajmie pewnie dobrą sekundę
poskrobanie się po głowie w celu ustalenia czy to o tego "Ziutka" z
książki telefonicznej mu chodziło, czy o jakiegoś innego.

Piotrek

do góry

On 2013-10-11 17:51, Sylwester Łazar wrote:
> Zauważ, że te biblioteki możesz mieć swoje lub obce, a nawet swojo-obce,
> czyli kolegi, z którym jeszcze się nie pokłóciłeś.
>
> Jeżeli ja mam bazę swoich projektów/bibliotek, do których interfejsy mam
> znane,

Acha. Czyli jednak zaczynasz od "szukania gotowych programów/bibliotek".
Zanotowałem ;-)

> potrzebuję tyle samo lub mniej czasu, niż ktoś kto wchodzi do zasobów
> globalnych,
> szuka biblioteki, wgłebia się w interfejs, includuje a na koniec
> uruchamia....

Problem zaczyna się w momencie, kiedy zaczynasz się poruszać poza swoją
niszą.

A przecież sprawny projektant powinien sobie poradzić z zaprojektowaniem
"czegobądź".

Dobierając co najwyżej ekspertów dziedzinowych, którzy doradzą mu jakich
komponentów użyć. :-)

>
> Jeżeli jednak ktoś, kto pisał 10 lat w C i 3 razy w asm,
> pragnąłby napisać kod na 32-bitowy uC w ASM - nie da rady.
> Polegnie na opisie sprzętowego 8xPWM.

No dokładnie o to chodzi. Dlatego IMHO - jeśli już masz spełnić jakieś
szczególne wymagania - lepiej użyć gotowych i sprawdzonych narzędzi, niż
rzeźbić samemu.

>[...]

Piotrek

do góry