Czy .NET to szwajcarski scyzoryk?

1
somekind napisał(a):

pewnie możesz sobie policzyć prawdopodobieństwo

@somekind No liczę i wychodzi mi małe, więc szukam danych na potwierdzenie lub obalenie.

somekind napisał(a):

Błędem z jakiego konkretnie powodu?

Jeżeli rozmawiamy o kosztach i nie korzystamy z elementów Windowsa, to trzeba było od razu iść na Linuksa (i użyć odpowiedniego języka).

somekind napisał(a):

Nie bardzo wiem, dlaczego czyjeś prywatne dewiacje miałyby mieć znaczenie w tej dyskusji. Programista nie musi być administratorem, prawdopodobnie nawet lepiej, żeby nie był.

Nikt nie mówi o administrowaniu, tylko o programowaniu. Nie wypada oczekiwać od programisty WinAPI znajomości POSIX-a, tak samo jest na poziomie języka C# czy Java.

somekind napisał(a):

Pewnie nie trzeba, ale strzelam, że równoczesny bujny rozwój i tworzenie nowej platformy, która ma wspierać wszystkie stare funkcje oraz te nowo dodawane byłoby znacznie bardziej kosztowne. Dla mnie normalne jest to, że soft w pewnym momencie przechodzi w etap supportu, a na nowe, wspaniałe ficzery trzeba poczekać do nowej wersji.

No i o długość tego oczekiwania się rozchodzi.

somekind napisał(a):

A co daje HKT?

A co daje async albo LINQ to Objects?

somekind napisał(a):

Trochę nie rozumiem celu tej incepcji. Co by to komu dało?

Trochę obosieczny ten argument "co by to komu dało", bo można go użyć do wszystkiego. Już sama możliwość uruchamiania bibliotek jvmowych dałaby chociażby szansę na walkę o aplikacje desktopowe na innych platformach, a tak, to trzeba kleić nowy framework (albo przenosić stary i porzucony).

somekind napisał(a):

Odbijając piłeczkę - tu nie chodzi o to, co jest dla Ciebie nieistotne. :)

No dla mnie w ogóle dotnet jest nieistotny, bo w nim nie zarabiam, więc nie trzeba się przejmować moim gadaniem.

somekind napisał(a):

Możliwość cięcia kosztów w biznesie jest istotnym czynnikiem, biznes to robi, a biznes to też źródło naszych zarobków.

Biznes potrzebuje też bezpieczeństwa i kompatybilności wstecznej, a ta druga została mocno nadwyrężona (o ile nie złamana).

0
Afish napisał(a):

@somekind No liczę i wychodzi mi małe, więc szukam danych na potwierdzenie lub obalenie.

No jeżeli prawdopodobieństwo tego, że nie szukając trafiam jest małe, to to zjawisko musi być bardzo powszechne.

Jeżeli rozmawiamy o kosztach i nie korzystamy z elementów Windowsa, to trzeba było od razu iść na Linuksa (i użyć odpowiedniego języka).

No nie wiem, czy zatrudnienie nowych programistów, nowych administratorów, i w ogóle cała migracja na nową platformę to są niższe koszty. Myślę, że jest wręcz skrajnie przeciwnie.

Nikt nie mówi o administrowaniu, tylko o programowaniu. Nie wypada oczekiwać od programisty WinAPI znajomości POSIX-a, tak samo jest na poziomie języka C# czy Java.

Ale po co jakieś WinAPI czy POSIX dla aplikacji webowych?
Dla serwera uruchamiającego kod nie ma znaczenia na jakim systemie operacyjnym powstał. Firma oszczędza na serwerach hostujących aplikacje i serwisy, nie na systemie dla developera, ten jest bez znaczenia.

A co daje async albo LINQ to Objects?

Ja nie wiem, więc pytam. Ale jeśli HKT daje to samo, co rzeczy, które wymieniłeś, to chyba obaliłeś własny argument, bo to w końcu tylko kilka liniej kodu mniej.

Trochę obosieczny ten argument "co by to komu dało", bo można go użyć do wszystkiego. Już sama możliwość uruchamiania bibliotek jvmowych dałaby chociażby szansę na walkę o aplikacje desktopowe na innych platformach, a tak, to trzeba kleić nowy framework (albo przenosić stary i porzucony).

