On 21/05/2023 20:28, Marek wrote:
>> Efektem czego dzisiaj możesz pisać o wiele większe aplikacje, w
>> bardziej bezpieczny i wydajny sposób.
> Aż poplułem ekran. Jasne. Szczególnie to widać wokół we wszystkim co
> otacza współczesnego człowieka. Telefony, telewizory, aplikacje w sieci
> jakie to bezpieczne a szczególnie wydajne, paradygmat "proszę czekać
> ładuje się". Wieszajace się i nie responsywne UI, nieprzewidywalne w
> zachowaniu aplikacje.

Możesz wyjasnić nam jaki widzisz związek pisania nieresponsywnych
apliakcji z wyborem języka programowania?

Może jneczej: czy znasz jakiekolwiek współczesne metody podwyżaszania
responsywności aplikacji, stosowane w UI?

Po prostu pokaż to powiązanie: "cośtam z języka jest odpowiedzialne za
cośtam w wydajności". Chętnie posłucham.

> No jakie to programowanie w  C++ (i innym obiektowym badziewiu) daje
> rezultaty, super. Efekty zajebiste. Chyba tylko finansowe korporacji i
> programistów.

Zgaduje że nigdy nie pracowałeś w dużym projekcie programistycznym. Ja
tak. Te apliakcje, z którymi pracowałem i pracuje, są niemożliwe do
utrzymania bez współczesnych zdobyczy z dziedzini inzynierii
oprogramowania. Która to, najczęsciej, opiera się o coś
nowocześniejszego niż assembler czy C. Tam jest dużo obiektowości,
funkcyjnosci, abstrakcji. Zdecydowana większośc technik
programistycznych zapewniajacych bezpieczeństwo, jakość itd nie da się
zastosować w językach asembleropodobnych, lub wymaga stawania na głowie.
Ludzie to wiedzą i dlatego, ideologicznie, nie stosują guano o nazwie C.
Stosują narzędzie adekwatne do problemu, potrzeby skalowania, wymaganej
jakości. To nie musi być C++. Ale zdecydowanie to nie będzie C ani asembler.

Praowdopodobnie masz ten sam problem, co większośc konserwatystów
programowania: winisz to, czego nie pojmujesz, za jakosć oprogramowania.

Nic nowego, znam wielu ludzi któzy mają taki konserwatyzm we krwi.
Zazwyczaj nie są w stanie okreslić dlaczego nak używają, na poziomie
wiedzy, ale idologicznie to wiadomo: wszystkiemu winne wszystko czego
nie rozumieją.

> Używałeś kiedyś UI Google ADS?

Nie.

> Tego k..wa  nie daje się używać. Każdy
> klik to 5-8 sekund czekania by interfejs zaregowal.

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

> I Google tego od 10
> lat nie  jest w stanie ogarnąć żeby to było używalne. GOOGLE najlepsi
> na świecie specjaliści. To jest przyszłość?

Jeśli okreslisz co jest tego powodem, to możemy wyjaśnić sobie gdzie
leży problem.

Na razie wiążesz niepowiązane rzeczy ze sobą starając się udowodnić
jakąs bzdurną tezę.

> Zajebiste wydajne te języki
> obiektowe. Super.

Nie masz najzwyczajniej pojęcia o tym, co jest przyczyną tych problemów.

Podpowiem Ci: debilizm programisty.

On jest mocno niezależny do wybranego języka programowania. Zazwyczaj on
jest powodem. Czasami też debilizm użytkownika.

> I uważasz, że wszystko jest w porządku bo da się  wydajnie i bezpiecznie
> zamigac LED w C++... Jprdl...

Najwidoczniej Twój świat skłąda się głownie z aplikacji tego typu, skoro
jak do tej pory nie pojmujesz czym jest nowoczesna inzynieria
[o]programowania.

C++ nie zmienia NIJAK wydajnosci aplikacji. Ani o milimetr. Nawet użycie
miliona klas nic nie zmienia. Szukasz problemu w zupełnie złym miejscu.

