Zastanawia mnnie skąd Ty masz w ogóle obserwacje, po procentah zgaduje, że poznałeś 4 programistów - nie wiem czy wliczasz siebie w to.
Siebie nie, bo ja nie mam języka z HKT, co do liczby masz rację. :) Na dodatek 75% z nich wypowiada się w tym wątku. ;)
Żeby nie dramatyzować, jak to się nie da żyć bez HKT - mam mniej wiecej raz w miesiącu moment, że mi brakuje (Kotlin) - nie placzę bardzo (mam większe problemy w tym języku niż brak HKT). Jest oczywiście możliwe, że jak bym częśćiej pisał w Scali czy Haskellu i lepiej opanował koncept to ten brak by mi bardziej doskwierał.
No właśnie, prawdopodobnie większość języków ma większe problemy. A na pewno ma takie C#.
Mechanizm potrzebny raz w miesiącu nie wygląda na coś niezbędnego.
A jak już dodajemy bajery do języka, to po pierwsze trzeba mieć jakąś priorytetyzację, a po drugie oczywistym chyba jest, że mechanizmy zrozumiałe natychmiastowo będą używane szybciej i częściej niż te potężne, ale wymagające dodatkowej nauki.
Co dają .NETowe genericsy? Są reified, więc można robić na nich zaawansowaną ifologię czasu wykonania. Scalowe genericy natomiast są z jednej strony wymazywane (a więc nie da się zrobić zaawansowanej ifologii czasu wykonania), ale są rozbudowane dzięki czemu można zrobić zaawansowaną ifologię czasu kompilacji. Jak dla mnie analiza typów w czasie kompilacji to rozwiązanie lepsze niż analiza typów w czasie wykonania.
Owszem, analiza podczas kompilacji jest lepsza. Fajnie jeśli język dąży w takim kierunku, ale fajnie też jeśli język nie jest przesadnie skompilkowany, a C# imho już dawno temu punkt nadmiernej kompolikacji osiągnął.
Sporo rzeczy sprowadza się do The Blub Paradox. Jest masa języków, w których można być produktywnym, więc jeśli ktoś osiągnął biegłość w jakimś języku i jest w nim produktywny to na języki bardziej skomplikowane (tzn. mocniejsze w sensie oferowanych mechanizmów) będzie patrzył jak na niepotrzebne udziwnienia.
Mnie nie chodzi o udziwnienia tylko o rachunek włożonego wysiłku do uzyskanego efektu.
No ja się z tym "przezroczysty" po prostu nie zgadzam. Jednocześnie nie umiem powiedzieć, jak bardzo nieprzezroczyste byłoby to, więc to tylko opinia.
No ok. Mnie właściwie nigdy nie interesowało, na jakim systemie mój soft chodzi. Czasami konfigurowałem IISa, ale to wszystko. Od dwóch lat robię głównie w Core i nawet nie wiem, co jest pod spodem bo zwyczajnie nie ma takiej potrzeby.
O kosztach nawet nie mówię, bo nigdzie nie widziałem, ile ta wieloplatformowość pozwoliła zaoszczędzić. To jest gdybanie, tylko że Ty pewnie tak samo nie będziesz umiał uzasadnić, że HKT da mniejsze zyski.
O możliwych oszczędnościach to ja już napisałem w tym wątku, nawet kwoty podałem. No ok, machnąłem się przy mnożeniu, ale idea się zgadza. Średniej wielkości firma może zaoszczędzić 1,5-2mln Euro rocznie.
I przejście na Core to zmiana konfiguracji projektu + ewentualnie zastąpienie niekompatybilnych fragmentów kodu zgodnie z instrukcją. To jest banał i to się robi hurtowo.
A HKT? To koncepcja, której trzeba się nauczyć i zrozumieć. Nie jest to prosta modyfikacja kodu, raczej przepisywanie. Nawet jeśli skraca to kod o 90%, eliminując masę bugów i skracając czas developmentu, to po pierwsze musimy ten kod napisać od nowa (co jest kosztem), a potem mocno przetestować, co jest kolejnym kosztem. Nikt tego nie zrobi z istniejącym kodem.
No i nadal płacimy wiecej za serwery z Windowsem.
Tak więc wieloplatofrmowosć przynosi zyski praktycznie od razu, HKT dałoby może po czasie w zależności od stopnia przyjęcia, i właściwie tylko w przypadku tworzenia nowego oprogramowania.
Ale nullable references z C# w ogóle nie rozwiązują problemu. Być może rozwiążą je za parę lat, jak już cały kod będzie przepisany, ale na chwilę obecną to jest zwykłe ostrzeżenie, które nic nie da przy używaniu bibliotek z różnej wersji C#, różnych języków dotnetowych, pinvoke'a i całej reszty. Pewnie, można to odbić, że jak ktoś będzie pisał nowy projekt, to sobie włączy ostrzeżenie jako błąd i już będzie wszystko cacy, ale jeżeli ktoś tego potrzebował, to już lata temu mógł wziąć bibliotekę do optionali i używać ich zamiast zwykłych referencji. Gdyby nullable references mogły być wymuszone na poziomie CLR-a, to inna rozmowa, a tak, to jest to zwykła analiza kodu.
Owszem, to jest bardzo niedoskonałe rozwiązanie. A to przez to, że zostało zaimplementowane w języku, który od zawsze te nulle miał.
No przecież ludzie używają IKVM.
Serio? Gdzie i po co? Komercyjnie?
Jaki odsetek firm/programistów dotneta to robi?
Nie musieliby portować WPF-a, żeby wspierać desktop na Linuksie, chociażby taki. Ale mogę odwrócić pytanie: udowodnij proszę, że wsparcie Javy nie dałoby żadnego zysku dla ekosystemu i społeczności?
Społeczność ma już swój język i swoje biblioteki. Po prostu nie wydaje mi się, aby wielu ludzi było zainteresowanych Javą na dotnecie.
Takie trochę dziwne gadanie, to były inne czasy, wtedy nikt by nie pomyślał, że Linuks będzie uruchamiany niemal bezpośrednio w Windowsie, albo że dotnet będzie działał wszędzie.
Dla prawników i korporacji czasy są zawsze te same. :)
Było zapytać parę lat temu, nie musiałbyś czekać ;)
Spoko, następnym razem jak będę potrzebował jakieś definicji bez nadmiernego związku z rzeczywistością, to się odezwę. :P
No i parę stron temu właśnie o to zapytałem - jeżeli z jakichś powodów nie chcę migrować aplikacji, to co dotnet dał mi w ciągu ostatnich pięciu lat?
No i ja chyba odpowiedziałem, że trochę lukru.
Ale to bez znaczenia, bo nikogo nie obchodzi, co robią mniejszości i bezrobotni. A jeśli nie migrujesz, to prawdopodobnie szybko znajdziesz się w jednej z tych dwóch grup. :)