Jaki język programowania jest przyszłościowy?

Witam. Rok temu skończyłem uczyć się c++ (symfonia c++ do tomu 2) i zacząłem uczyć się javy. Dręczy mnie pytanie czy programowanie w javie na windowsa czy osx to dobre rozwiązanie? W sumie kod javy można odpalić na każdym systemie pod warunkiem zainstalowania środowiska, a programy z c++ tylko na windowsie.
Ewentualnie w jakim innym języku można programować na windowsa

programy z c++ tylko na windowsie wierutne kłamstwo.
Ewentualnie w jakim innym języku można programować na windowsa łatwiej zapytać w jakim się nie da.

programy z c++ tylko na windowsie od kiedy? o_O A myślisz że JVM to w czym jest napisany, że można potem Javę odpalać pod innymi systemami? :D

Dobra z c++ zostałem wprowadzony w błąd :)
Programowanie w javie na windowsa to dobry pomysł czy większość aplikacji jest tworzonych w innym kodzie?
Bo zwróciłem uwagę że jak odpalam jakiś program to mam plik exe a w javie nie stworzę takiego pliku. Pytam się dlatego że na studiach mam jave i mam pomysły na pierwsze programy i chciałbym stworzyć je zgodnie z dobrym "nawykami"

A z ilu desktopowych programów korzystasz na codzień? Kilku? A z ilu aplikacji webowych? Bo takie głownie pisze się w javie.

Przyszłościowe języki to te nowoczesne jak Rust, Go, Swift, Elixir, Vala, oraz te na JVM jak Scala, Kotlin, Ceylon. Ja mam takie nietypowe pytanie czy w Pythonie można napisać kompilator do języka programowania które będzie kompilowany jak C, Pascal? Dlaczego maszynę JVM piszą nadal w C, a nie w czystej Javie? Czy chodzi tu tylko wyłącznie o wydajność.

Odpowiedzi po kolei:

1. Można, wystarczy np. z Pythona wypluwać LLVM-IR a następnie to kompilować do kodu natywnego przy pomocy LLVM. Pytanie po co? To i tak będzie raczej tylko bootstrap bo następna wersja kompilatora już pewnie byłaby napisana w języku, który właśnie stworzyłeś.
2. Java jest kompilowana do IL JVMa. Jak wyobrażasz sobie JVM, który do pracy wymaga JVMa (to jest JIT nie AOT)? Poza tym AFAIK JVM jest napisany w C++ a nie w C.

Dlaczego maszynę JVM piszą nadal w C, a nie w czystej Javie? Czy chodzi tu tylko wyłącznie o wydajność.

Niespecjalnie da się napisać VMkę w języku (nie: dla języka) z automatycznym zarządzaniem pamięcią jeśli tego zarządzania pamięcią się gdzieś po drodze nie zaimplementuje. Od czegoś musi się ten proces odśmiecania pamięci zacząć i to coś samo w sobie GC nie może wymagać (no chyba, że GC jest zaimplementowane sprzętowo jak w porzuconym projekcie: https://en.wikipedia.org/wiki/Intel_iAPX_432 ).

Jednakże jest ciekawy projekt, który będzie pozwalał na oprogramowanie znacznej części JITa w czystej Javie: http://openjdk.java.net/projects/graal/
Skopiuję opis:

The aim of this project is to expose VM functionality via Java APIs. Namely, we want to make it feasible to write in Java a dynamic compiler and interpreter for a language runtime. These components will seamlessly integrate and leverage existing VM infrastructure (e.g., HotSpot).

The design of the dynamic compiler uses features of Java that make it highly extensible such that adding extra IR nodes and/or transformations is straightforward. At the same time, it should produce excellent code quality without compromising compile time and memory usage by the JVM.

Building on the compiler, we aim to develop a multi-language interpreter framework. Java will be just one member in the family of supported languages. The use of partial evaluation will allow the framework to deliver competitive performance.

Sam Graal VM nie jest jeszcze gotowy, ale Java 9 będzie mieć już funkcjonalność, która wykorzystuje Graala: JEP 295: Ahead-of-Time Compilation

Nowoczesne języki funkcyjne, np. F#. Kiedy komputery kwantowe wreszcie zaczną działać wszelkie języki imperatywne pójdą do lamusa bo zmieni się sposób działania procesora. Dodatkowo znajomość takiego języka jest świetną szkoła programowania i myślenia.

"Sam Graal VM nie jest jeszcze gotowy, ale Java 9 będzie mieć już funkcjonalność, która wykorzystuje Graala: JEP 295: Ahead-of-Time Compilation"

Widzę, że Java znowu pozazdrościła .NETowi :) Szkoda tylko że zawsze są parę lat za nim. Najpierw wyrażenia lambda, później generacje GC a teraz wystawione API kompilatora. Kto wie, może za kilka lat zaimplementują LINQ?

1. Weźmy np. desktopowy program do zarządzania pracownikami bez przeszkód mogę go stworzyć w javie czy lepiej stworzyć go np. w c++ czy innym języku
2. @śmieszek piszesz że java pozazdrościła .Net-owi
   O co Ci chodzi? :)
   Przecież .Net to framework niezwiązany z żadnym konkretnym językiem

To konkretnie podam:

W .NET od zawsze były generacje GC (GC działą na poziomie maszyny wirtualnej a nie konkretnego języka), Java to wprowadziła w końcu i były szampany u ludzi zafascynowanych tą technologią jaka to nowoczesna i jak .NET jest do bani. Podobnie było z wyrażeniami lambda. Roslyn (nowy kompilator C#) istnieje już parę lat a teraz Javowcy piszą coś podobnego - Graal VM. Pewnie znowu będzie gadka jaka to Java jest wspaniała i jaką ma przewagę nad .NET. Dla mnie to zabawne :) Java jest dobrym językiem ale pewnych rzeczy już nie przeskoczy z powodu kompatybilności. Poza tym jest mocno zamkniętym środowiskiem z uwagi na właściciela, który gotów jest pozwać wszystkich o naruszenie patentów. Z .NET tego problemu nie ma - masz kody źródłowe komercyjnego produktu (co nie odpwiada np. Open JDK), licencja MIT do tego otwarta specyfikacja także .NET wygląda, że ma lepszą przyszłość.

Technologia jest dla ludzi, ja nie rozumiem tych sporów. Jak komuś odpowiada Java to niech programuje w niej. Jak ktoś lubi C++ i klepanie masy kodu to niech w tym programuje. Jak ktoś woli .NET to jego wybór. Praca w każdej z tych technologii jest, także zawsze można ją zmienić jak komuś coś nie pasuje.

Roslyn (nowy kompilator C#) istnieje już parę lat

Roslyn równie dobrze mógłby nie istnieć - ot, Microsoft zdecydował że przepisze kompilator C# w C# (poprzedni był napisany w C++) i przy okazji udostępni kod źródłowy.

Wydaje mi się, że nie masz pojęcia czym Roslyn jest. Jak ktoś programuje dłużej w C# to na pewno zobaczył jaki był przeskok jakościowy w pisaniu aplikacji. Refaktoring, statyczna analiza kodu, znajdywanie metod rozszerzających, klas itp. w assemlby i inne bajery, które na co dzień się używa są możliwe dzięki Roslynowi. Największy postęp do była przejścia na statyczną analizę kodu źródłowego a nie skompilowanego co daje niezłe efekty.

Największy postęp do była przejścia na statyczną analizę kodu źródłowego a nie skompilowanego co daje niezłe efekty.

A to nie było tak że C#-powcy marzyli że roslyn da im type providersy?

Najbardziej przyszlosciowe sa te co nie powstaly, reszta umiera.

śmieszek napisał(a):

"Sam Graal VM nie jest jeszcze gotowy, ale Java 9 będzie mieć już funkcjonalność, która wykorzystuje Graala: JEP 295: Ahead-of-Time Compilation"

Widzę, że Java znowu pozazdrościła .NETowi :) Szkoda tylko że zawsze są parę lat za nim. Najpierw wyrażenia lambda, później generacje GC a teraz wystawione API kompilatora. Kto wie, może za kilka lat zaimplementują LINQ?

No tak, .NET jest pionierem we wszystkich dziedzinach i jeśli implementujemy coś co było w .NETu to znaczy, że mu zazdrościmy....

Kompilacja AOT to tylko jedna z funkcjonalności udostępnianych przez Graal VM. Sam AOT do Javy istnieje od roku 2000: https://en.wikipedia.org/wiki/Excelsior_JET

Lambdy w Javie, podobnie jak genericsy, są kompatybilne wstecznie. Lambdy są konwertowane na instancje klas wszędzie tam, gdzie oczekujemy klasy z SAM (single abstract method). .NET nie miał ambicji, by jego lambdy były kompatybilne wstecznie więc wprowadził je jako całkowicie osobne narzędzie do programowania.

Generacyjne GC? Istnieje dłużej niż nawet sama Java. Wiki w artykule o generacyjnym GC podaje nazwisko https://en.wikipedia.org/wiki/David_Ungar który to stworzył generacyjne GC w 1984, a w 2001 roku został zatrudniony przez Suna. Dokładnych historii nie znam i nie chce mi się sprawdzać, ale na pewno .NET nie był tutaj motorem napędowym dla rozwoju GC. Motorem napędowym był Lisp i autorzy Javy implementowali GC po zapoznaniu się z badaniami na GC od autorów Lispa.

Wystawione API kompilatora? Tym stwierdzeniem obnażyłeś całą swoją ignorancję. Graal VM nie polega na wystawieniu API kompilatora (tego z kodu źródłowego bajtkodu) tylko API maszyny wirtualnej (czyli interpretera/ kompilatora JIT). Z wystawiania API kompilatora (w sensie takim jakim jest np Presentation Compiler w Scali od dawien dawna) nie widzę dużego zysku, bo goście z JetBrains i tak zaimplementują super narzędzia do C#/ Javy/ Scali/ czegokolwiek bez polegania na jakimkolwiek "standardowym" Presentation Compilerze.

Jeśli chodzi o Resharpera to (ReSharper and Roslyn: Q&A):

Will ReSharper take advantage of Roslyn?

The short answer to this tremendously popular question is, no, ReSharper will not use Roslyn.

Graal VM polega na wystawieniu API maszyny wirtualnej. W trakcie wykonywania możemy podać JVMowi dowolnego AST do interpretacji, czy zJITowania. AST może pochodzić z analizy kodu Pythonowego, JavaScriptowego, napisanego w R czy pochodzącego z bajtkodu LLVM. To ostatnie może pomóc zastąpić JNI i statycznie kompilowane biblioteki DLL/ SO/ czegokolwiek przez wrzucanie bajtkodu LLVM i kompilowanie go przez JVMa na maszynie klienta, przez co nie trzeba będzie wrzucać do JARa natywnych wersji na wszelkie dostępne systemy operacyjne.

LINQ to nie wiem po co wrzucać do języka jeśli są już strumienie w Javie 8 i jest w nich pełno kombinatorów, w zasadzie bardzo podobnych do tych z LINQ.

a przejscie z ruby na elixir?

Muszę pewne rzeczy naprostować.

No tak, .NET jest pionierem we wszystkich dziedzinach i jeśli implementujemy coś co było w .NETu to znaczy, że mu zazdrościmy....

Nigdy nie twierdziłem, że jest pionierem. Wyśmiewałem się tylko z pewnego zjawiska wojny .NET z Javą i puszenia się. Ani Java ani C# nie są nowatorskie bo nawet koncepcja języków zarządzalnych jest znacznie starsza od nich.

Lambdy w Javie, podobnie jak genericsy, są kompatybilne wstecznie. Lambdy są konwertowane na instancje klas wszędzie tam, gdzie oczekujemy klasy z SAM (single abstract method). .NET nie miał ambicji, by jego lambdy były kompatybilne wstecznie więc wprowadził je jako całkowicie osobne narzędzie do programowania.

Nie bardzo rozumiem o co Ci chodzi. W C# wyrażenia lambda są kompilowane do klasy, która również przechowuje domknięcia. Klasy są od .Net 1.0 także nie ma mowy o naruszeniu kompatybilności. Jak już poruszyłeś temat Generyków Javy to właśnie dzięki kompatybilności są one tak marne, wolne i niebezpieczne. Generyki w C# są szybsze i znacznie bezpieczniejsze w użyciu czego ceną było złamanie kompatybilności w wersji 2.0. Nie krytykuje Javy za to, bo podjęli racjonalną decyzję która ma takie skutki.

Generacyjne GC? Istnieje dłużej niż nawet sama Java. Wiki w artykule o generacyjnym GC podaje nazwisko https://en.wikipedia.org/wiki/David_Ungar który to stworzył generacyjne GC w 1984, a w 2001 roku został zatrudniony przez Suna. Dokładnych historii nie znam i nie chce mi się sprawdzać, ale na pewno .NET nie był tutaj motorem napędowym dla rozwoju GC. Motorem napędowym był Lisp i autorzy Javy implementowali GC po zapoznaniu się z badaniami na GC od autorów Lispa.

Nigdzie nie napisałem, że Microsoft wymyślił generację. Porównywałem tylko rozwój dwóch zbliżonych do siebie języków.

Z wystawiania API kompilatora nie widzę dużego zysku.

To szkoda, bo bardzo dużo korzyści z tego płynie.

Jeśli chodzi o Resharpera to (ReSharper and Roslyn: Q&A):

I co w związku z tym? Trudno, żeby korzystali z Roslyna skoro już tyle zainwestowali we własną technologię, którą zapewne używają również w innych językach.

Graal VM polega na wystawieniu API maszyny wirtualnej. W trakcie wykonywania możemy podać JVMowi dowolnego AST do interpretacji, czy zJITowania.

No to ciekawe. W .NET takie rzeczy są wbudowane od dawna, możesz sobie dowolony kod generować w aplikacji za pomocą refleksji.

LINQ to nie wiem po co wrzucać do języka jeśli są już strumienie w Javie 8 i jest w nich pełno kombinatorów, w zasadzie bardzo podobnych do tych z LINQ.

Cała rzecz z LINQ nie polega tylko na fajnej bibliotece ale na wspieraniu jej bezpośrednio przez kompilator. Bardziej czytelny jest taki kod:

from item in collection
where item.price > 20
orderby item.price descending
select item

Niż takie cudo:

List fruits =
    Arrays.asList("apple", "banana", "cherry", "plum", "pear", "pinapple");

myList
    .stream()
    .filter(s -> s.startsWith("p"))
    .map(String::toUpperCase)
    .sorted()
    .forEach(System.out::println);

Nigdy nie twierdziłem, że jest pionierem. Wyśmiewałem się tylko z pewnego zjawiska wojny .NET z Javą i puszenia się. Ani Java ani C# nie są nowatorskie bo nawet koncepcja języków zarządzalnych jest znacznie starsza od nich.

Nie było tu żadnej wojny między Javą, a .NETem dopóki sam nie wpadłeś i sam nie zacząłeś bić piany o generacyjnych GC i innych rzeczach, które to niby Javowcy skopiowali z .NETa.

Nie bardzo rozumiem o co Ci chodzi. W C# wyrażenia lambda są kompilowane do klasy, która również przechowuje domknięcia. Klasy są od .Net 1.0 także nie ma mowy o naruszeniu kompatybilności. Jak już poruszyłeś temat Generyków Javy to właśnie dzięki kompatybilności są one tak marne, wolne i niebezpieczne. Generyki w C# są szybsze i znacznie bezpieczniejsze w użyciu czego ceną było złamanie kompatybilności w wersji 2.0. Nie krytykuje Javy za to, bo podjęli racjonalną decyzję która ma takie skutki.

Kompatybilność polega na tym, że nawet korzystając ze starożytnej biblioteki, która nie słyszała o lambdach można je użyć. Jeśli w danym miejscu metoda przyjmuje klasę z jedną metodą abstrakcyjną to można to zaimplementować za pomocą lambdy.

Generyki w Javie nie są znowu jakieś bardzo złe. Niebezpieczeństw nie ma, jeżeli stosujemy się do zaleceń kompilatora, który wychwytuje złe użycia generyków na etapie kompilacji - domyślnie jednak wyrzuca tylko ostrzeżenia, a nie wstrzymuje kompilacji. Upierdliwe może być wymuszanie boxingu przy korzystaniu z generyków. To rzeczywiście ma spory wpływ na wydajność i jak na razie nie ma na to wygodnych obejść czy rozwiązań. Są różne typy strumieni, jak np IntStream, LongStream czy DoubleStream i dzięki temu odzyskujemy wydajność, ale kosztem tego, że trzeba żonglować typami strumieni. Pytanie tylko jak bardzo to wpływa na wydajność aplikacji biznesowych? Bardzo rzadko widuję kolekcje prymitywów w kodzie, który piszę w firmie. Nawet jeśli gdzieś się tam przewijają to nie sądzę by wyraźnie spowalniały całą aplikację.

Nigdzie nie napisałem, że Microsoft wymyślił generację. Porównywałem tylko rozwój dwóch zbliżonych do siebie języków.

To jeszcze porównaj efekt dla użytkownika końcowego. Przechwalanie się, że .NET ma pierdylion ficzerów niewiele zmienia, jeśli użytkownik końcowy nic nie widzi. Czy ten generacyjny GC od razu pozwolił .NETowi przeskoczyć Javę? A może generacyjny GC dla Javy był przygotowywany już wcześniej, ale nie był na tyle dopracowany by go domyślnie włączać? Od dłuższego czasu była sprawa z G1 GC, który ma być następcą CMSa jednak od zapowiedzi G1 do momentu ustawienia go jako domyślnego GC jest sporo czasu - G1 ma być domyślny dopiero w Javie 9, która jeszcze oficjalnie nie wyszła.

Jeśli ktoś ma duże wymagania co do GC to dla Javy jest świetne rozwiązanie - Azul C4 GC. Autorzy chwalą się, że potrafi obsługiwać VMki ze stertą na setki gigabajtów, a pauzy są dalej rzadkie i minimalne. Oracle przygotowuje coś podobnego jako element własnej wersji JRE: https://wiki.openjdk.java.net/display/shenandoah/Main .NET ma coś takiego, czy zamierza dopiero "skopiować" od Javy?

To szkoda, bo bardzo dużo korzyści z tego płynie.

Zysk jest głównie dla samego MS, który może lepiej zintegrować swoje własne narzędzia.

I co w związku z tym? Trudno, żeby korzystali z Roslyna skoro już tyle zainwestowali we własną technologię, którą zapewne używają również w innych językach.

To, że Roslyn wchodzi w paradę Resharperowi i ten ostatni wolniej działa. Nowe IDE od JetBrains: https://www.jetbrains.com/rider/ jest połączeniem Javowego frontendu i .NETowego backendu, a więc pomija całkowicie Visual Studio i chyba też Roslyna. Efekt jest taki, że działa znacznie szybciej (przynajmniej tak pisze JetBrains na swojej stronie).

Z punktu widzenia użytkownika końcowego wprowadzenie Roslyna ma więc następujące skutki:

• dla tych którzy używają gołego Visual Studio jest lepiej,
• dla tych którzy korzystają z Resharpera jest gorzej,

Sami oceńcie czy to dobry wynik.

No to ciekawe. W .NET takie rzeczy są wbudowane od dawna, możesz sobie dowolony kod generować w aplikacji za pomocą refleksji.

Podaj konkretne linki do API czy manuali. Konkretnie interesuje mnie jak to AST wygląda, które to się wrzuca bezpośrednio do VMki w trakcie wykonywania programu (nie kompilacji do bajtkodu, bo przecież wtedy nie działamy na VMce klienta; sam bajtkod nie jest też żadnym AST, przynajmniej nie ten Javowy).

Cała rzecz z LINQ nie polega tylko na fajnej bibliotece ale na wspieraniu jej bezpośrednio przez kompilator. Bardziej czytelny jest taki kod:
Niż takie cudo:

1. Kwestia gustu. Jak dla mnie to im mniej dziwacznych DSLi tym lepiej. Wolę kod bez niespodzianek, który wygląda tak jak każdy inny.
2. Czy LINQ można wygodnie rozbić na mniejsze funkcje? Te przykłady z LINQa które widziałem to można by podpiąć pod kategorię "Hello World".
3. Łańcuch wywołań funkcji jest lepiej sprecyzowany, mogę dowolnie sterować kolejnością wykonania kombinatorów tak by nie wpaść w kiepską złożoność obliczeniową.

Aktualizacja:

Jako, że temat wrzucania AST do VMki wydaje się być bardzo interesujący to podrążyłem temat i znalazłem coś takiego: http://jruby.org/bench9000/
jruby-dev-truffle-graal osiąga niezłe przyspieszenie względem zarówno oficjalnego interpretera Ruby jak i wersji JRuby, która operuje na bajtkodzie.

Nie było tu żadnej wojny między Javą, a .NETem dopóki sam nie wpadłeś i sam nie zacząłeś bić piany o generacyjnych GC i innych rzeczach, które to niby Javowcy skopiowali z .NETa.

Wyśmiałem po prostu pewne zjawisko. świat IT nie kręci się wokół 4p także w innych miejscach można takie śmieszne wojny spotkać. Zupełnie bezcelowe. Fakty są takie, że lepsze jest wrogiem dobrego. .NET powstał 5 lat po Javie i jego celem nie było skopiowanie produktu Sun'a ale stworzenie czegoś lepszego. Naturalna ewolucja. Oba języki są dobre ale Java z uwagi na dłuższy staż i zachowanie kompatybilności nie może się tak dynamicznie rozwijać. Być może jej rozwój ruszy, nie wiem. Ale na razie w pewnych kwestiach odstaje.

Generyki w Javie nie są znowu jakieś bardzo złe. Niebezpieczeństw nie ma, jeżeli stosujemy się do zaleceń kompilatora, który wychwytuje złe użycia generyków na etapie kompilacji - domyślnie jednak wyrzuca tylko ostrzeżenia, a nie wstrzymuje kompilacji. Upierdliwe może być wymuszanie boxingu przy korzystaniu z generyków. To rzeczywiście ma spory wpływ na wydajność i jak na razie nie ma na to wygodnych obejść czy rozwiązań.

Zgadza się, to są problemy generyków w Javie. Mieli wybór i niestety musieli wybrać kompatybilność.

Przechwalanie się, że .NET ma pierdylion ficzerów niewiele zmienia, jeśli użytkownik końcowy nic nie widzi.

Zmienia, bo duża część tych "ficzerów" ułatwia pisanie aplikacji co z reguły pozwala pisać lepszy kod, który ma mniej błędów.

Czy ten generacyjny GC od razu pozwolił .NETowi przeskoczyć Javę?

To nie są produkty równoważne wbrew pozorom. Jak pisałem wcześniej, .NET powstał długo po Javie i podczas jego tworzenia z pewnością brali pod uwagę doświadczenia przy jej tworzeniu. Java ma problem, bo jest bardzo popularna i posiada ogromną bazę kodu. Z tego powodu muszą zachowywać kompatybilność i tak np. generyki są jakie są i raczej się to nie zmieni. Podczas tworzenia .NET 2.0 mogli się nie przejmować kompatybilnością i dzięki temu udało się szybko wprowadzić kluczowe kwestie do platformy.

Jeśli ktoś ma duże wymagania co do GC to dla Javy jest świetne rozwiązanie - Azul C4 GC. Autorzy chwalą się, że potrafi obsługiwać VMki ze stertą na setki gigabajtów, a pauzy są dalej rzadkie i minimalne. Oracle przygotowuje coś podobnego jako element własnej wersji JRE: https://wiki.openjdk.java.net/display/shenandoah/Main .NET ma coś takiego, czy zamierza dopiero "skopiować" od Javy?

Chyba zbyt osobiście bierzesz do siebie tą technologię. Zgadzam się z Tobą, Azul i cały Zing to świetna technologia i w .NET prawdopodobnie takiej nie ma. Może skopiują w końcu, bo przydała by się ;)