Jeśli twierdzisz, że jest inaczej, najwyczajniej wyjasnij na konkretnym
przykładnie, zamiast pierdolić od rzeczy jak to lokomotywy powodują żwe
krowy mleka nie dają.

PS. Jak jeszcze w PL był Praktiker, to mieli system rozliczania faktur,
jakiejś polskiej firmy, napisanyw DOSie. System ten *liniowo*
przeszukiwał bazę danych, czym z resztą się chwalił wyświetlając
wszystkie rekordy na ekranie od A do szukanego, "szybko", czyli w ciągu
minut, znajdujac szukanego delikwenta. To, czy byłby napisany w C, C++,
Fortranie czy asemblerze nie pomogło by na debilizm programisty. Ani trochę.

do góry

On Sun, 21 May 2023 20:52:14 +0200, heby <h...@p...onet.pl> wrote:
> Na razie wiążesz niepowiązane rzeczy ze sobą starając się udowodnić
> jakąs bzdurną tezę.

Jaka tezę? Niczego nie udowadniam tylko stwierdzam fakty.
Jak zwykle nie pojmujesz w czym rzecz. Globalnie świat
oprogramowania (produktów, efektów) jest zjebany. Ja nie wnikam czy z
powodu, że 99% programistów to idioci czy języki obiektowe do
niczego się nie nadają. To nie ma znaczenia. Ja oceniam CAŁOŚĆ. A ta
jest zjebana. Czynnik zjednania jest nieistotny.
Więc proszę przestań chrzanić głodne kawałki o selektywności gdzie
leży problem i czemu on nie jest w C++. Mam to gdzieś gdzie jest, bo
ocena całościowa jest taka jaka jest. Skoro programiści są be a
języki cacy to może dostosujemy języki do możliwości programistów
jacy są, co?

--
Marek

do góry

On 21/05/2023 21:26, Marek wrote:
>> Na razie wiążesz niepowiązane rzeczy ze sobą starając się udowodnić
>> jakąs bzdurną tezę.
> Jaka tezę? Niczego nie udowadniam tylko stwierdzam fakty.

Te fakty to schizofreniczne łaczenie kropek na osobnych kartkach.

> Jak zwykle  nie pojmujesz w czym rzecz.

Pojmuję. Dlatego że pracowałem od ~20 lat nad oprogramowaniem, w którym
responsywnośc i szybkosc były *krytyczne*, włącznie z Twoim ukochanym
UI. I programowanie nowoczesne (funkcyjne, obiektowe, szablonowe,
abstrakcyjne) było niezbędnym elementam uzyskania tego efektu.

Wiem więcej o programowaniu responsywnego UI niż może Ci się wydawać. I
wiem, że to nieosiągalne w C bez absultnie iditycznego poziomu szamba
jaki by wygenerowało. Ilość skomplikowanych rozwiązań jest
przytłaczająca jak na jezyk do pisania dupereli.

> Globalnie świat oprogramowania
> (produktów, efektów) jest zjebany.

Podpowiem: jest dużo kiepskich programistów. Wina języków typu C++ jest
tu niewielka. Dużo większa wina języków klikalnych, kieposkiego
kształcenia i wsysania na stanowiska programistów byle kogo z ulicy.

Byłem w procesie rekrutacyjnym jako kandydat i jako manager teamu.
Jestem "rekrutowany" prawie codziennie (absolutnie nie przesadzam).
Byłem częscią procesu edukacji ludzi z dyplomami informatyków. Można
powiedzieć, że widziałem wszystko, z każdej możliwej strony.

Ludzie, przyjmowani na stanowiska programistów, są kiepscy. W dużej
większości. I nie chodzi tu o znajomośc wyszukanych algorytmów. O
zwyczajną intuicję, talent i umiejętności poza edukacyjne.

Wiesz ilu, w ostatnich 5 latach, widziałem ludzi po studiach,
kandydujacych na stanowisko programisty, mających hobby z choć z okolicy
informatyki? Zero.