Może ja nie zrozumiałem, ale to co wcześniej napisałeś zabrzmiało dla mnie jak uruchamianie jednej maszyny wirtualnej w drugiej, a teraz piszesz o tym, aby jedna maszyna mogła uruchamiać binarki innej. No i spoko, tylko:

  • zbudowanie takiej warstwy kompatybilności nie jest raczej darmowe;
  • nie widzę w tym za bardzo zysku dla świata dotnetu (desktop to nisza), a tym bardziej dla Microsoftu;
  • ostatnia próba bycia kompatybilnym się źle skończyła (tzn. w ogólności dobrze, ale kilka mln fanatyków Javy ma ból tyłka o istnienie C#)

No dla mnie w ogóle dotnet jest nieistotny, bo w nim nie zarabiam, więc nie trzeba się przejmować moim gadaniem.

Nie tyle nie przejmować, ale może jakbyś zarabiał, to byś wiedział jak rynek wygląda i nie pisał tyle o desktopach, WinAPI, i braku zysków z wieloplatformowości.

Biznes potrzebuje też bezpieczeństwa i kompatybilności wstecznej, a ta druga została mocno nadwyrężona (o ile nie złamana).

Nie zauważyłem, aby ktoś się czuł niebezpiecznie. Migracja nie jest obowiązkowa, nowy soft tworzy się w core, stary się utrzymuje tak jak jest.

1

Ja sam na co dzień pracuję na Linuxie, i prowadzę aktywny development kilku aplikacji w .NET Core, który poza pewnymi mankamentami jest w pełni możliwy na tej platformie (przykładowy mankament to np to że jak chcę skorzystać z PerfView to i tak muszę mieć Windowsa, a w praktyce najlepiej by było gdybym same benchmarki też przeprowadził na Windows) - mówię o aplikacjach serwerowych.

Przyznaję - większość z naszych developerów C# używa na co dzień Windowsa, ale nie jest to reguła. Dla mnie to plus że nie muszę korzystać z Windowsa zwłaszcza ze względu na nasz software który jest spoza świata .NET - znacznie wygodniej korzysta się z basha (możliwe że teraz kiedy jest WSL 2 może to porównanie byłoby mniej korzystne na rzecz Linuxa) niż z PowerShell.
Pomijam już kwestię niższych kosztów związanych z środowiskiem uruchomieniowym.
Nie wiem na ile to istotne dla samego Microsoftu, ale wyobrażam sobie że baza developerów piszących Open Source w .NET może wzrosnąć właśnie dlatego że ci developerzy nie będą zmuszeni do korzystania z samego Windowsa (co bezpośrednio przełożyłoby się też na plus dla nas).
Przykładowo - my korzystamy z różnych baz zarówno SQL jak i NoSQL. Swego czasu trafiłem na bug w driverze do MongoDB dla którego ticket był otwarty od długiego czasu (bodaj 2 lata o ile pamiętam), a że dotyczył jakiegoś specyficznego use case-u to nikt tego nie naprawił. Zakładam że im większe community to potencjalnie wyższa jakość takich paczek i bardziej aktywny development. Oczywiście tak długo jak nie wychodzimy poza stos Microsoftu (czyli bierzemy ich bazę danych) to to nie jest specjalnie istotna kwestia bo oni (Microsoft) dostarcza wszystko.
Inne problemy tego typu miałem z driverem do ElasticSearcha - który wewnętrznie dokonuje potencjalnie dużych alokacji, co dla dużych odpowiedzi w moim use case już miało znaczenie. Oba problemy udało mi się rozwiązać/obejść niemniej warto to mieć na uwadze.

1
somekind napisał(a):

No jeżeli prawdopodobieństwo tego, że nie szukając trafiam jest małe, to to zjawisko musi być bardzo powszechne.

Logika niby żelazna ¯_(ツ)_/¯

somekind napisał(a):

No nie wiem, czy zatrudnienie nowych programistów, nowych administratorów, i w ogóle cała migracja na nową platformę to są niższe koszty. Myślę, że jest wręcz skrajnie przeciwnie.

Właśnie zacząłeś zbijać swój własny argument.

somekind napisał(a):

Ale po co jakieś WinAPI czy POSIX dla aplikacji webowych?

Jak nigdy nie miałeś potrzeby, to nie zrozumiesz.

somekind napisał(a):

Ja nie wiem, więc pytam. Ale jeśli HKT daje to samo, co rzeczy, które wymieniłeś, to chyba obaliłeś własny argument, bo to w końcu tylko kilka liniej kodu mniej.

No ba, wszystkie wysokopoziomowe języki opierają się o „kilka linii kodu mniej”, bo przecież to samo da się zrobić w kodzie maszynowym.

somekind napisał(a):

Może ja nie zrozumiałem, ale to co wcześniej napisałeś zabrzmiało dla mnie jak uruchamianie jednej maszyny wirtualnej w drugiej, a teraz piszesz o tym, aby jedna maszyna mogła uruchamiać binarki innej.

Jak to zrobią, to już ich sprawa.

somekind napisał(a):

No i spoko, tylko:

  • zbudowanie takiej warstwy kompatybilności nie jest raczej darmowe;

Żadna praca nie jest darmowa.

somekind napisał(a):
  • nie widzę w tym za bardzo zysku dla świata dotnetu (desktop to nisza), a tym bardziej dla Microsoftu;

Nisza, a znowu robią kolejny framework do niej.

somekind napisał(a):

Nie tyle nie przejmować, ale może jakbyś zarabiał, to byś wiedział jak rynek wygląda i nie pisał tyle o desktopach, WinAPI, i braku zysków z wieloplatformowości.

Microsoft robi nowy framework do desktopu, o WinAPI pytają mnie programiści dotneta na każdej konferencji, a wieloplatformowość chwaliłem w tym temacie już kilkakrotnie.

somekind napisał(a):

Nie zauważyłem, aby ktoś się czuł niebezpiecznie. Migracja nie jest obowiązkowa, nowy soft tworzy się w core, stary się utrzymuje tak jak jest.

A ja zauważyłem ¯_(ツ)_/¯

3

Współpracowałem z firmą, w której programiści tworzyli kod na Windowsie, a wrzucali na Linuxa (z użyciem Mono i dockerów).
Dlaczego tak? Bo pewnie:

  • dockery, kontenery i inne fajne rzeczy, które wydawały się idealne do profilu firmy były bardziej pod Linuxa
  • administratorzy znali bardziej Linuxa; wydaje się, że mimo wszystko trudniej znaleźć dobrych administratorów Windows niż Linux
  • jak ma się już programistów .NET to raczej łatwiej nauczyć ich różnic Linux-Windows niż kazać pisać Javie; problemy z kompatybilnością były częste, ale bardzo drobne i wynikały głównie z tego, że ktoś nie używał bibliotek standardowych, tylko np. ręcznie tworzył ścieżkę do plików itp. Nawet udawało się odpalać natywne pliki exe :) Ale oczywiście można trafić na przypadki "nie do obejścia".

Planowane jest przejście na .NET Core, bo:

  • ma być szybciej i wydajniej
  • Mono rozwija się wolniej
  • ASP Core jest fajne i programiści chcą w tym robić (może to głupie, ale tak jest)
0
Afish napisał(a):

Właśnie zacząłeś zbijać swój własny argument.

W jaki konkretnie sposób zbijam argument, że dotnetowcom łatwiej zostać na dotnecie niż uczyć się jakiejś innej platformy, a jak mają już VS na Windowsie, to na tym zostaną, a zysku z migracji developmentu na Linuksa nigdy by nie było?

Jak nigdy nie miałeś potrzeby, to nie zrozumiesz.

Ciekawy wniosek, niemniej jednak aplikacja webowa korzystająca z WinAPI to dość rzadkie zjawisko. Tych bez takiej zależności jest znacznie więcej, a z ich hostowania na Linuksie zysk jest znaczny.

No ba, wszystkie wysokopoziomowe języki opierają się o „kilka linii kodu mniej”, bo przecież to samo da się zrobić w kodzie maszynowym.

No więc czemu Twoje kilka linii kodu mniej ma być lepsze niż te kilka linii kodu mniej, które w ostatnich latach zaimplementowali? :)

Jak to zrobią, to już ich sprawa.

To nie jest kwestia tego jak oni by to zrobili, tylko tego, abyś precyzyjnie wyraził, o co Ci chodzi. :P

Microsoft robi nowy framework do desktopu, o WinAPI pytają mnie programiści dotneta na każdej konferencji, a wieloplatformowość chwaliłem w tym temacie już kilkakrotnie.

Hmm, nie myślałeś może, że pytają Cię o to, bo poruszasz takie, a nie inne tematy? :P

A ja zauważyłem ¯_(ツ)_/¯

No i jaka jest konkretna przyczyna tego poczucia niebezpieczeństwa? Bo chyba nie fakt istnienia Core.

.NET od początku był platformą m.in. dla aplikacji webowych, a Microsoft od dawna nie jest biznesem opartym o sprzedaż systemów operacyjnych. Największy ich konkurent od początku oferował wieloplatformowość, a jej brak często był głównym argumentem przeciwko dotnetowi. Wcale nie dziwi mnie, że Microsoft zdecydował się podążyć w tym kierunku, bo w ten sposób zadowolą biznes. Zadowolenie paru programistów hipsterów przez dodanie im paru dżezi ficzerów takiego zysku nie da.

PS Widzę, że sylwestrowy klimat już Ci się udzielił, ale jeśli chcesz prawidłowo wstawić emotkę żula spod Żabki, to musisz dać podwójny backslash.

2

Ja ze swojej strony powiem tylko jedno. Polecam policzyć sobie koszty licencji dla wymagającej aplikacji (Windows Server licencjonowany jest per rdzeń).

Dodatkowo mało kto wie jak w tym wszystkim jest licencjonowany IIS. Jeżeli np. mamy 1000 pracowników i wystawiamy WebApi postawione na IIS, które jest dostępne tylko dla naszej organizacji to dla każdego pracownika musimy mieć licencję CAL.

To jest właśnie to na czym zależy Biznesowi. Obniżanie kosztów. .NET Core na to pozwala.

0