Zysk jest głównie dla samego MS, który może lepiej zintegrować swoje własne narzędzia.

Wiadomo, że nie robią tego charytatywnie. Ale kod źródłowy Roslyna jest, .NET również a gdzie jest kod komercyjnej Javy?

To, że Roslyn wchodzi w paradę Resharperowi i ten ostatni wolniej działa. Nowe IDE od JetBrains: https://www.jetbrains.com/rider/ jest połączeniem Javowego frontendu i .NETowego backendu, a więc pomija całkowicie Visual Studio i chyba też Roslyna. Efekt jest taki, że działa znacznie szybciej (przynajmniej tak pisze JetBrains na swojej stronie).

No trudno, żeby napisali inaczej o swoim produkcie ;) Nie wiem, nie korzystałem z ich IDE ale trudno obwiniać Microsoft, że nie przejmował się Resharperem podczas tworzenia Roslyna.

Z punktu widzenia użytkownika końcowego wprowadzenie Roslyna ma więc następujące skutki:
dla tych którzy używają gołego Visual Studio jest lepiej,
dla tych którzy korzystają z Resharpera jest gorzej,

może być też lepiej, bo nie będą musieli płacić co roku za licencję ReSharpera. Da się bez niego żyć a w Visual Studio 15 (2017?) to już na pewno.

