Przejście z Javy ->C# .NET

0

Podczas mojej kariery dane mi było parę miesięcy klepać testy w C# jako SQA.( na początku, jak brałem co się da, byle załapać robotę). Teraz mam 3 lata doświadczenia w Javie enterprajzowej. Spring, Hibernate, typowo pod webówkę.

Co mnie boli w Javie? Co bym chciał? A co mam wrażenie że w C# jest lepsze:

Część rzeczy i rozwiązań, przynajmniej z wierzchu, podobała mi się bardziej w C# - jedno IDE, jedno rozwiązanie do danego problemu, brak pierdyliarda bibliotek do trywialnych rzeczy. Po prostu lubię jak jest Ordnung. Mniejsze ryzyko że Junior albo Hindus coś zepsują bo nie wiedzieli o jakimś pitfallu. Łatwiej też czyta się kod, którego zasady są spójniejsze/uniewersalne. Brak pokusy ze strony pracodawcy "o, od jutra przechodzimy na jakiś inny język JVM".

"write once, run everywhere", niespecjalnie mnie raduje. Dla mnie osobiście koniec dnia liczy się to ile mi ktoś zapłaci, jaki będzie komfort pracy, i czy jestem elastyczny pod względem zmiany pracy/zamieszkania.

Czy jest sens przechodzić z jednego języka na drugi? A dokładniej: Jak teraz rokuje C#? Czy moje wyobrażenia o porządku w projektach .NET są przesadzone?

1

To teraz masz dwa IDE, a nawet trzy jak się uprzesz(VSC) :-) hindusów coraz więcej, zmiana języka to chyba największy atut JVM :-) Projekt ma taki porządek o jaki zadbają ludzie którzy go tworzą oraz nadzorują tworzenie :-) Taka prawda. Poza tym nie wiadomo co tam się w przyszłości wydarzy jak M$ zmieni kierunek rozwoju platformy bo mimo tego że jest open source to zdecydowana większość kontrybucji idzie od jego pracowników :-) Oczywiście możesz spróbować :-)

3

Część rzeczy i rozwiązań, przynajmniej z wierzchu, podobała mi się bardziej w C# - jedno IDE

Do Javy jest jedno porządne IDE - IntelliJ IDEA. Reszta to plankton, podobnie jak Visual Studio Code (w którym można też klepać w Javie) czy inne wynalazki.

0
Aryman1983 napisał(a):

To teraz masz dwa IDE, a nawet trzy jak się uprzesz(VSC) :-) hindusów coraz więcej, zmiana języka to chyba największy atut JVM :-) Projekt ma taki porządek o jaki zadbają ludzie którzy go tworzą oraz nadzorują tworzenie :-) Taka prawda. Poza tym nie wiadomo co tam się w przyszłości wydarzy jak M$ zmieni kierunek rozwoju platformy bo mimo tego że jest open source to zdecydowana większość kontrybucji idzie od jego pracowników :-) Oczywiście możesz spróbować :-)

Niestety kolego, ale bardzo się mylisz. 87% kontrybutorow nie pracuje w Microsoft.
https://dotnetfoundation.org/[...]et-foundation-open-membership

0

Dla mnie pomysł bez sensu. Lepiej zglebiac jave, może czas na Scale? Wciaz rynek javovy jest wiekszy i wiecej w nim pieniedzy.

1
error91 napisał(a):
Aryman1983 napisał(a):

To teraz masz dwa IDE, a nawet trzy jak się uprzesz(VSC) :-) hindusów coraz więcej, zmiana języka to chyba największy atut JVM :-) Projekt ma taki porządek o jaki zadbają ludzie którzy go tworzą oraz nadzorują tworzenie :-) Taka prawda. Poza tym nie wiadomo co tam się w przyszłości wydarzy jak M$ zmieni kierunek rozwoju platformy bo mimo tego że jest open source to zdecydowana większość kontrybucji idzie od jego pracowników :-) Oczywiście możesz spróbować :-)

Niestety kolego, ale bardzo się mylisz. 87% kontrybutorow nie pracuje w Microsoft.
https://dotnetfoundation.org/[...]et-foundation-open-membership

Ciekawe, ciekawe. Przejrzałem kilka projektów z https://github.com/dotnet i ludzi, którzy tam pchają kod. Znalazłem całego jednego, który w profilu nie ma wpisane Microsoft[email protected] https://github.com/brthor
https://github.com/orgs/dotnet/people - tutaj sprawa ma się nieco inaczej. Jest kilka sztuk ale ich aktywność jest mocno znikoma. Więc gdzie te 87%?

0

Nie miałbym z tym raczej problemu, jeżeli C# rozwija głównie Microsoft. Zmiany języka VM na np. Scalę też nie widzę jako atut, wolę jednak jeden język. W razie czego, można wtedy zamienić pracę na inną z tego ekosystemu łatwiej.