.net to rozwiązanie bardziej pudełkowe, dużo rzeczy działa ad hoc, nie trzeba się bawić w magiczne konfiguracje
java to zbiór bibliotek myślicieli z całego świata, zawsze był problem żeby postawić ten sam projekt u kogoś na nowym kompie..., jak już przeszło się przez ból konfiguracji to jakoś to działało, na szczęście Idea uratowała trochę tę technologię bo netbensy czy eclipsy były patrząc na nie archaiczne w porównaniu do tego co oferował i jak działał visual studio. Mi przyjemniej pracuje się na .net.

1

Czy .NET to szwajcarski scyzoryk?

Ze Szwajcarii to jest Scala :]

A co daje HKT?

HKT to takie "generics done right" (pod warunkiem, że ktoś lubi pogłówkować przy typach). Zamiast robić isinstanceofy (w runtime) można zakodzić system typów (compile time), który tego nie wymaga.

Ekstremalny przykład: https://www.servant.dev/ - biblioteka do opisywania endpointów jako typy. Dzięki temu kompilator może statycznie sprawdzić czy wszystkie typy i ścieżki są kompatybilne między np. serwerem i klientem. To wszystko bez użycia makr czy jakichkolwiek metod innych niż system generycznych typów.

1
somekind napisał(a):

W jaki konkretnie sposób zbijam argument, że dotnetowcom łatwiej zostać na dotnecie niż uczyć się jakiejś innej platformy, a jak mają już VS na Windowsie, to na tym zostaną, a zysku z migracji developmentu na Linuksa nigdy by nie było?

Argument dotyczył kosztu uruchamiania kodu, a nie jego rozwoju.

somekind napisał(a):

Ciekawy wniosek, niemniej jednak aplikacja webowa korzystająca z WinAPI to dość rzadkie zjawisko. Tych bez takiej zależności jest znacznie więcej, a z ich hostowania na Linuksie zysk jest znaczny.

Zgadza się.

somekind napisał(a):

No więc czemu Twoje kilka linii kodu mniej ma być lepsze niż te kilka linii kodu mniej, które w ostatnich latach zaimplementowali? :)

To jest opinia, możesz się z nią nie zgodzić. Mógłbym uzasadniać dalej, na przykład ostatnio Bartek Adamczewski wrzucał na grupie dotnetowej, że JIT nawet nie usuwa nieużywanych zmiennych lokalnych (złośliwie bym powiedział, że pewnie za chwilę okaże się, że nawet getterów i setterów nie wyplaszcza, ale chyba jednak robi to na produkcji). Po prostu jak myślę o ostatnich latach rozwoju dotneta, to mam wrażenie, że zajęli się rzeczami, które mają mały stosunek wartości dodanej do czasochłonności.

somekind napisał(a):

To nie jest kwestia tego jak oni by to zrobili, tylko tego, abyś precyzyjnie wyraził, o co Ci chodzi. :P

Chcę uruchamiać aplikacje javowe na dotnecie i mieć pełną dostępność w obie strony (chociaż już dostęp do javowych rzeczy z dotneta byłby dla mnie wystarczający). Jak to zrobią, to już mi bez różnicy, mogą wziąć IKVM, mogą robić przepisywnie w locie, mogą hostować w osobnym procesie i łączyć się przez strumienie, byleby było stabilne i szybkie.

somekind napisał(a):

Hmm, nie myślałeś może, że pytają Cię o to, bo poruszasz takie, a nie inne tematy? :P

Możliwe, ale to pokazuje, że oni pracują nad tym. Jak ktoś przychodzi po pomoc, bo async psuje mu się z jakimś systemowym muteksem i nie wie, jak to zrobić porządnie, to właśnie to potwierdza moje uwagi, że znajomość systemu operacyjnego jest potrzebna i nie wystarczy tylko "znać dotneta".

somekind napisał(a):

No i jaka jest konkretna przyczyna tego poczucia niebezpieczeństwa? Bo chyba nie fakt istnienia Core.

Niepewność co do przyszłości frameworka i tego, czy jest sens dalej rozwijać aplikacje na tym, bo nie wiadomo, czy będą działać na corze. Dotyczy to głównie integracji z ekosystemem windowsa, a nie jakichś "przenośnych" rzeczy.

somekind napisał(a):

.NET od początku był platformą m.in. dla aplikacji webowych, a Microsoft od dawna nie jest biznesem opartym o sprzedaż systemów operacyjnych. Największy ich konkurent od początku oferował wieloplatformowość, a jej brak często był głównym argumentem przeciwko dotnetowi. Wcale nie dziwi mnie, że Microsoft zdecydował się podążyć w tym kierunku, bo w ten sposób zadowolą biznes. Zadowolenie paru programistów hipsterów przez dodanie im paru dżezi ficzerów takiego zysku nie da.

Też mnie to nie dziwi i sam chwaliłem wieloplatformowość, ale mam wrażenie, że nie czytasz tego, co piszę. Ja wskazuję, że moim zdaniem mogli wykorzystać poprzednie lata lepiej, w tym lepiej dodać wsparcie Linuksa bez zrywania z frameworkiem.

somekind napisał(a):

PS Widzę, że sylwestrowy klimat już Ci się udzielił, ale jeśli chcesz prawidłowo wstawić emotkę żula spod Żabki, to musisz dać podwójny backslash.

O, dzięki. Nie wiedziałem, a wpisuję ją standardowym skrótem windowsowym.

2
Afish napisał(a):

Argument dotyczył kosztu uruchamiania kodu, a nie jego rozwoju.

Pierwotnie tak, potem zacząłeś pisać o podróżach w czasie (i chyba także międzywymiarowych, bo "odpowiedni język" jest dostępny na Linuksie raptem od 3,5 roku).

Ja sobie słabo radzę z zaawansowaną fizyką, więc może napiszę jeszcze raz od początku. Firmie zatrudniającej programistów C#/.NET zawsze było taniej stworzyć aplikację webową, nieużywającą Windowsa w C#/.NET niż zatrudniać nowych ludzi do pisania na jedyną słuszną platformę. Teraz taka firma może zaoszczędzić na utrzymywaniu swojego softu w chmurze taniej. To zysk dla biznesu.

I niezależnie od tego jak bardzo Czechosłowacko-Indonezyjscy komuniści by tego chcieli, nie uda się, aby wszyscy pisali w jednym słusznym języku. Zawsze ktoś zachowa resztki godności i będzie pisał w C, no i jest jeszcze tych dwóch gości od Delphi. Ten plan się nie uda, więc serio już można przestać za nim lobbować.

To jest opinia, możesz się z nią nie zgodzić.

To nie jest tak, że ja się nie zgadzam, po prostu bajery w języku to subiektywne zabawki dla programistów, a wieloplatformowość to zysk dla biznesu.

Po prostu jak myślę o ostatnich latach rozwoju dotneta, to mam wrażenie, że zajęli się rzeczami, które mają mały stosunek wartości dodanej do czasochłonności.

No najbardziej czasochłonna była chyba właśnie wieloplatformowość, a to jest wartość dodana.

Chcę uruchamiać aplikacje javowe na dotnecie i mieć pełną dostępność w obie strony (chociaż już dostęp do javowych rzeczy z dotneta byłby dla mnie wystarczający). Jak to zrobią, to już mi bez różnicy, mogą wziąć IKVM, mogą robić przepisywnie w locie, mogą hostować w osobnym procesie i łączyć się przez strumienie, byleby było stabilne i szybkie.

No tak, tylko jaki z tego zysk dla świata .NET?