Podaj konkretne linki do API czy manuali. Konkretnie interesuje mnie jak to AST wygląda, które to się wrzuca bezpośrednio do VMki w trakcie wykonywania programu (nie kompilacji do bajtkodu, bo przecież wtedy nie działamy na VMce klienta; sam bajtkod nie jest też żadnym AST, przynajmniej nie ten Javowy).

Tu masz tutorial dla Roslyna: https://github.com/dotnet/roslyn/wiki/Scripting-API-Samples

Kwestia gustu. Jak dla mnie to im mniej dziwacznych DSLi tym lepiej. Wolę kod bez niespodzianek, który wygląda tak jak każdy inny.

Niby tak, ale jak operujesz w bardziej skomplikowany sposób na kolekcjach, np. łączenie, grupowanie, sortowanie to wtedy to przestaje być kwestią gustu a staje się kwestią czytelności.

Czy LINQ można wygodnie rozbić na mniejsze funkcje? Te przykłady z LINQa które widziałem to można by podpiąć pod kategorię "Hello World".

Nie wiem, czy dobrze Ciebie rozumiem. Linq ma dwie postaci - taką jak podałem przykład w Javie (metody roszerzające) oraz w formie pseudo sql. Można go rozbijać na części, same warunki są po prostu delegatami (np. w formie wyrażeń lambda).

