donkey7 napisał(a)
Różnego rodzaju frameworki, np do GUI co jakiś czas się zmieniają chyba. W Javie jest Swing od bardzo dawna i ma się bardzo dobrze.
W .NET do GUI jest WinForms, już od 10 lat. Doszło parę nowych kontrolek 5 lat temu, od tamtej pory chyba nic nowego, co najwyżej pojedyncze metody czy usprawnienia.
Parę lat temu wpadli na pomysł WPF, czyli konfiguracji GUI w formie XML, niby to promują, ale jakoś nikt nie chce korzystać. Czyżby przez mułowatość? ;) Daje to spore możliwości i ułatwienia, może kiedyś zdobędzie popularność, ale na razie WF na desktopach rządzą.
Generalnie dodawane są nowe klasy i frameworki, jak np. dwa ORMy (LINQ to SQL i Entity Framework), ale nikt nie uznał np. DataSetów czy modelu połączeniowego jako przestarzały. (A szkoda, bo DS to syf straszny akurat). Doszło ASP.NET MVC, ale nikt nie odrzuca WebForms.
Są w .NET jakieś klasy i metody "depreciated", ale to raczej sporadyczne przypadki. Trzeba się naprawdę postarać by na takie trafić.
Więc chyba trochę na wyrost napisałeś. ;)
- słowo kluczowe yield - czy może posłużyć do stworzenia dowolnego rodzaju kolekcji?
A cholera wie, nigdy nie używałem.
- propertiesy są trochę bez sensu, w Scali wszystko ma akcesory z automatu, można je ewentualnie dopisać. Skoro w C# dodali specjalną składnię to mogła ona choć trochę przypominać tą z Scali,
W każdym razie propertisy mają większy sens niż metody get*, set* z C++ czy Javy (to chyba lepsze języki do porównywania). Metoda to raczej powinna wykonywać bardziej skomplikowaną operację niż zmiana stanu pola.
- LINQ jest wielkim kawałem wspawanej logiki w kompilator, w Scali identyczną funkcjonalność można osiągnąć pisząc bibliotekę (np Squeryl), którą można potem dowolnie rozszerzyć na różne typy zbiorów danych,
Nie rozumiem "wspawania logiki w kompilator". LINQ to klasy z metodami rozszerzającymi pozwalającymi operować na kolekcjach przy użyciu lambdy. Zarąbista sprawa, nie trzeba już pisać milionów pętli z milionami ifów do sortowania, filtrowania czy przeszukiwania kolekcji, wszystko da się osiągnąć ładnym, łańcuchowym wywołaniem metod.
Chodzi Ci o słowa kluczowe i składnię from - where - select? Jak sądzę kompilator zamienia to tylko na wywołania metod. Dla mnie taka składnia jest obrzydliwa, ale może komuś pasuje.
Zresztą - same metody rozszerzające są wystarczająco zajebistym pomysłem, żeby przyćmić wszystkie wady. ;)
- collection initializers - czy działają dla dowolnych, także własnych, kolekcji?
Z tego, co się orientuję, to jak najbardziej.
- nadpisywanie metod to już czysty idiotyzm wg mnie (tzn new function czy coś takiego), w języku obiektowym wszystko powinno być wirtualne,
Zachowanie metody new jest nieco inne niż override w sytuacji gdy obiekt klasy potomnej przypisujemy do zmiennej typu klasy bazowej. Może i masz rację, nie zastanawiałem się nigdy nad takim niuansem. A czemu tak uważasz?
- poza tym daleko C# do Scali pod względem np elastyczności, rozszerzalności, zwięzłości itp
O ile się orientuję, to Scala jest po pierwsze młodsza, po drugie funkcyjna, więc nie wiem czy jest sens porównywać ją składniowo z C#.
Co do cukru - właściwości, słówko kluczowe var, LINQ - to wszystko po to, żeby kodu było mniej. Im mniej kodu tym jest on czytelniejszy (sensownego kodu, oczywiście), tym łatwiej go utrzymać. IMHO to ma sens.
W ogóle rozwój ma sens, np. w następnej wersji języka metody będzie można oznaczać modyfikatorem async, przy ich wywołaniu trzeba będzie używać operatora await, dzięki czemu nie trzeba będzie uzywać callbacków i napisać asynchroniczny kod przy zachowaniu niemalże nienaruszonej struktury synchronicznego kodu. Może i cukier, ale jaki praktyczny.