Możliwe, ale to pokazuje, że oni pracują nad tym. Jak ktoś przychodzi po pomoc, bo async psuje mu się z jakimś systemowym muteksem i nie wie, jak to zrobić porządnie, to właśnie to potwierdza moje uwagi, że znajomość systemu operacyjnego jest potrzebna i nie wystarczy tylko "znać dotneta".

No niewątpliwie, jeśli się pisze na system, to trzeba znać ten system. :)

Też mnie to nie dziwi i sam chwaliłem wieloplatformowość, ale mam wrażenie, że nie czytasz tego, co piszę. Ja wskazuję, że moim zdaniem mogli wykorzystać poprzednie lata lepiej, w tym lepiej dodać wsparcie Linuksa bez zrywania z frameworkiem.

Gdyby tak zrobili, to zostaliby z frameworkiem, który w niektórych miejscach nieco cuchnął. Pisanie od nowa dało szanse poprawić parę rzeczy.

1
somekind napisał(a):

Ja sobie słabo radzę z zaawansowaną fizyką, więc może napiszę jeszcze raz od początku. Firmie zatrudniającej programistów C#/.NET zawsze było taniej stworzyć aplikację webową, nieużywającą Windowsa w C#/.NET niż zatrudniać nowych ludzi do pisania na jedyną słuszną platformę. Teraz taka firma może zaoszczędzić na utrzymywaniu swojego softu w chmurze taniej. To zysk dla biznesu.

Tak, zgadzam się. Tylko potem punktuję, że to nie jest "darmowe", bo w moim odczuciu (i z mojego doświadczenia) trzeba też znać platformę pod spodem, więc to nie jest tak, że nagle wszystko śmiga na Linuksie, tylko też jest to jakiś koszt po stronie zespołu programistów. Kosztu zespołu administratorów nie uwzględniam, on też tam jest. I pointa jest taka — ja nie wiem, jak duży jest to zysk dla biznesu, ale jeżeli jest on naprawdę znaczący, to czy wybranie C# lata temu nie było błędem i może nie powinno się iść w Javę + Linuksa od samego początku?

somekind napisał(a):

To nie jest tak, że ja się nie zgadzam, po prostu bajery w języku to subiektywne zabawki dla programistów, a wieloplatformowość to zysk dla biznesu.

Używasz słów, które nie mają jasnej definicji. Czym jest "bajer w języku"? Czy pętla jest bajerem (wszak goto wystarczy)? Czy async jest bajerem (Java nie ma i żyje)? Oba te elementy są zaoszczędzeniem "kilku linijek kodu", ale mają wymierny zysk mierzony w pieniądzach wynikający z przyspieszenia działania aplikacji i skróceniu czasu jej implementowania.

somekind napisał(a):

No najbardziej czasochłonna była chyba właśnie wieloplatformowość, a to jest wartość dodana.

Ponownie, ja nie neguję wartości dodanej. Ja sugeruję, że mogła być ona jeszcze większa, tylko źle się do tego zabrano. Nawet lekko parafrazując Twój argument — jeżeli "bajery w języku" nie dają wartości biznesowej, to dlaczego skupiano się na dodawaniu nullable references, a nie na szybszym wsparciu assembly .NET Frameworka bezpośrednio na .NET Corze?

somekind napisał(a):

No tak, tylko jaki z tego zysk dla świata .NET?

Większy dostęp do bibliotek, wsparcie dla aplikacji desktopowych, możliwość całkowitego przeniesienia aplikacji javowej na dotnet i zysk wydajności (a w efekcie oszczędność kasy).

somekind napisał(a):

No niewątpliwie, jeśli się pisze na system, to trzeba znać ten system. :)

Używanie systemowego muteksa nie jest żadnym "pisaniem na system", nie jest też nim czytanie z plików i pisanie do nich, albo komunikacja po sieci. Nie jest też nim analizowanie wydajności aplikacji, robienie zrzutów pamięci i profilowanie, a te rzeczy też się różnią między Windowsem a Linuksem.

somekind napisał(a):

Gdyby tak zrobili, to zostaliby z frameworkiem, który w niektórych miejscach nieco cuchnął. Pisanie od nowa dało szanse poprawić parę rzeczy.

Tak, a potem musieli wycofać się rakiem z wielu decyzji. Nowy csproj oparty o json czy co tam było na początku - wróćmy jednak trochę do starego. Brak makerefów - jednak je dodajmy, bo ludzie ich chcą. Optymalizacja OrderBy + FirstOrDefault - odkręcamy, bo jednak kiepsko wyszło. Nie wspieramy assembly .NET Frameworka - no jednak to dodajemy, bo bez tego dużo ludzi nie pójdzie dalej. Z takich większych rzeczy, to chyba tylko appdomeny i Thread.Abort wyleciały i nie wróciły potem. Nie wiem, jak bardzo spartolony był kod dotneta, że nie dało się go przenieść inkrementacyjnie, ale jesteśmy 5 lat później i widzimy, że wiele starych rzeczy działa "tak samo" na Corze, więc skoro tak, to może te dałoby się dojść do tego miejsca bez drastycznego zaczynania od zera.

0

Optymalizacja OrderBy + FirstOrDefault - odkręcamy, bo jednak kiepsko wyszło.

https://github.com/dotnet/docs/issues/19683
https://github.com/dotnet/runtime/issues/31554

haha

1
Afish napisał(a):

złośliwie bym powiedział, że pewnie za chwilę okaże się, że nawet getterów i setterów nie wyplaszcza, ale chyba jednak robi to na produkcji

O, a jednak Bartek pokazał, że getter na interfejsie jest dla dotneta zbyt skomplikowany: https://www.facebook.com/groups/net.developers.poland/permalink/1745205212327493/

Jasne, można odbić, że to tylko getter, że jakbym chciał klepać algo, to wezmę C++, że "już za moment to naprawią"…

1

Tak, zgadzam się. Tylko potem punktuję, że to nie jest "darmowe", bo w moim odczuciu (i z mojego doświadczenia) trzeba też znać platformę pod spodem, więc to nie jest tak, że nagle wszystko śmiga na Linuksie, tylko też jest to jakiś koszt po stronie zespołu programistów

Ja tam programuje w Javie/Kotline i na Linuxie i na Windowsie, i nigdy poza jednym wyjątkiem nie miałem jakiś problemów wymagających znajomości platformy pod spodem. Jedyny przypadek jaki kojarze to potrzeba instalacji jakiś bibliotek w Linuxie na potrzeby serwera reaktywnego Netty. Platforma powinna dostarczać jakąś warstwę abstrakcji, np. na to że w jednym systemie jest '/' a w innym '' w ścieżkach plików. Aplikacje biznesowe są zazwyczaj webowe, a te generalnie tak bardzo od systemu nie zależą jeśli maszyna wirtualna jest dobrze zaimplementowana.

I pointa jest taka — ja nie wiem, jak duży jest to zysk dla biznesu, ale jeżeli jest on naprawdę znaczący, to czy wybranie C# lata temu nie było błędem i może nie powinno się iść w Javę + Linuksa od samego początku?

Ale Ty wiesz że cały czas powstaje nowy soft? Ja bym na miejscu tworców .NETa wolał mieć więcej potencjalnych klientów. Ale dodam że tu nie chodzi tylko o to że serwery są tańsze, na Linuxie moga być jakieś narzędzia które gorzej działają albo ich nawet na początku nie ma na Windowsie, np. Docker