Wyśmiałem po prostu pewne zjawisko. świat IT nie kręci się wokół 4p także w innych miejscach można takie śmieszne wojny spotkać. Zupełnie bezcelowe. Fakty są takie, że lepsze jest wrogiem dobrego. .NET powstał 5 lat po Javie i jego celem nie było skopiowanie produktu Sun'a ale stworzenie czegoś lepszego. Naturalna ewolucja. Oba języki są dobre ale Java z uwagi na dłuższy staż i zachowanie kompatybilności nie może się tak dynamicznie rozwijać. Być może jej rozwój ruszy, nie wiem. Ale na razie w pewnych kwestiach odstaje.

Fakty są takie, że sam tu zacząłeś wojenkę. Nawet jeśli przeniosłeś ją z innego miejsca to to nie ma znaczenia. Nawet nie wiem co cię skłoniło do tego by zacząć bić pianę, a gdybym wiedział to przynajmniej wiedziałbym na czym się skupić zamiast odpowiadać na dziesiątki pobocznych historyjek.

Wiadomo, że nie robią tego charytatywnie. Ale kod źródłowy Roslyna jest, .NET również a gdzie jest kod komercyjnej Javy?

Jest OpenJDK, który już jest albo i niedługo będzie referencyjną wersją Javy. Zamknięte komercyjne dodatki do Javy od Oracle'a istnieją, ale to chyba nie problem. MS też wszystkiego nie otworzył.

Niby tak, ale jak operujesz w bardziej skomplikowany sposób na kolekcjach, np. łączenie, grupowanie, sortowanie to wtedy to przestaje być kwestią gustu a staje się kwestią czytelności.

Dla mnie to SQLowa składnia jest dziwaczna. Może gdybym klepał te SQLe w kółko to bym się przyzwyczaił, ale na co dzień pisuję w Scali. W Scali stosuje się ciągi wywołań i jest to idiomatyczne funkcyjne podejście. Każde wywołanie z ciągu jest krokiem, który tworzy nową (zwykle niemutowalną) kolekcję (albo widok) - super łatwo się to analizuje i wydziela mniejsze sekwencje kroków. W przypadku takiego LINQ ciężko od razu stwierdzić jakie kroki i w jakiej kolejności się wykonają. Jak już wspomniałem jest to dość ważne, bo np sortowanie w złym momencie może zwiększyć złożoność mocno mimo że semantycznie wszystko będzie OK. Dużo też zależy od tego jaki jest wybór - Scala ma fajnie zrobione for-comprehensions, gdzie oprócz cukru składniowego dla podstawowych konstrukcji monadycznych (flatMap, map i filter) jest też bardzo zwięzły pattern matching. Java tego nie ma, LINQa też nie używałem, więc ciężko mi porównać rozwiązania Javowe i C#-owe. Jednak z punktu widzenia Scalowca LINQ wygląda jak zbędna pokraka.

A'propos Scali: dzięki wymazywaniu typów w Javie Scala nie jest ograniczana przez implementację genericsów, bo jej na poziomie JVMa po prostu nie ma. CLR natomiast ma implementację genericsów zrobioną dość sztywno, bo Microsoftowi (w zasadzie słusznie) nie zależy na wspieraniu generyków bardziej skomplikowanych niż w C#.

Tu masz tutorial dla Roslyna: https://github.com/dotnet/roslyn/wiki/Scripting-API-Samples

To jest jakiś dowcip? Gdzie tu jest jakiekolwiek AST? Rozumiesz w ogóle ten skrót?

Na https://github.com/dotnet/roslyn/wiki/Scripting-API-Samples jest napisane:

The scripting APIs enable .NET applications to instatiate a C# engine and execute code snippets against host-supplied objects.

Wygląda na to, że to jest podobna zabawka co https://en.wikipedia.org/wiki/BeanShell stworzony w 1999 roku. Ja pisałem o tym, że z pomocą Graal VM można podrzucać VMce w czasie wykonania AST, które nie ma generalnie nic wspólnego z jakimkolwiek konkretnym językiem programowania. Dzięki Graal VM i Truffle można tworzyć własne języki programowania, które będą interpretowane i JITowane przez VMkę w locie: https://github.com/graalvm/simplelanguage Partial evaluation sugeruje też, że nie trzeba podrzucać VMce naraz wszystkiego. Można np mieć 100 MB kodu źródłowego, ale podrzucać kawałki w miarę potrzeby, tuż przed tym jak są wykonywane. Jak już podałem wcześniej, zostało to wykorzystane do zaimplementowania bardzo szybkiej wersji Ruby'ego.

Akurat LINQ expressions to jeden z większych syfów w C# (gorszy jest chyba tylko null). Dodali 20 słów kluczowych w celu jakim? Żeby SQLowcy mieli łatwiej zmigrować na C#? Czy może bazodanowych ignorantów piszących w C# nakłonić do poznania SQLa? Sensu żadnego, jedynie dodatkowa komplikacja w języku, który już i tak jest nadmiernie skomplikowany i niespójny.

@Wibowit - drwiąco pytasz o skrót AST gościa, który całkiem niedawno obalił zasadę Dirichleta. Na Twoim miejscu bym uważał. ;)

Fakty są takie, że sam tu zacząłeś wojenkę. Nawet jeśli przeniosłeś ją z innego miejsca to to nie ma znaczenia. Nawet nie wiem co cię skłoniło do tego by zacząć bić pianę, a gdybym wiedział to przynajmniej wiedziałbym na czym się skupić zamiast odpowiadać na dziesiątki pobocznych historyjek.

