On 23/05/2023 17:26, titanus wrote:
>> 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...

Mimo to Amiga OS jest obiektowy, przynajmniej częściowo. I to, co
najzabawniejsze, w ogóle nie zależnie od języka programowania. W asm też
się dało pisać z BOOPSI obiektowe aplikacje. W tym momencie embedowcom
trzeba chyba podawać tlen.

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

Amiga OS jest już na granicy OSa uniwersalnego, gdzie abstrakcja na
hardware jest prawie kompletna.

Z każdą nastepna wersją stawał się coraz mniej skrojony na miarę a coraz
bardziej uniwersalne. Amiga bez problemu obsługiwała tym samym OSem inne
karty gfx, dzwiękowe, dodatki typu MMU itd itp. Nie, ten system nie był
skrojony na miarę, był na granicy takiego.

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

Dobrze wiedzieć.

I dobrze też przeciwdziałać. Zamiast produkować tony krapu w C można
najzwyczajniej napisać przejrzysty kod w wyższym poziomie abstrakcji.
Czy to będzie C++ czy Rust, to drugorzędne.

Krap można pisać wszędzie. Są jezyki w których robi się to trudniej.
Obecny zwrot z C(++) do Rust świadczy o tym, że w głowach wielu ludzi
zaczeło kiełkować, że jednak uniwersalny asembler to niekoniecznie
najlepsze narzędzie do pisania aplikacji z tysiącami kloc.

Prawdopodobnie wynika to z odchodzenia starych ideologów C na emeryturę.
Bo z własnej woli Rust'a by nie tknęli kijem.

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

Wyjaśnij przyczynę.

Mogę migać diodą w C++ w takiej samej ilości instrukcji asm kodu
wynikowego co w C. Nic tu nie rośnie.

Co rośnie i dlaczego?

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

Sprzęt, w szczególności układy specjalizowane grafiki, są obecnie
wielokrotnie szybsze niż przeciętnej karty Trident czy amigowego
Blittera. Biorąc w poprawkę cały postęp w rozdzielczości i głebokości
kolorów.

Hardware jest super szybkie.

A natywne bibliteki, jak Qt, korzystają z tego całymi garściami.

Sugeruje odpalić demka z Qt, płynnośc i responsywnośc wgniata w podłogę.

Oczywiście do pierwszego imbecyla robiącego "for (;;)" w onkliku. Tutaj
szukaj przyczyny. Nie ilość danych, nie język, a najzwyczajniej
niepojmowanie jak się pisze aplikacje responsywne, powoduje wrażenie
spowolnienia.