Czy async jest bajerem (Java nie ma i żyje)?

Jest adnotacja, oczywiście w Springu xD //ale to taki offtopic :P

1

Ja tam programuje w Javie/Kotline i na Linuxie i na Windowsie, i nigdy poza jednym wyjątkiem nie miałem jakiś problemów wymagających znajomości platformy pod spodem. Jedyny przypadek jaki kojarze to potrzeba instalacji jakiś bibliotek w Linuxie na potrzeby serwera reaktywnego Netty. Platforma powinna dostarczać jakąś warstwę abstrakcji, np. na to że w jednym systemie jest '/' a w innym '' w ścieżkach plików. Aplikacje biznesowe są zazwyczaj webowe, a te generalnie tak bardzo od systemu nie zależą jeśli maszyna wirtualna jest dobrze zaimplementowana.

no i generalnie jeżeli chodzi o web dev, to tak to działa

ja osobiście chyba największy problem jakie miałem z Linuxem to takie, że musiałem font w systemie doinstalować aby generować pdfy.

Nie wiem o jakich rzeczach day2day @Afish piszę, bo ten temat poruszany 18 dni temu zszedł na WSL i końce linii :P

1
Aleksander32 napisał(a):

Ja tam programuje w Javie/Kotline i na Linuxie i na Windowsie, i nigdy poza jednym wyjątkiem nie miałem jakiś problemów wymagających znajomości platformy pod spodem.

To może nawet nie tyle chodzi o znajomość, co o niejawną zależność. Dotnet dużo rzeczy "odziedziczył" z Windowsa, bo chciał się w niego wpasować (aplikacja dotnetowa jest aplikacją natywną), Java od początku była wieloplatformowa, więc jak coś nie działałoby na wszystkich platformach, to tego nie było.

Aleksander32 napisał(a):

Ale Ty wiesz że cały czas powstaje nowy soft?

Tu rozmawialiśmy o aplikacjach polegających na ekosystemie Windowsa i właśnie potwierdziłeś to, o czym mówię. .NET Core nie dawał gwarancji, że ten ekosystem będzie dalej dobrze wspierany i przez to pojawiły się różne obawy przy migracji. Jeżeli gadamy o aplikacjach niepolegających na systemie pod spodem (czyli powiedzmy "proste crudy"), to jasne, że można jechać w Core'a i całą resztę, ale jeżeli coś zależało od systemu (przez integracje z innymi aplikacjami, jakieś comy, uwierzytelnienia czy coś innego), to nagle pojawił się problem.

Aleksander32 napisał(a):

Ja bym na miejscu tworców .NETa wolał mieć więcej potencjalnych klientów. Ale dodam że tu nie chodzi tylko o to że serwery są tańsze, na Linuxie moga być jakieś narzędzia które gorzej działają albo ich nawet na początku nie ma na Windowsie, np. Docker

Oczywiście, to jest duży plus (chociaż póki co część narzędzi działa raczej tylko na Windowsie, ale to drobiazg). Jak jeszcze raz ktoś mi tu zasugeruje, że ja krytykuję wieloplatformowość, to się oddzwonkuję z tego tematu, bo już naprawdę nie chce mi się w kółko tego samego pisać.

0

Jak jeszcze raz ktoś mi tu zasugeruje, że ja krytykuję wieloplatformowość, to się oddzwonkuję z tego tematu, bo już naprawdę nie chce mi się w kółko tego samego pisać.

Nie wiem czy ktoś to zasugerował, na pewno nie byłem to ja. Być może tak mogłes to zrozumieć, ale tego nie sugerowałem.

Jeżeli gadamy o aplikacjach niepolegających na systemie pod spodem (czyli powiedzmy "proste crudy"), to jasne, że można jechać w Core'a i całą resztę, ale jeżeli coś zależało od systemu (przez integracje z innymi aplikacjami, jakieś comy, uwierzytelnienia czy coś innego), to nagle pojawił się problem.

Nie znam .NETu, ale przecież chyba Kafka nie zalezy od systemu, ani REST. Uwierzytelnienie w aplikacji webowej chyba tez nie powinno.

0
Afish napisał(a):

Tak, zgadzam się. Tylko potem punktuję, że to nie jest "darmowe", bo w moim odczuciu (i z mojego doświadczenia) trzeba też znać platformę pod spodem, więc to nie jest tak, że nagle wszystko śmiga na Linuksie, tylko też jest to jakiś koszt po stronie zespołu programistów. Kosztu zespołu administratorów nie uwzględniam, on też tam jest.

Nie twierdzę, że Linuks jest darmowy, tylko że teraz można tak ciąć koszty. I to w sposób przezroczysty dla programistów.

I pointa jest taka — ja nie wiem, jak duży jest to zysk dla biznesu, ale jeżeli jest on naprawdę znaczący, to czy wybranie C# lata temu nie było błędem i może nie powinno się iść w Javę + Linuksa od samego początku?

No może patrząc z przyszłości to wszystko było błędem, ale w danym momencie mogło nie być. Jeśli firma ma 100 ludzi znających .NET, to taniej jej było kontynuować w tej technologii niż nagle wszystkich zwolnić albo przekwalifikować.
Poza tym często decyzji o wyborze technologii dokonują założyciele firmy. Oczywiście można im po latach mówić, że popełnili błąd, ale obstawiam, że będzie im bardzo z tego powodu wszystko jedno.
No i czemu w Javę, a nie w PHP?

Używasz słów, które nie mają jasnej definicji. Czym jest "bajer w języku"? Czy pętla jest bajerem (wszak goto wystarczy)? Czy async jest bajerem (Java nie ma i żyje)? Oba te elementy są zaoszczędzeniem "kilku linijek kodu", ale mają wymierny zysk mierzony w pieniądzach wynikający z przyspieszenia działania aplikacji i skróceniu czasu jej implementowania.

No bardzo dobre przykłady bajerów (chociaż ja bym użył LINQ zamiast pętli, to zdecydowanie bardziej skraca kod i implementację). No i pytanie, czy HKT są równie bajeranckie i pozwolą równie przyspieszyć development i aplikację?
Ile osób będzie umiało i chciało z tego korzystać? Z moich obserwacji wynika, że 25% ludzi, którzy używają HKT umiałoby w ogóle cokolwiek w C# napisać, a kolejne 25% nie może pojąć dotnetowego spójnego systemu typów. Obserwacji odwrotnych, tzn. o pożądaniu HKT wśród programistów .NET nie zauważyłem.
Umiałbyś uzasadnić, że dzięki HKT można byłoby ściąć koszty bardziej niż wieloplatformowością?

Pamiętam, jak kontrowersyjne było wprowadzenie inferencji typów i var. Jeszcze kilka lat później potrafili jeździć po konferencjach i bezwstydnie przekonywać, że to zło w czystej postaci.

Ponownie, ja nie neguję wartości dodanej. Ja sugeruję, że mogła być ona jeszcze większa, tylko źle się do tego zabrano. Nawet lekko parafrazując Twój argument — jeżeli "bajery w języku" nie dają wartości biznesowej, to dlaczego skupiano się na dodawaniu nullable references, a nie na szybszym wsparciu assembly .NET Frameworka bezpośrednio na .NET Corze?

Może dlatego, że problemów z nullem doświadczył każdy programista, i często były to czasochłonne (a więc kosztowne) problemy?

