W dniu 21.05.2023 o 22:52, titanus pisze:
> W dniu 2023-05-21 o 20:52, heby pisze:
>> On 21/05/2023 20:28, Marek wrote:
> [cut]
>
>>
>> Wyjaśnij proszę, jakie jest powiązanie między używaniem nowoczesnego
>> języka programowania z powolnym UI. Na przykładzie jakiegoś
>> konkretnego rozwiązania. Gdzie znajdują się powody nieresposywnego
>> działania z powodu jakiejś cechy języków lepszych niż C.
>>
>> Pamiętaj, że *prawie* wszystkie, a na pewno wszystkie współcześnie
>> używane bibliteki UI są *całkowicie* obiektowe. Jesli chcesz zobaczyć
>> jak responsywny jest np. Qt, proponuje zerknąc do exampli. Wyrywa z
>> kapci.
>>
>> Natomiast wszystkio można spierniczyć.
>>
> Może wtrącę od siebie 3 grosze:
>
> Parę lat temu używałem... przepraszam... próbowałem używać na smartfonie
> interfejsów typu 3D: jakiś pseudo pokój ze ścianami, szufladami itp.
> Było to o tyle ciekawe, że pisane było w Javie, C++ i bóg wie czym jeszcze.
>
> Pierwsze projekty były oczywiście toporne i oferowały ograniczone
> interakcje, potem przyszły takie które - można powiedzieć - nadążały za
> użytkownikiem kosztem ograniczenia funkcjonalności samego shella.
>
> Obecnie to już totalna nisza, bo nikt przy zdrowych zmysłach widząc jak
> w szybkim postępie liniowym bateria urządzenia jest drenowana przez taką
> "nakładkę" po prostu tego nie używa.

Z powodu baterii, jak można używać urządzenie na zasilani bateryjnym???

>
> Z drugiej strony widziałem również kilkanaście lat temu demo projektu
> ShellCube na Amigę 500/1200 gdzie respons widoczny przynajmniej na tym
> filmie był nie większy niż kilkadziesiąt milisekund. I to mi się spodobało.

Czemu już nie produkują Amigi?

>
> 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...
>
> 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 to powinno pójść na większych. Czy nie.

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

No przecież o tym właśnie mowa, hebe, zasadniczo słusznie, twierdzi że
można to zrobić za pomocą C++ zamiast assemblera i C bez straty tej
optymalizacji a z potężnym zyskiem w postaci jasności kodu.

>
>
> Teraz też chciałbym aby młodzi byli w stanie znaleźć i umieli używać
> optymalizacji...
>
> vel ostatni wypust samsunga S23 Ultra i jego ROM o wilekości - o ile
> dobrze pamiętam  - 62,3 GB ??????

No i czemu nie ma urządzeń z mniejszym?

>
> Puściłem ostatnio kompilację z PiC C Compiler na PICa 32MZ, jakieś 80 KB
> kodu, a kompilator z MPLAB zrobił z tego blisko 323 KB bo
> zadeklarowałem, że będę używał 17 bibliotek wbudowanych.
>
> Nie ma UI, jest tylko wewnętrzna prosta obsługa bieżąca.

Bibliotekom Arduino nie pomaga nawet to, że są pisane w C :-)

>
> I coś co każdy "widzi na codzień" - pierwszy windows: na kilku
> dyskietkach, obecny: na kilkunastu DVD się nie zmieści...
>
> Pierwszy robił co miał robić - obecny... właściwie nie wiadomo co robi...

Windows IoT mieścił się na 2GB to chyba nie tak źle na system, który już
jakoś sam działa.

>
>
> [cut]
> ... ot, taka dygresja.
>

Dobra, ale czemu w takim razie nie używasz tych prostych rozwiązań.