Jeżeli się czujesz urażony czy zaatakowany to przykro mi, nie miałem takiego celu. Moim zdaniem brak Ci dystansu do głupiego narzędzia i traktujesz je zbyt osobiście.

Dla mnie to SQLowa składnia jest dziwaczna. Może gdybym klepał te SQLe w kółko to bym się przyzwyczaił, ale na co dzień pisuję w Scali.

Rozumiem. Ale zauważ, że Twój przypadek stanowi wyjątek bo większość aplikacji wciąż oparta jest na SQL.

Jednak z punktu widzenia Scalowca LINQ wygląda jak zbędna pokraka.

I dlatego masz wolność. możesz używać LINQ na jeden z dwóch sposobów.

To jest jakiś dowcip? Gdzie tu jest jakiekolwiek AST? Rozumiesz w ogóle ten skrót?

Podałem Ci przykład zastosowania, jeżeli rzeczywiście szukasz informacji to pierwszy link z Google by Ci pomógł: https://github.com/dotnet/roslyn/wiki/Getting-Started-C%23-Syntax-Analysis

Akurat LINQ expressions to jeden z większych syfów w C# (gorszy jest chyba tylko null). Dodali 20 słów kluczowych w celu jakim? Żeby SQLowcy mieli łatwiej zmigrować na C#? Czy może bazodanowych ignorantów piszących w C# nakłonić do poznania SQLa? Sensu żadnego, jedynie dodatkowa komplikacja w języku, który już i tak jest nadmiernie skomplikowany i niespójny.

W LINQ można rozwiązywać bardzo złożone problemy w elegancki sposób pod warunkiem, że się piszę coś więcej niż select. Dodali 20 słów kluczowych, ponieważ składnia SQL jest bardziej przejrzysta niż masa wywołań z kropkami, nawiasami, lambdami itp. Jak Ci się nie podoba, to przecież nie musisz jej używać, w czym problem?

Jeżeli się czujesz urażony czy zaatakowany to przykro mi, nie miałem takiego celu. Moim zdaniem brak Ci dystansu do głupiego narzędzia i traktujesz je zbyt osobiście.

Jasne. Wytknął to człowiek, który:

• zaczął wojenkę Java vs C#,
• od razu wyśmiał takie wojenki - schizofrenia?
• nie wiadomo w ogóle dlaczego je zaczął,

Rozumiem. Ale zauważ, że Twój przypadek stanowi wyjątek bo większość aplikacji wciąż oparta jest na SQL.

Współczuję sisitowcom, skoro muszą klepać swoje aplikacje w SQLu. Ja 5 lat piszę w backendzie i tego SQLa doświadczyłem jakieś śladowe ilości.

Jednak o gustach się nie dyskutuje. Mi LINQ nie przypasował. Oszczędność znaków nie zawsze idzie w parze z czytelnością. Dla mnie rozbicie operacji na kolekcjach na osobne kroki znacznie ułatwia analizę kodu. Jeśli bardzo lubisz zwięzłą składnię to polecam język APL: http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#APL

Jeśli komuś pasuje LINQ to spoko, ale to chyba ty masz za mały dystans do narzędzia, skoro tak zaciekle bronisz jego wyższości.

Podałem Ci przykład zastosowania, jeżeli rzeczywiście szukasz informacji to pierwszy link z Google by Ci pomógł: https://github.com/dotnet/roslyn/wiki/Getting-Started-C%23-Syntax-Analysis

Świetnie! W końcu zajarzyłeś co to jest AST, sukces!!! Teraz jeszcze musisz skumać podział na narzędzia odpalane na maszynie programisty i narzędzia odpalane na maszynie użytownika. Oprócz tego AST z Roslyna wygląda na ściśle związane z językiem C# - nie wygląda jakby dało się w tym sensownie zamodelować inne języki, jak np JavaScript, Ruby czy bajtkod LLVMa. javac też ma własne AST, ale nie przypominam sobie by było jakoś ustandaryzowane i upublicznione - nie ma to tutaj znaczenia, bo i tak to AST istnieje tylko w momencie kompilacji z kodu źródłowego do bajtkodu. IntelliJ ma własne AST do Javy i jest świetnym narzędziem. Wątpię, by Oracle stworzyło coś lepszego. O GraalVM/ Truffle nie będę się w kółko powtarzał, bo i tak masz poważne problemy z czytaniem ze zrozumieniem. Przypomnę tylko jeden fragment:

Building on the compiler, we aim to develop a multi-language interpreter framework. Java will be just one member in the family of supported languages. The use of partial evaluation will allow the framework to deliver competitive performance.

W sumie to mogę też podać opis innego projektu opartego o GraalVM/ Truffle framework: https://github.com/graalvm/sulong

Opiszę ci po polsku (abyś zrozumiał) jak w skrócie działa Sulong:

• użytkownik podrzuca do Sulonga LLVM IR, czyli pośrednią reprezentację między LLVMowym frontendem, a backendem,
• owo LLVM IR jest konwertowane do AST przez Truffle,
• AST jest interpretowane i profilowane w locie przez GraalVM,
• na podstawie danych z profilowania następuje kompilacja JIT do kodu natywnego często używanych fragmentów kodu,
• dzięki partial evaluation nie trzeba czekać, aż od razu skompiluje się wszystko - AST tworzymy sobie, interpretujemy i JITujemy w razie potrzeby, a więc jeśli mamy 100 MB bajtkodu LLVMa, ale wykonuje się 5% z niego to tylko te 5% będzie zamienione na AST, intepretowane i JITowane,

A teraz podaj mi jakikolwiek działający projekt od MS, który implementuje powyższe funkcjonalności. Jestem pewien że znajdziesz, bo w końcu Java wszystko kopiuje z .NETa.

śmieszek napisał(a):

Jak Ci się nie podoba, to przecież nie musisz jej używać, w czym problem?

Problemów jest wiele:

1. kolejny powód do opieprzania juniorów podczas review, kolejny czas stracony na poprawki;
2. dodawanie kolejnych słów kluczowych do i tak skomplikowanego języka zwiększa tylko próg wejścia, nie dając w zamian właściwie nic;
3. więcej możliwości zapisania tego samego to więcej styli kodowania, co tworzy brak spójności;
4. do języka typu C# bardziej pasuje wywoływanie łańcucha metod niż słowa kluczowe z SQL;
5. po iluś takich zmianach, język przestaje wyglądać jak jakiś zaprojektowany twór, a zaczyna jak losowa mieszanina różnych języków, w zależności od tego, co w danym roku pili autorzy.