Większy dostęp do bibliotek, wsparcie dla aplikacji desktopowych, możliwość całkowitego przeniesienia aplikacji javowej na dotnet i zysk wydajności (a w efekcie oszczędność kasy).

Ale kto by chciał javowych bibliotek na dotnecie używać?
I jaki MS miałby z tego zysk?
Zresztą oni już nawet kiedyś się Javą nadmiernie interesowali, efektem były procesy z Sunem.

Używanie systemowego muteksa nie jest żadnym "pisaniem na system", nie jest też nim czytanie z plików i pisanie do nich, albo komunikacja po sieci. Nie jest też nim analizowanie wydajności aplikacji, robienie zrzutów pamięci i profilowanie, a te rzeczy też się różnią między Windowsem a Linuksem.

Pisanie do plików jest ukrywane przez abstrakcje, analizowanie wydajności robią odpowiednie narzędzia, dla których nie ma znaczenia, na czym aplikacja jest hostowana.

Afish napisał(a):

Tu rozmawialiśmy o aplikacjach polegających na ekosystemie Windowsa i właśnie potwierdziłeś to, o czym mówię. .NET Core nie dawał gwarancji, że ten ekosystem będzie dalej dobrze wspierany i przez to pojawiły się różne obawy przy migracji.

Te obawy były w 2016/2017 roku. Mamy 2021. Owszem, pewnie wciąż istnieją organizacje, które się boją, podobnie jak niektóre wciąż się boją MVC i tkwią w WebFormsach.

Jeżeli gadamy o aplikacjach niepolegających na systemie pod spodem (czyli powiedzmy "proste crudy"),

No, przynajmniej wreszcie mamy definicję cruda, na którą czekaliśmy od lat. ;)

to jasne, że można jechać w Core'a i całą resztę, ale jeżeli coś zależało od systemu (przez integracje z innymi aplikacjami, jakieś comy, uwierzytelnienia czy coś innego), to nagle pojawił się problem.

Nie ma problemu, po prostu tej aplikacji/serwisu się nie migruje. Zysk jest z migracji stu innych.

1

@somekind:

Ile osób będzie umiało i chciało z tego korzystać? Z moich obserwacji wynika, że 25% ludzi, którzy używają HKT umiałoby w ogóle cokolwiek w C# napisać, a kolejne 25% nie może pojąć dotnetowego spójnego systemu typów. Obserwacji odwrotnych, tzn. o pożądaniu HKT wśród programistów .NET nie zauważyłem.

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.
A co braku pożądania HKT wśród .NET - to normalne. Programistom Go niepotrzebne generyki. A JavaScryptowcom do niczego nie potrzebne typy. Jak pisałem w Basicu na C64 to i bez procedur się obywałem i nawet nie wiedziałem, że mi ich brakuje :P

W tym kontekście przypomina mi się przykład od Tonego Morrisa https://vimeo.com/90738761 - przewiń do 28:39 (olej monady i sorry za jakość - nie mam siły szukać lepszej wersji). To tylko analogia - nie jest o HKT.
The listreverse project is doing fine...

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

1

Oprócz HKT Scala oferuje jeszcze inne mechanizmy związane z typami, jak np compound types https://docs.scala-lang.org/tour/compound-types.html (w Scali 3 odpowiednikiem są intersection types http://dotty.epfl.ch/docs/reference/new-types/intersection-types.html ), type members: https://docs.scala-lang.org/tour/abstract-type-members.html (hobbystycznie często używam, w pracy rzadziej). Scala 3 dodaje jeszcze union types http://dotty.epfl.ch/docs/reference/new-types/union-types.html , type lambdas http://dotty.epfl.ch/docs/reference/new-types/type-lambdas.html , match types http://dotty.epfl.ch/docs/reference/new-types/match-types.html itp itd

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.

Weźmy dla przykładu JavaScript czy TypeScript. Nie ma tam przeciążania metod, ale można to zaemulować za pomocą ifologii czasu wykonania.
https://github.com/snabbdom/snabbdom/blob/master/src/package/h.ts

export function h (sel: string): VNode
export function h (sel: string, data: VNodeData | null): VNode
export function h (sel: string, children: VNodeChildren): VNode
export function h (sel: string, data: VNodeData | null, children: VNodeChildren): VNode
export function h (sel: any, b?: any, c?: any): VNode {
  var data: VNodeData = {}
  var children: any
  var text: any
  var i: number
  // tu zaczyna się ifologia emulująca przeciążanie metod
  if (c !== undefined) {
    if (b !== null) {
      data = b
    }
    if (is.array(c)) {
      children = c
    } else if (is.primitive(c)) {
      text = c
    } else if (c && c.sel) {
      children = [c]
    }
  } else if (b !== undefined && b !== null) {
    if (is.array(b)) {
      children = b
    } else if (is.primitive(b)) {
      text = b
    } else if (b && b.sel) {
      children = [b]
    } else { data = b }
  }
  // tu zakończyła się ifologia emulująca przeciążanie metod
  if (children !== undefined) {
    for (i = 0; i < children.length; ++i) {
      if (is.primitive(children[i])) children[i] = vnode(undefined, undefined, undefined, children[i], undefined)
    }
  }
  if (
    sel[0] === 's' && sel[1] === 'v' && sel[2] === 'g' &&
    (sel.length === 3 || sel[3] === '.' || sel[3] === '#')
  ) {
    addNS(data, children, sel)
  }
  return vnode(sel, data, children, text, undefined)
};

Jak widać język nie musi oferować sensownego przeciążania metod by osiągnąć popularność. JS i TS trzymają się bardzo dobrze na rynku. Obstawiam też, że tego typu brak nie jest tematem nieustannych żali. Każdy się dostosowuje do tego co oferuje język. Jeżeli w C# da się rozwiązać jakiś problem orając generyki refleksją czasu wykonania, a w Scali ten sam problem można ogarnąć zaawansowanymi typami i innymi mechanizmami czasu kompilacji to wybiera się rozwiązania dopasowane do języka.

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.

Inne przykład to receivery w Kotlinie. Czasami na forum Scali zdarzają się ludzie, którzy bardzo mocno lobbują za wstawieniem takiego mechanizmu do Scali. Twierdzą, że taki mechanizm totalnie zmienia ich życie i że Scala musi go mieć by nie być w tyle za Kotlinem. Jak do tej pory nie ma wprost analogicznego mechanizmu w Scali. Są inne, którymi można rozwiązać podobne problemy, ale wprost receiverów w Scali nie ma.

1
somekind napisał(a):

Nie twierdzę, że Linuks jest darmowy, tylko że teraz można tak ciąć koszty. I to w sposób przezroczysty dla programistów.

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.

somekind napisał(a):

No może patrząc z przyszłości to wszystko było błędem, ale w danym momencie mogło nie być. Jeśli firma ma 100 ludzi znających .NET, to taniej jej było kontynuować w tej technologii niż nagle wszystkich zwolnić albo przekwalifikować.

Prawdopodobnie tak.

somekind napisał(a):

No i czemu w Javę, a nie w PHP?

Może być i PHP.

somekind napisał(a):

