Czy .NET to szwajcarski scyzoryk?

0

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/ref[...]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/s[...]/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.

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

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

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

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

0
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: 0, botów: 1

Robot: CCBot