Współczuję sisitowcom, skoro muszą klepać swoje aplikacje w SQLu. Ja 5 lat piszę w backendzie i tego SQLa doświadczyłem jakieś śladowe ilości.

Nie wiem, czego tu współczuć. Sama teoria relacyjnych baz danych świetnie się sprawdziła pomimo upływu lat a same bazy są bardzo dobre a w pewnych zastosowaniach niezbędne. Jest teraz trend na bazy NoSQL która również są całkiem dobre ale w bardzo wąskich zastosowaniach. Większość aplikacji biznesowych opiera się na różnych relacjach, zatem wytłumacz w jaki sposób te informacje przechowujesz? Jakie aplikacje piszesz od 5 lat, że nie ma w nich żadnych relacji? Chętnie się dowiem, bo sam piszę aplikacje oparte bardzo mocno na relacjach i być może brak mojej wiedzy sprawia, że muszę się faktycznie męczyć.

Oszczędność znaków nie zawsze idzie w parze z czytelnością. Dla mnie rozbicie operacji na kolekcjach na osobne kroki znacznie ułatwia analizę kodu

Nie zgodzę się. Języki programowania wyglądają jak wyglądają z powodu naszej ludzkiej słabości. Lepiej by przecież było, gdyby wszyscy pisali w asemblerze ponieważ jest najbliżej procesora. Ale że mamy ograniczoną percepcję to musimy tworzyć abstrakcję. Ponieważ w jednym czasie możemy "ogarnąć" umysłem ograniczoną ilość kodu rozbijamy go na atomowe metody. Programowanie polega na kompresji danych - również wykresy trzeba kompresować, ponieważ człowiek nie jest w stanie lupą zobaczyć szeroką perspektywę. Zatem im mniej kodu zmieści się na jak największej przestrzeni tym lepiej.

Jeśli komuś pasuje LINQ to spoko, ale to chyba ty masz za mały dystans do narzędzia, skoro tak zaciekle bronisz jego wyższości.

Napisałem wiele razy, że kwestia gustu. Bardzo lubię języki funkcyjne za ich zwięzłą składnię i możliwość wyrażenia skompilowanych działań w prosty sposób.

Teraz jeszcze musisz skumać podział na narzędzia odpalane na maszynie programisty i narzędzia odpalane na maszynie użytownika.

Zobacz sobie jeszcze raz API Roslyna. Wtedy skumasz bardzo łatwo, że narzędzie które będzie odpalało kod u użytkownika napiszesz sobie w 5 minut.

Oprócz tego AST z Roslyna wygląda na ściśle związane z językiem C# - nie wygląda jakby dało się w tym sensownie zamodelować inne języki, jak np JavaScript, Ruby czy bajtkod LLVMa.

Pytanie jest inne - po co? Po co miałbym używać Ruby, jeżeli chce programować w .NET? Bardzo dobrze, że taka maszyna wirtualna jest. Jeżeli kiedyś będę miał okazję programować w Ruby to pewnie z niej skorzystam, nie mam z tym problemu, żeby korzystać z Javy jeżeli dobrze się sprawdzi w moich zastosowaniach. To tylko technologia, ma być na mój użytek.

Opiszę ci po polsku (abyś zrozumiał) jak w skrócie działa Sulong:

Bardzo opryskliwy jesteś, ale spokojnie - dosyć to zabawne :) Od 3 postów oskarżasz mnie o wojnę po czym od 3 postów atakujesz mnie, podważasz moją inteligencje czy umiejętności. Ja Ciebie nie zaatakowałem ani razu personalnie, pytanie jest zatem: kto tutaj prowadzi wojnę?

A teraz podaj mi jakikolwiek działający projekt od MS, który implementuje powyższe funkcjonalności. Jestem pewien że znajdziesz, bo w końcu Java wszystko kopiuje z .NETa.

Pewnie nie ma, Java jest pod tym względem zapewne lepsza :)

dodawanie kolejnych słów kluczowych do i tak skomplikowanego języka zwiększa tylko próg wejścia, nie dając w zamian właściwie nic;

Daje dużą czytelność. Dam Ci przykład: napisz kod, który wyciągnie z kolekcji elementy, które nie występują w innej kolekcji, następnie pogrupuje je po nazwie oraz dociągnie do niej z innej kolekcji elementy po kluczu. Brzmi to jak zadanie dla SQL ale lepiej jest wczytać wiele danych za jednym zamachem i przetworzyć je w pamięci niż rąbać co chwilę zapytanie do bazy.

Dla mnie bez sensu jest upraszczać język, bo komuś nie chce się go nauczyć. Są bardzo dobre książki ale dużo ludzi nie chce włożyć minimum wysiłku, żeby ten język poznać.

do języka typu C# bardziej pasuje wywoływanie łańcucha metod niż słowa kluczowe z SQL;

Zgadzam się. Ale podobnie jest z wyrażeniami lambda (czysto funkcyjna rzecz), domknięciami (znowu funkcyjna rzecz), typami anonimowymi (funckyjny element), krotkami itp. Wszystkie te mechanizmy albo łamią zasady OOP (np. domknięcie może wystawić na zewnątrz prywatne elementy klasy) albo kompletnie nie pasują do języka silnie typowanego (typy anonimowe).

po iluś takich zmianach, język przestaje wyglądać jak jakiś zaprojektowany twór, a zaczyna jak losowa mieszanina różnych języków, w zależności od tego, co w danym roku pili autorzy.

Na razie byli dosyć ostrożni na szczęście, jest takie niebezpieczeństwo, tutaj masz całkowitą rację. Takie są trendy według mnie, że wszystko idzie w stronę języków funkcyjnych. Najlepsze potworki są w C++ - ich wyrażenia lambda.

LINQ jest super, blablabla

Dobra, skończ tą napinkę. I tak się nie przekonamy. Różne rzeczy są czytelniejsze dla różnych ludzi.

Zobacz sobie jeszcze raz API Roslyna. Wtedy skumasz bardzo łatwo, że narzędzie które będzie odpalało kod u użytkownika napiszesz sobie w 5 minut.

GraalVM i Truffle framework napiszę sobie w 5 minut? A to dobre. Ciekawe po co Oracle rozwija projekt przez wiele lat za pomocą zespołu programistów, skoro wszystko można załatwić zwykłym presentation compilerem?