0

Przejście z Javy ->C# .NET

Lepiej późno niż wcale.

11
BluzaWczolg napisał(a):

Część rzeczy i rozwiązań, przynajmniej z wierzchu, podobała mi się bardziej w C# - jedno IDE, jedno rozwiązanie do danego problemu, brak pierdyliarda bibliotek do trywialnych rzeczy.

Za to jest druga skrajność - wielu tzw. programistów a także korporacji jest bardzo przywiązana do rozwiązań dostarczanych przez Microsoft i często nie chce używać lepszych narzędzi rozwijanych przez społeczność.

Mniejsze ryzyko że Junior albo Hindus coś zepsują bo nie wiedzieli o jakimś pitfallu.

Hindusów jest niestety pod dostatkiem.
Ale zaletą dla Ciebie może być, że większość z nich w C# pisze właściwie w Javie. (Equals zamiast ==, String, Object, klamerki bez entera, nadmiarowe nawiasy przy konstruktorach mimo użycia inicjalizatora obiektu... niby to wszystko się kompiluje, ale wygląda obrzydliwie.)

Łatwiej też czyta się kod, którego zasady są spójniejsze/uniewersalne.

To spójrz na to:

class Test
{
    private int _number;

    public int Number
    {
        get { return _number; }
    }

    public Test(int number)
    {
        _number = number;
    }

    public int SquareMethod()
    {
        return _number * _number;
    }

    public int SquareProperty
    {
        get { return _number * _number; }
    }

    public override string ToString()
    {
        return _number.ToString();
    }

    public int DoSomethingComplex(int x)
    {
         int z = n + n;
         return z + x;
    }
}

oraz na to:

class Test
{
    public int Number { get; }
    public Test2(int number) => Number = number;
    public int SquareProperty => Number * Number;
    public int SquareMethod() => Number * Number;
    public override string ToString() => Number.ToString();

    public int DoSomethingComplex(int x)
    {
         int z = n + n;
         return z + x;
    }    
}

Te klasy są sobie równoważne, a zapis jest raczej niespójny. DoSomethingComplex w drugiej klasie pasuje jak pięść do oka. No, ale nie da się inaczej jeśli metoda ma więcej niż jedną linijkę. Tak to jest, jak tworzy się język bazujący na klamerkach, a potem próbuje je usuwać. W drugiej klasie można się nieźle pomylić zapominając dodać nawiasy za nazwą SquareMethod - a to jedyne, co w tym podejściu odróżnia metodę od właściwości.

Jeszcze gorzej, gdy w projekcie trafi się szajbus, który zamiast po ludzku:

var numQuery = numbers.Where(num => num % 2 == 0).OrderBy(n => n);

pisze po "nowoczesnemu":

var numQuery =
    from num in numbers
    where num % 2 == 0
    orderby num
    select num;

Wydaje mi się, że z uwagi na (niekoniecznie sensowne) bogactwo składni, w C# trzeba bardziej pilnować spójności i więcej jest konwencji do ustalenia niż w Javie.

Główną zaletą C# jest to, że kompilator w nim działa, i jest co do zasady statycznie typowany, ale jeśli bardzo się chce użyć dynamicznego typowania, to trzeba jawnie deklarować zmienne jako dynamic. Nie ma takich cudów jak w Javie, żeby osiągnąć runtime error niekompatybilności mimo deklarowania rzekomo statycznych typów.

Brak pokusy ze strony pracodawcy "o, od jutra przechodzimy na jakiś inny język JVM".

Jakoś nie wierzę, żeby ktoś gdzieś nagle wpadał na pomysł zmiany języka w trakcie trwania projektu.

Czy jest sens przechodzić z jednego języka na drugi? A dokładniej: Jak teraz rokuje C#?

Rynek jest mniejszy niż w Javie, ale jest też mniej chętnych. Dzięki Core rynek się może się tylko zwiększać.

Czy moje wyobrażenia o porządku w projektach .NET są przesadzone?

Przez jakieś 10 lat w tej branży wybitnie porządnego projektu jeszcze nie widziałem, chociaż jeden był całkiem niezły. Ale nie sądzę, żeby to się drastycznie różniło od innych technologii.

2

Główną zaletą C# jest to, że kompilator w nim działa, i jest co do zasady statycznie typowany, ale jeśli bardzo się chce użyć dynamicznego typowania, to trzeba jawnie deklarować zmienne jako dynamic. Nie ma takich cudów jak w Javie, żeby osiągnąć runtime error niekompatybilności mimo deklarowania rzekomo statycznych typów.

Podaj przykłady na te niekompatybilności.

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