No bardzo dobre przykłady bajerów (chociaż ja bym użył LINQ zamiast pętli, to zdecydowanie bardziej skraca kod i implementację). No i pytanie, czy HKT są równie bajeranckie i pozwolą równie przyspieszyć development i aplikację?
Ile osób będzie umiało i chciało z tego korzystać? Z moich obserwacji wynika, że 25% ludzi, którzy używają HKT umiałoby w ogóle cokolwiek w C# napisać, a kolejne 25% nie może pojąć dotnetowego spójnego systemu typów. Obserwacji odwrotnych, tzn. o pożądaniu HKT wśród programistów .NET nie zauważyłem.
Umiałbyś uzasadnić, że dzięki HKT można byłoby ściąć koszty bardziej niż wieloplatformowością?

Nie, nie umiem na to odpowiedzieć. Rzuciłeś anegdotyczne procenty, do których odnieść się nie mogę. 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.

somekind napisał(a):

Pamiętam, jak kontrowersyjne było wprowadzenie inferencji typów i var. Jeszcze kilka lat później potrafili jeździć po konferencjach i bezwstydnie przekonywać, że to zło w czystej postaci.

To pytanie, czy ci sami ludzie potem ochoczo przenieśli się na .NET Core'a.

somekind napisał(a):

Może dlatego, że problemów z nullem doświadczył każdy programista, i często były to czasochłonne (a więc kosztowne) problemy?

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.

somekind napisał(a):

Ale kto by chciał javowych bibliotek na dotnecie używać?

No przecież ludzie używają IKVM.

somekind napisał(a):

I jaki MS miałby z tego zysk?

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?

somekind napisał(a):

Zresztą oni już nawet kiedyś się Javą nadmiernie interesowali, efektem były procesy z Sunem.

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.

somekind napisał(a):

Pisanie do plików jest ukrywane przez abstrakcje, analizowanie wydajności robią odpowiednie narzędzia, dla których nie ma znaczenia, na czym aplikacja jest hostowana.

Oprócz tego, że niektórych narzędzi dotnetowych nie uruchomisz na Linuksie. Pisanie do plików jest tak ukryte przez abstrakcję, że przy wychodzeniu z aplikacji leci race condition.

somekind napisał(a):

Te obawy były w 2016/2017 roku. Mamy 2021. Owszem, pewnie wciąż istnieją organizacje, które się boją, podobnie jak niektóre wciąż się boją MVC i tkwią w WebFormsach.

Były wtedy, były pewnie i później. To jest moje meritum, że te obawy w ogóle wystąpiły i to spowolniło rozwój.

somekind napisał(a):

No, przynajmniej wreszcie mamy definicję cruda, na którą czekaliśmy od lat. ;)

Było zapytać parę lat temu, nie musiałbyś czekać ;)

somekind napisał(a):

Nie ma problemu, po prostu tej aplikacji/serwisu się nie migruje. Zysk jest z migracji stu innych.

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?

1
jarekr000000 napisał(a):

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.

Wibowit napisał(a):

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.

Afish napisał(a):

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

1
somekind napisał(a):

Mechanizm potrzebny raz w miesiącu nie wygląda na coś niezbędnego.

To chyba można odnieść do spanów i memory.

somekind napisał(a):

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.

Jeżeli to jest prawda, to dobrze. Jak robiłem to przy wersji 2.1, to była to droga przez mękę, no ale ja już odszedłem z dotneta.

somekind napisał(a):

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 i zasadnym jest pytanie, czy warto było w to inwestować? Moim zdaniem nie.

somekind napisał(a):

Serio? Gdzie i po co? Komercyjnie?
Jaki odsetek firm/programistów dotneta to robi?

A jaki odsetek potrzebował spana i memory? Jaki odsetek potrzebował asynca? To jest wejście na potężny rynek, jeżeli dotnet umiałby w JVM, to nagle dałoby się na przykład odpalić scala.js. To, że "tego nie trzeba" nie oznacza, że nie byłoby to przydatne. No i dałoby to też możliwość odpalania kilku sensownych języków na dotnecie, na którym rządzi C# (który z jednej strony jest skomplikowany, a z drugiej ubogi).

somekind napisał(a):

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.

A wiele osób było na początku zainteresowanych rubym na dotnecie? Albo pythonem?

somekind napisał(a):

Spoko, następnym razem jak będę potrzebował jakieś definicji bez nadmiernego związku z rzeczywistością, to się odezwę. :P

Spoko, daj adres email, to podeślę CV i pogadamy o tym godzinę (czy ile tam zajmuje Ci zweryfikowanie kandydata) ;)

somekind napisał(a):

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

No właśnie, nie migruję z Windowsa, to dostałem tylko lukier (kwestia gustu), spany/memory (pewnie nigdy nie użyję, wszak nawet nie muszę wiedzieć, na czym odpalam aplikację), nullable references (które niespecjalnie rozwiązują problem), no i trochę zwiększonej prędkości. Nie mówię, że to źle, ale wydaje mi się, że w 5 lat dałoby się lepiej.

0
Afish napisał(a):

To chyba można odnieść do spanów i memory.

No chyba można. Czyli chciałbyś mieć w C# mechanizm równie zbędny co spany i memory? To teraz brzmi jakby jeszcze mniej przekonująco niż wcześniej.

Jeżeli to jest prawda, to dobrze. Jak robiłem to przy wersji 2.1, to była to droga przez mękę

No w sumie, to o tym, co przed 3.0 było, to nie wiem, bo u mnie był zakazany.

no ale ja już odszedłem z dotneta.

No to powiem Ci, że to wyjątkowo nieudane odejście. :P

No i zasadnym jest pytanie, czy warto było w to inwestować? Moim zdaniem nie.

Moim zdaniem również nie.
Zresztą moim zdaniem w ogóle nie ma sensu inwestować w C#, najlepiej gdyby został jako dziwny język przejścia z XIX do XXI wieku, z jego wszystkimi zbędnymi czy nieudanymi mechanizmami jak wskaźniki czy dynamic, żeby sobie mogli muteksować na COMach ci, którzy tego potrzebują. A dla całej reszty, którzy te "proste crudy" klepią przydałby się znacznie normalniejszy język.

