-
Data: 2023-05-21 20:52:14
Temat: Re: Dziwny problem z kodem w C (gcc mips/pic32)
Od: heby <h...@p...onet.pl> szukaj wiadomości tego autora
[ pokaż wszystkie nagłówki ]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ę.
Następne wpisy z tego wątku
- 21.05.23 21:26 Marek
- 21.05.23 22:03 heby
- 21.05.23 22:52 titanus
- 21.05.23 22:57 Robert Wańkowski
- 21.05.23 23:19 heby
- 21.05.23 23:26 heby
- 22.05.23 10:39 io
- 22.05.23 10:46 io
- 22.05.23 10:50 io
- 22.05.23 11:14 heby
- 22.05.23 13:14 J.F
- 22.05.23 13:17 J.F
- 22.05.23 13:24 Janusz
- 22.05.23 13:33 heby
- 22.05.23 14:03 J.F
Najnowsze wątki z tej grupy
- DS1813-10 się psuje
- Taki tam szkolny problem...
- LIR2032 a ML2032
- SmartWatch Multimetr bezprzewodowy
- olej psuje?
- Internet w lesie - Starlink
- Opis produktu z Aliexpress
- No proszę, a śmialiście się z hindusów.
- Zewnętrzne napięcie referencyjne LM385 1,2V -> 100mV dla ICL7106, Metex M-3800
- karta parkingowa
- Wl/Wyl (On/Off) bialy/niebieski
- I3C
- Pytanie o transformator do dzwonka
- międzymordzie USB 3.2 jako 2.0
- elektronicy powinni pomysleć o karierze elektryka
Najnowsze wątki
- 2024-11-24 Aby WKOOOORWIĆ ekofaszystów ;-)
- 2024-11-22 OC - podwyżka
- 2024-11-22 wyszedł z domu bez buta
- 2024-11-22 Bieda hud.
- 2024-11-24 DS1813-10 się psuje
- 2024-11-23 Białystok => Inżynier bezpieczeństwa aplikacji <=
- 2024-11-23 Szczecin => QA Engineer <=
- 2024-11-23 Warszawa => SEO Specialist (15-20h tygodniowo) <=
- 2024-11-22 Warszawa => Kierownik Działu Spedycji Międzynarodowej <=
- 2024-11-22 Warszawa => Senior Account Manager <=
- 2024-11-22 Warszawa => Key Account Manager <=
- 2024-11-22 Warszawa => DevOps Specialist <=
- 2024-11-22 Kraków => IT Expert (Network Systems area) <=
- 2024-11-22 Warszawa => Infrastructure Automation Engineer <=
- 2024-11-22 Warszawa => Presales / Inżynier Wsparcia Technicznego IT <=