W dniu 2023-05-21 o 23:19, heby pisze:
> On 21/05/2023 22:52, titanus wrote:
>> Stawiając te projekty obok siebie: Gdzie w przypadku programistów ARM
>> tkwił błąd ? Procki szybkie, wielordzeniowe, ze sporymi zasobami... a
>> tu coś co miało kilkaset MHz, jeden "rdzeń" i ledwie ...naście mega
>> pamięci...
>
> Byłem programistą na Amidze. Zarówno grzebiącym w hardware i piszącym
> "efekty" jak i używajacym wielu aspektów OSa. Powiedzmy, że wiem jak to
> działało w bardzo wielu płaszczyznach.
>
> Więc tutaj muszę Cie zmartwić: Amiga, z OS od wersji 2.0, miała
> obiektowy interfejs. BOOPSI. Używałem go, bawiłem się nim, pisałem w nim
> aplikacje. Był szybki, bardzo łatwy w użyciu i powstała masa
> upraszczaczy, w tym najsłynniejszy MUI, który był znakomity. nie miał
> się czego wstydzić względem podobnych rozwiązań na innych OSach.
>
> Prawdopodobnie przeciwnikom obiektowośc żyłka pęknie na samą myśl, że
> Amiga 500+ miała (częściowo) obiektowy system operacyjny.
>
> Doszukiwanie się problemów w samej obiektowości jest, w obliczu tego
> przykładu, naiwne.
>
Ależ mi nie chodzi o obiektowość, czy rodzaj interfejsu UI, czy nawet
nie chodzi o to w jakim języku go napisano...

Chodzi o to, że na tamten sprzęt "skrojono" programowo niemal wszystko
"na wymiar", a "embedowcy" potrafili wycisnąć z niego niemal siódme
poty. Jednym zdaniem: soft skrojony do hadware'u.

Teraz do oprogramowania - NIEZALEŻNIE JAKIEGO - dorzuca się rzeczy
zbędne, wrogie użytkownikowi a czasem tak bzdurne, że szkoda słów.
I nie myślę tu tylko o OS'ach, ROMACH czy aplikacjach. Dzisiaj kod jest
przeważnie śmietniskiem i wylęgarnią wszelkiego crapu.

>> Przypomniała mi się również tzw "scena" gdzie prawdziwi mistrzowie w
>> pliku o wielkości 64KB byli w stanie zmieścić obraz, dziwięk midi i
>> miało to czasem po 7 minut.
>
> No więc ja wiem jak to było, od kuchni.
>
> a) Efekty nie mogą mieć dużo kodu, bo nie miałby go kto wykonać w
> spodziewanym czasie. Kod był często generowany w czasie rzeczywistym z
> innego, włącznie z parametrycznym generowaniem danych wymaganych przez
> "efekt". To są pojedyncze kB.
> b) Muzyka MIDI jest bardzo skompresowana. W przypadku Amigi często
> wavetables (sample) były wytwarzane parametrycznie. Sama jakość układów
> dzwiękowych Amigi nie była aż tak super, aby te sample były też super.
> Przeciętny "moduł", czyli muzyka z dema, to kilkadziesiąt kB z samplami.
> To kwestia kreatywności muzyka.
> c) Jeśli przejrzysz jeszcze niższe demka 8-bit, zazwyczaj jest to
> powtarzanie tych samych efektów, często z tymi samymi danymi
> graficznymi, po wielokroć w pętlach. Dema rozbudowane, często ładują
> dodatkowe elementy z dysku, bo się nie mieszczą w 64k.
>
>> Tak - tęsknię za czasami, gdzie można było napisać surowy kod -
>> nieobarczony całym tym gwónoszitem UI i można było w kompilatorze
>> włączyć (lub nie) optymalizacje kodu i faktycznie robiło to "robotę".
>> Z pliku wynikowego np 200-300 kb robiło 80-120 kb - i był tam kod
>> pracujący naprawdę dobrze.
>
> Obecnie też pracuje dobrze.
>
Pozwolę się nie zgodzić: eskalacja kodu jest pomiędzy tamtymi a obecnymi
czasami już nie liniowa a logarytmiczna - i to nie w dobrym kierunku.

> Obecnie też możesz pisać wydajne apliakacje.
>
> Obecnie GUI jest zarąbisto szybkie, ale musi przerzucać 32 bitowy kolor
> z przezroczystością i rozmywaniem. I tak jest zarąbiście szybkie.
>
> To wszystko to tylko problem z jakością programisty, nie narzędzi.
>
No nie - to problem sprzętu nienadążającego za stale rosnącymi
zapotrzebowaniami oprogramowania.

> Typowy problem w GUI typu "zamrażanie, bo coś robię" to bezpośrednia
> konsekwencja niedzielnych programistów Drag'n'drop z Delphi. Oni nie
> potrafią pisać inaczej, niż logika biznesowa w onklikach. To się
> propaguje na współczesne języki, Delphi było tylko źródłem wszelkiego zła.
>
>> Teraz też chciałbym aby młodzi byli w stanie znaleźć i umieli używać
>> optymalizacji...
>
> Optymalizacja, szczególnie automatyczna, jest ostatnią rzeczą jaka jest
> ważna.
>
> Zdecydowanie więcej zysku uzyskując prawidłowo pisząc algorytmike, niż z
> optymalizacji na poziomie kompilatora. Ba, nieudolne próby optymalizacji
> kodu mogą zniweczyć efekt przyszłych refaktoringów.
>
>> I coś co każdy "widzi na codzień" - pierwszy windows: na kilku
>> dyskietkach, obecny: na kilkunastu DVD się nie zmieści...
>
> Zauważyłeś jak skomplikowane i rozbudowane jest obecnie API windowsa,
> względem powiedzmy wersji 95? Zauważyłes, jak wiele jest obecnie mediów
> zawartych w samym systemie? Zauważyłes, że ogólnie ilość wymaganych
> funkcji OSa wzrosła wielokrotnie, z reszą na życzenie userów?
>
Owszem, ale osobiście uważam, że ponad 60% kody obecnego windowsa
SPOKOJNIE można by z niego wyrzucić ujmując mu najwyżej 5%
"zajebistości". Kolejne 15% skierować na elementy niezwiązane z systemem
w postaci dołączanych plików, które użyte przez usera byłyby może raz
lub w ogóle. Reszt to aktywnie działający system.

Tak go widzę.

--
Pozdrawiam - titanus