Poza tym narzędzia do generowania bajtkodu w locie i jego ładowania w czasie uruchamiania istnieją w świecie Javy od wielu, wielu lat. Nie ma to jednak nic wspólego z JITowanym AST, podobnie jak Roslyn.

Pytanie jest inne - po co? Po co miałbym używać Ruby, jeżeli chce programować w .NET? Bardzo dobrze, że taka maszyna wirtualna jest. Jeżeli kiedyś będę miał okazję programować w Ruby to pewnie z niej skorzystam, nie mam z tym problemu, żeby korzystać z Javy jeżeli dobrze się sprawdzi w moich zastosowaniach. To tylko technologia, ma być na mój użytek.

Bo C# może się komuś nie podobać, podobnie jak Java. Java ma bujny ekosystem. Istnieją sobie na nim już języki jak Scala, Kotlin, JRuby, Groovy, Clojure i inne. Dzięki temu ludzie, którzy niespecjalnie byliby zainteresowani platformą Java się na nią przenoszą. Po wprowadzeniu GraalVM w życie bardzo duża ilość popularnych języków będzie hulać na JVMce najszybciej i to moim zdaniem może diametralnie zwiększyć jej popularność. Zamiast pakować się w PyPy, Rubiniusy, HHVMy i inne wynalazki, które nie są oparte na sprawdzonej od wielu lat technologii będzie można użyć szeroko używanego GraalVMa. Aktualnie np takie JRuby nie daje dużego zysku wydajnościowego względem oficjalnego interpretera, może 2x średnio, a przy użyciu GraalVM będzie to raczej 20x i chyba nie będzie to zjadało pamięci w tak szybkim tempie jak teraz JRuby.

A taki Sulong rozwiąże też dość uciążliwy problem jakim jest wrzucanie natywnych bibliotek do Javowych aplikacji. Obecnie trzeba kompilować zawczasu na wszelkie platformy, które chcemy obsługiwać. Jeśli wprowadzony zostanie GraalVM/ Sulong to wtedy wystarczające będzie wrzucenie jednego egzemplarza bajtkodu LLVMa, a GraalVM zJITuje to sobie do kodu natywnego dla platformy klienta już na maszynie klienta. Hasło "write once, run everywhere" rozszerzy się też więc i na natywny kod.

Bardzo opryskliwy jesteś, ale spokojnie - dosyć to zabawne :) Od 3 postów oskarżasz mnie o wojnę po czym od 3 postów atakujesz mnie, podważasz moją inteligencje czy umiejętności. Ja Ciebie nie zaatakowałem ani razu personalnie, pytanie jest zatem: kto tutaj prowadzi wojnę?

Prostuję twoje głupoty po prostu. Wyszedłeś w pierwszym swoim poście z bzdurnego założenia, że Java kopiuje wszystko z .NETa, a przyczepiłeś się do rozszerzenia JVMa, które zupełnie nie ma związku z jakimkolwiek produktem Microsoftu. Pomyliłeś presentation compiler z JITowanym AST - chyba bardziej nie da się odlecieć w kosmos. Mam uznać wyższość .NETa tylko dlatego, że się nim podniecasz?

W poście, który cię sprowokował do pisania bredni nie miałem zamiaru rozpoczynać wojenek C# vs Java. W ogóle nie nawiązałem do jakiegokolwiek produktu Microsoftu. Po prostu spodobała mi się idea GraalVM (JITowany AST, partial evaluation, speculative optimization, etc - GraalVM wygląda na coś, co w 100% korzysta z idei kompilacji JIT). Tobie wcale nie musiała, ale i tak zacząłeś się napinać.

A jeśli chodzi o to kto od kogo kopiuje to prawda jest taka, że pierwsza wersja C# była bezczelnym klonem Javy, praktycznie 100%-owym plagiatem. Następnie drogi tych języków się rozeszły i nie przypominam sobie żadnych ważnych nowych funkcji z Javy wzorowanych na tych z C#. Genericsy działają zupełnie inaczej, lambdy też. Genercisy, ani lambdy nie zostały też wymyślone przez MS. Plagiat MS był na tyle chamski i bezmyślny, że C# 1.0 odziedziczył wszystkie wady Javy,dodatkowo ograniczając API z przenośnego do działającego na jednym systemie. Genericsy i lambdy nie trafiły do pierwszej wersji Javy z powodu braku czasu. Gosling go po prostu nie dostał w wystarczającym stopniu.

śmieszek napisał(a):

Daje dużą czytelność. Dam Ci przykład: napisz kod, który wyciągnie z kolekcji elementy, które nie występują w innej kolekcji, następnie pogrupuje je po nazwie oraz dociągnie do niej z innej kolekcji elementy po kluczu. Brzmi to jak zadanie dla SQL ale lepiej jest wczytać wiele danych za jednym zamachem i przetworzyć je w pamięci niż rąbać co chwilę zapytanie do bazy.

Równie dobrze można wysłać jedno zapytanie SQL, które to zrobi, tylko to i tak nie ma żadnego związku z dyskusją. To nie jest argument za używaniem query syntax zamiast notacji metodowej.

Co do czytelności:

IEnumerable<int> numQuery1 = 
    from num in numbers
    where num % 2 == 0
    orderby num
    select num;

vs

IEnumerable<int> numQuery2 = numbers.Where(num => num % 2 == 0).OrderBy(n => n);

Boję się ludzi, dla których pierwsza wersja jest czytelniejsza.

Dla mnie bez sensu jest upraszczać język, bo komuś nie chce się go nauczyć. Są bardzo dobre książki ale dużo ludzi nie chce włożyć minimum wysiłku, żeby ten język poznać.

Dobry język to taki, który ma mało instrukcji, a jego rozszerzanie odbywa się poprzez dodawanie nowych funkcji. Taki język jest bardziej ekspresywny i łatwiejszy do nauczenia. Piękno tkwi w prostocie.

Wszystkie te mechanizmy albo łamią zasady OOP (np. domknięcie może wystawić na zewnątrz prywatne elementy klasy) albo kompletnie nie pasują do języka silnie typowanego (typy anonimowe).

Nie widzę powodu dla którego typy anonimowe miały łamać silne typowanie. Co innego dynamic.

Na razie byli dosyć ostrożni na szczęście, jest takie niebezpieczeństwo, tutaj masz całkowitą rację.

No właśnie moim zdaniem nie byli, zarówno query syntax, jak i np. nowe jednolinijkowe metody/właściwości, powodują tylko niespójność i syf.