Tu szukaj przyczyny, dla której niektóre aplikacje są napisane źle. Ba,
przytłaczająca większość.

> Ja nie wnikam czy z powodu, że  99%
> programistów to idioci czy języki obiektowe do niczego się nie nadają.

Wnikasz. Poprzednie wypociny to było narzekanie na to, że UI jest
nieresponsywne bo obiektowe.

Już się wycofujesz w panice?

> To nie ma znaczenia.

Ma.

Idiotą można być w dowolnym jezyku.

Natomiast Ty pondniosłeś konkretną, nieistniejącą korelację. Tak
naprawdę jesteś tylko następnym konserwatystą który usilnie stara się
zrzucić problem na rzeczy, których nie pojmujesz.

Wina Tus^M^M^Mobiektowości.

> Ja oceniam CAŁOŚĆ. A ta jest zjebana. Czynnik
> zjednania jest nieistotny.

Przed chwią wyjasniłeś czym jest ten czynnik, że to "obiektowe
badziewie". Nawet ekran poplułeś. Czyli jednak ucieksza w panice od
własnej argumentacji?

Co ma wspólnego obiektowe pisanie z kipeskim kodem. Nie wyjaśniłeś, ale
pewnośc już masz.

> Skoro programiści są be a języki cacy to
> może dostosujemy języki do możliwości programistów jacy są, co?

Dostosowujemy. Dlatego embedded trzyma się C. Miganie diodą czasami jest
krytyczne istotne, a wiadomo, że ludzie w embedded to nie idioci i nigdy
błedów nie popełniają. W końcu ta dioda to może być silnik respiratora.
Trzeba się skupić i pisać porządny kod, od razu, bez błedów i najlepiej
na produkcji.

Natomiast reszta ludzi, świadomych swoich ograniczeń, spodziewa się
języków bezpiecznych, utrudniajacych popełnienie błędu. Język C++
bezpieczny nie jest, ale jest *bezpiczeniejszy* od C. I za darmo. Jeśli
ktoś nie bierze tego darmowego obiadu, bo ma kretyński konserwatyzm we
krwi, to nic nie poradzę. Musi nastapić zmiana pokoleniowa i
uszczelnianie szamba po obecnym pokoleniu programatorów C. Tak jest od
ponad 20 lat z miejsca, gdzie widzę to na żywo. I jeszcze długo będę
widział, bo skumbrii w tomacie wśród programistów nie brakuje, wbrew
obiegowej opinii to nie tylko ludzie otwarci na nowości.

do góry

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

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.

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.


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

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.

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


[cut]
... ot, taka dygresja.

--
Pozdrawiam - titanus

do góry

W dniu 21.05.2023 o 20:52, heby pisze:
> Może jneczej: czy znasz jakiekolwiek współczesne metody podwyżaszania
> responsywności aplikacji, stosowane w UI?

Coraz gorętsza dyskusja, to pozwolę sobie trochę obok tematu, ale o tej
responsywności.

Jak można zbudować system, który tak kiepsko działa, nikt tego nie
testuje przed odbiorem? A mam na myśli np. biletomaty Apcoa.
To, że przycisk wandaloodporny pojemnościowy działa po dotknięciu za 4-5
razem, to pominę, może jest uszkodzony.
Ale od momentu naciśnięcia do pojawienia się jakiejkolwiek reakcji na
wyświetlaczu mija kilka sekund, po których pojawia się info o druku
biletu i następne kilka sekund na reakcję drukarki.

Albo wpłatomat. Komunikat, że brak papieru, czy chcesz kontynuować.
Tak chcę, po zakończonej wpłacie komunikat... weź potwierdzenie, które
jest dowodem... ale przecież nie ma papieru.

To nie są jakieś darmowe apki z Google Play, tylko systemy za grubą kasę.

Robert

do góry

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?

do góry

On 21/05/2023 22:57, Robert Wańkowski wrote:
> Jak można zbudować system, który tak kiepsko działa, nikt tego nie
> testuje przed odbiorem?

