Języki c# i java mają dług techniczny którego nie da się naprawić nie zrywając wstecznej kompatybilności. Były tworzone z nullami, z mechanizmem try-catch (ok, dyskusyjne, zmierzam do tego że mając krotki (tuples) można robić mechanizm obsługi błędów jak z Rust albo Go), bez union-types, bez pattern matching. Problem polega na tym że ze względu na zachowanie wstecznej kompatybilności "biblioteki standardowe" tych języków nigdy nie dostosują się do nowych funkcji języków, nawet gdy te je zyskają. Poza tym są to interpretowane kobyły które żrą masę pamięci. Dlatego powinniśmy iść w nowe języki kompilowane do binarek i ewentualnie statycznie łączone typu Go, Rust, Zig, Crystal. Nie wymieniam tu C++ bo nie ma mechanizmu refleksji który jest mega przydatny a wymienione języki posiadają go w formie przynajmniej podstawowej. Nie pozostawaj bierny Przyszłość jest w Twoich rękach Piramidy zbudowali kosmici #programowanie #csharp #java
@nunczako: W cpp możesz odwołać sie do obiektu bezpośrednio przez refererencje, albo wskaźnik. Musiałbyś sobie napisać jakiś wrapper który by Ci po nazwie zwracał referencje i tyle.
@Ewentualnie: mechanizm refleksji polega na tym, że możesz w runtime w zasadzie sprawdzić definicję swojego kodu, c# tutaj jest lepszy od Java bo nawet potrafi zamienić lambdę w abstrakcyjne drzewo składni (expresieon trees) i dzięki temu mają najlepszy ORM jaki do tej pory powstał. Nie zrobisz tego w c/c++ (edit: ani w java)
@Ewentualnie: tak, jak dla każdej klasy chyba zdefiniujesz metodę (albo zaimplemntujesz interfejs czy tam klasę bazową) która się nazywa "whatIsMyName". Ale wtedy Javowcy Ci powiedzą że to łamie SOLID (deb...)
@nunczako: no ale ziomek, to jest gdzieś pod spodem zaimplementowane jest w taki sposób (albo moze inny w/e) , nie masz niczego za darmo, jako programista powinieneś to wiedzieć. Btw w javie masz klase Class która wykorzystuje Unsafe
@Ewentualnie: ziomek, ale o czym rozmawiamy? mój pierwszy post zmierzał do tego że "biblioteki standardowe" popularnych języków były projektowane pod te języki kiedy one jeszcze nie miały funkcji które dzisiaj mają. Kolekcje w Javie zwracają NULLe a nie Optionale, i już nigdy tych Optionali nie zwrócą. Drugi wątek który zacząłem to to że może nie potrzebujemy dzisiaj języków zarządzanych bo języki kompilowane do binarek oferują nam podobne możliwości (które dotąd
@nunczako: Kolekcje w javie można zmienić, tylko po co mają zwracać optionale, optionale sa przydatne w momencie gdy kolekcja reprezentuje jakis stan, a kto robi np in memory cache w array list. Jakby byla potrzeba to by zrobili jak z vector i arraylist. Nie wiem co to jezyki zarzadzane.
@Ewentualnie: vector jest deprectaed od lat, mapa (nie moge sprawdzić bo intenret mi naprawde dupnie dziala) zwraca nula zamiast optionala. Interefejs bazowej biblioteki jest przestarzały i ze względu na wsteczną kompatybilność już nigdy nie zostanie poprawiony.
@nunczako: generalnie to można by zaimplementować całą java.utils od nowa tylko każdy ma to w dupie tak samo jak każdy miał w dupie JavaEE, np taki JMS można było bardzo upiększyć, ale np z EJB zrobili porządek, tylko co z tego jak za późno
@nunczako: niby dlaczego, trzeba po prostu zapisywac gdzieś te informacje xD. C# został napisany w cpp to nawet nie ma o czym gadać xd
@Ewentualnie: z takim argumentem to i w assemblerze da się używać reflekjsi. W c++ nie możesz zamienić struktury na jsona automatycznie, trzeba ręcznie pisać kod. Oczywiście da się go napisać, ale chodzi o to, żeby kod był pisany szybko i bez błędów. Ręczne generowanie
@nunczako: Coś ci się pomerdało. To, że język wspiera kompatybilność wsteczną, nie znaczy, że nie może dodawać nowych rozwiązań - tylko, że nie może usunąć tych starych. W najgorszym wypadku może usunąć stare konstrukcje z języka ale zostawić je w kompilatorze, żeby nadal się kompilowało ale nie można było pisać.
@nunczako: Przede wszystkim jest to ciekawy post (co nie zdarza sie tutaj zbyt czesto).
Pisze w C#, ale autor posta ewidentnie nie. O ile od strony teoretycznej podnoszone przez niego argumenty sa trafne, tak praktyka pokazuje, ze mam odpalone na produkcji systemy napisane w .Net Core na maszynach ARM z 1GB RAMu... Narzut interpretera jest w zasadzie pomijalny przy rozwiazaniach innych niz embedded.
Nie zgodze sie z teza dot. dlugu technologicznego w
@user-agent-switcher: "problem" to może za dużo powiedziane, ale teraz gdy .Net działa na Linuksach to jest to według mnie najbardziej interesująca platforma. Można zrozumieć JavaSkryptowców że piszą backend na NodeJSa bo dzięki temu mają jeden język na frontendzie i backendzie, ale .Net ma teraz tego Blazora więc tutaj też robi się ciekawie (ale nic w tym jeszcze nie pisałem). Są takie gotowe komponenty GUI dla popularnych frameworków www.primefaces.org, jakby zrobili
Poza tym są to interpretowane kobyły które żrą masę pamięci.
Dlatego powinniśmy iść w nowe języki kompilowane do binarek i ewentualnie statycznie łączone typu Go, Rust, Zig, Crystal. Nie wymieniam tu C++ bo nie ma mechanizmu refleksji który jest mega przydatny a wymienione języki posiadają go w formie przynajmniej podstawowej.
Nie pozostawaj bierny
Przyszłość jest w Twoich rękach
Piramidy zbudowali kosmici
#programowanie #csharp #java
@Ewentualnie: z takim argumentem to i w assemblerze da się używać reflekjsi. W c++ nie możesz zamienić struktury na jsona automatycznie, trzeba ręcznie pisać kod. Oczywiście da się go napisać, ale chodzi o to, żeby kod był pisany szybko i bez błędów. Ręczne generowanie
Pisze w C#, ale autor posta ewidentnie nie. O ile od strony teoretycznej podnoszone przez niego argumenty sa trafne, tak praktyka pokazuje, ze mam odpalone na produkcji systemy napisane w .Net Core na maszynach ARM z 1GB RAMu... Narzut interpretera jest w zasadzie pomijalny przy rozwiazaniach innych niz embedded.
Nie zgodze sie z teza dot. dlugu technologicznego w