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.

> 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.

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.

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?