Czy .NET to szwajcarski scyzoryk?

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.

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.

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

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/grou[...]d/permalink/1745205212327493/

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

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

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

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

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.

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.

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