make.

I do klientów.

Znam firmę, która to robi na codzień. Kiedyś gadałem z jednym z
programistów. Zapytałem jak testują. Zostałem nazwany idiotą. Oni piszą
tak, że nie trzeba. Dobrze, znaczy. Koleś ma tak pod 60kę. O unit
testach, testach integracyjnych itd słyszał, ale to tylko nowoczesne
gówno. Oni tego nie potrzebują. Jak coś się spieprzy, to się naprawi i tyle.

> Ale od momentu naciśnięcia do pojawienia się jakiejkolwiek reakcji na
> wyświetlaczu mija kilka sekund, po których pojawia się info o druku
> biletu i następne kilka sekund na reakcję drukarki.

Kamyczek w ogródek embedded

Mam zmywarkę hotpoint. Wciśnięcie "power on" powoduje 4sek pauzę, po
której zmywarka wstaje i ożywa.

W czasie tych 4 sekund, przeciętny user, w tym ja, w pierwszym
zderzeniem z tą zmywarką, wciśnie ten przycisk 6 razy.

To jest przykład, że imbecyl-programista to również rzecz spotykana w
embedded.

Wcześniejsza wersja miała reakcję natychmiastową. Bo przycisk był
mechaniczny.

> To nie są jakieś darmowe apki z Google Play, tylko systemy za grubą kasę.

Odpowiedź brzmi: te system nie są odbierane przez wolny rynek. One są
odbierane przez urzędniczych pustaków, którym wystarczy wyjaśnić, że
"komputer myśli". Ale za to są kolorowe ikonki. Widziałem kiedyś taki
odbiór na żywo. Straciłem spory kawałek mózgu starając się logicznie
ogarnąc argumentację producenta. To bez znaczenia z resztą, system
został wdrożony i przez wiele lat przyczynił się do depresji i ataków
zaniku logiki wielu petentów pewnego urzędu.

do góry

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

do góry

W dniu 21.05.2023 o 23:19, heby pisze:
> On 21/05/2023 22:52, titanus wrote:
...
>
> 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.

Czytnik grup Mozilli też mi się jakoś zamraża. Pewnie niedzielni
programiści Delphi :-)

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

Nie bardzo. A właściwie to wcale. Użytkownicy w ogóle nie oczekują
funkcji systemu operacyjnego. Funkcjonalność postrzegają jako cechę
programów. Programistycznie też nie widzę by jakoś bardzo się ten system
operacyjny rozwinął. Wręcz się programistycznie uprościł ze względu na
obiektowe API dotnetów.

do góry

W dniu 21.05.2023 o 22:57, Robert Wańkowski pisze:
> W dniu 21.05.2023 o 20:52, heby pisze:
>> Może jneczej: czy znasz jakiekolwiek współczesne metody podwyżaszania
>> responsywności aplikacji, stosowane w UI?
>
> Coraz gorętsza dyskusja, to pozwolę sobie trochę obok tematu, ale o tej
> responsywności.
>
> Jak można zbudować system, który tak kiepsko działa, nikt tego nie
> testuje przed odbiorem? A mam na myśli np. biletomaty Apcoa.
> To, że przycisk wandaloodporny pojemnościowy działa po dotknięciu za 4-5
> razem, to pominę, może jest uszkodzony.
> Ale od momentu naciśnięcia do pojawienia się jakiejkolwiek reakcji na
> wyświetlaczu mija kilka sekund, po których pojawia się info o druku
> biletu i następne kilka sekund na reakcję drukarki.
>
> Albo wpłatomat. Komunikat, że brak papieru, czy chcesz kontynuować.
> Tak chcę, po zakończonej wpłacie komunikat... weź potwierdzenie, które
> jest dowodem... ale przecież nie ma papieru.
>
> To nie są jakieś darmowe apki z Google Play, tylko systemy za grubą kasę.

No ale kto te systemy zamawia.

do góry