No, ale to jest moje zdanie i moje marzenia. :(

A jaki odsetek potrzebował spana i memory? Jaki odsetek potrzebował asynca?

Asynca to chyba całkiem spory. No i to jest bajer, który ma chyba aspekt biznesowy.

To jest wejście na potężny rynek, jeżeli dotnet umiałby w JVM, to nagle dałoby się na przykład odpalić scala.js. To, że "tego nie trzeba" nie oznacza, że nie byłoby to przydatne. No i dałoby to też możliwość odpalania kilku sensownych języków na dotnecie, na którym rządzi C# (który z jednej strony jest skomplikowany, a z drugiej ubogi).

No i chyba właśnie dlatego byłby to strzał w stopę, na dodatek kosztowny. To być może ma sens techniczny, ale żaden inny.

A wiele osób było na początku zainteresowanych rubym na dotnecie? Albo pythonem?

Pojęcia nie mam. Mam niestety zbyt ubogą wyobraźnię, żeby wyobrazić sobie, że ktoś tego kiedykolwiek na poważnie użył.

Nie mówię, że to źle, ale wydaje mi się, że w 5 lat dałoby się lepiej.

Tylko to jest taki najbanalniejszy truizm. Zawsze dałoby się zrobić lepiej, więcej albo taniej.

1
somekind napisał(a):

No chyba można. Czyli chciałbyś mieć w C# mechanizm równie zbędny co spany i memory? To teraz brzmi jakby jeszcze mniej przekonująco niż wcześniej.

Ale to Ty uznajesz moje mechanizmy za zbędne. Z HKT (który jest tylko jednym z mechanizmów) mogą korzystać programiści "crudów", a ze spanów raczej nie.

somekind napisał(a):

Moim zdaniem również nie.
Zresztą moim zdaniem w ogóle nie ma sensu inwestować w C#, najlepiej gdyby został jako dziwny język przejścia z XIX do XXI wieku, z jego wszystkimi zbędnymi czy nieudanymi mechanizmami jak wskaźniki czy dynamic, żeby sobie mogli muteksować na COMach ci, którzy tego potrzebują. A dla całej reszty, którzy te "proste crudy" klepią przydałby się znacznie normalniejszy język.

No dobra, skoro wolisz ironizować.

somekind napisał(a):

Asynca to chyba całkiem spory. No i to jest bajer, który ma chyba aspekt biznesowy.

Async nie był potrzebny, bo nie dodawał nic, czego nie dało się zrobić wcześniej. Owszem, upraszczał trochę rzeczy, ale też wymagał dużych i wieloletnich inwestycji wszystkich zainteresowanych, bo trzeba było praktycznie każdą biblioteczkę przerobić, a ile przy tym deadlocków ludzie dostali, to brak słów.

somekind napisał(a):

No i chyba właśnie dlatego byłby to strzał w stopę, na dodatek kosztowny. To być może ma sens techniczny, ale żaden inny.

No cóż, to będę cierpliwie czekał, aż Microsoft znowu zrobi jakiś strzał w stopę pisząc kolejny framework do desktopów.

somekind napisał(a):

Pojęcia nie mam. Mam niestety zbyt ubogą wyobraźnię, żeby wyobrazić sobie, że ktoś tego kiedykolwiek na poważnie użył.

No jak myślisz, że nikt nie używał ruby'ego, pythona, albo IKVM-a na produkcji, to rzeczywiście moje propozycje rozwoju mogą wydawać się absurdalne.

somekind napisał(a):

Tylko to jest taki najbanalniejszy truizm. Zawsze dałoby się zrobić lepiej, więcej albo taniej.

Wystarczyło nie robić nullable references, a kasę w to władowaną przeznaczyć na rozwój GC, żeby wreszcie wyciągnąć porządny interfejs, sensowną implementację i wejść w obszar sparka. Albo w JIT-a, żeby dotnet umiał inline'ować gettery.

1
Afish napisał(a):

Ale to Ty uznajesz moje mechanizmy za zbędne. Z HKT (który jest tylko jednym z mechanizmów) mogą korzystać programiści "crudów", a ze spanów raczej nie.

Dobra, nie zrozumiałem Twojego poprzedniego posta.

No dobra, skoro wolisz ironizować.

Nie ironizuję, serio uważam, że potrzebny jest nowy język, bo C# ma zbyt wiele długu w sobie.

No jak myślisz, że nikt nie używał ruby'ego, pythona, albo IKVM-a na produkcji, to rzeczywiście moje propozycje rozwoju mogą wydawać się absurdalne.

Może ktoś używał, Ja się z tym po prostu nie spotkałem, nie widziałem w żadnych wymaganiach, itd. Dla mnie istnienie tego to tylko jakaś ciekawostka.

1
somekind napisał(a):

Nie ironizuję, serio uważam, że potrzebny jest nowy język, bo C# ma zbyt wiele długu w sobie.

Okej. Ja bym się z tym nawet zgodził i to trochę zahacza o mój żal, że w ekosystemie skupiono się na C# (na przykład cukier składniowy), a nie rozwija się za bardzo CLR-a, przez co w F# też nie da się robić HKT po ludzku albo innych zabawek.

somekind napisał(a):

Może ktoś używał, Ja się z tym po prostu nie spotkałem, nie widziałem w żadnych wymaganiach, itd. Dla mnie istnienie tego to tylko jakaś ciekawostka.

Najwyraźniej ja mam inny przegląd dotneta od Ciebie, więc z tego pewnie bierze się nasz rozjazd. Ja widziałem IKVM na produkcji, widziałem IronPythona (o IronRuby kiedyś słyszałem), do tego robiłem chyba wszystko, co da się na dotnecie 1, więc dla mnie takie rzeczy są czymś "normalnym" (aczkolwiek nie "powszechnym").

[1] COM-y, niskie haki, desktopy, mobilne, web, jakieś wtyczki do natywnych aplikacji, IKVM, IronPython, zrzuty pamięci, wycieki pamięci, deadlocki, C++/CLI, RPi, hostowanie PowerShella, P/Invoke.

1
Afish napisał(a):

Najwyraźniej ja mam inny przegląd dotneta od Ciebie, więc z tego pewnie bierze się nasz rozjazd.

No, niewątpliwie. Ośmielę się zaryzykować stwierdzenie, że Twój jest bardziej oryginalny, a mój bardziej mainstreamowy. A to, co robi MS będzie raczej zmierzało ku mainstreamowi, a nie oryginałom.

Ja widziałem IKVM na produkcji, widziałem IronPythona (o IronRuby kiedyś słyszałem), do tego robiłem chyba wszystko, co da się na dotnecie 1, więc dla mnie takie rzeczy są czymś "normalnym" (aczkolwiek nie "powszechnym").

A kiedy Ty to IKVM na produkcji widziałeś? Bo jak tak patrzę - strona nieaktualizowana od 2014, na GH niby coś jest w miarę świeżego (20 miesięcy) z trzema kontrybutorami i 16 commitami. No nie wygląda to jak coś pożądanego przez społeczność.
IronPython - stabilna wersja sprzed paru miesięcy sugeruje, że jest to ta wersja Pythona, która już jest martwa. Ta niemartwa jest dopiero tworzona.
IronRuby jest martwe od 10 lat?

[1] COM-y, niskie haki, desktopy, mobilne, web, jakieś wtyczki do natywnych aplikacji, IKVM, IronPython, zrzuty pamięci, wycieki pamięci, deadlocki, C++/CLI, RPi, hostowanie PowerShella, P/Invoke.

No ja robiłem tylko desktopy (czasami wołając WinAPI, gdy WinFormsy nie dawały sobie rady), mobilne, web i P/Invoke. Wycieków pamięci i deadlocków nie robiłem, jakoś tak się nie złożyło.

1
somekind napisał(a):

A kiedy Ty to IKVM na produkcji widziałeś? Bo jak tak patrzę - strona nieaktualizowana od 2014, na GH niby coś jest w miarę świeżego (20 miesięcy) z trzema kontrybutorami i 16 commitami. No nie wygląda to jak coś pożądanego przez społeczność.

Ostatnia wersja ze starej linii była chyba pod koniec 2015 roku, jeszcze w 2017 go widziałem na prodzie, czyli mnie więcej w okresie wymierania Frameworka i narodzin Core'a.

somekind napisał(a):

IronPython - stabilna wersja sprzed paru miesięcy sugeruje, że jest to ta wersja Pythona, która już jest martwa. Ta niemartwa jest dopiero tworzona.

Tak, Python 2 umarł jakoś w zeszłym roku, to i Iron Python musiał odejść.

somekind napisał(a):

IronRuby jest martwe od 10 lat?

A nie wiem, tym się nie interesowałem.

1 użytkowników online, w tym zalogowanych: 0, gości: 1