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.