Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 259
Хм, это шутка, или сказка? :)
Я правильно понимаю, что на c# можно будет под Linux официально писать?
Я правильно понимаю, что на c# можно будет под Linux официально писать?
Это тренд. Они ещё весной компилятор новый открыли, да и до этого многие вещи изначально с открытыми исходниками делали, те же Typescript и SignalR. В общем, если всё пойдёт нормально, то Java можно будет хоронить. А если ещё шеневмерл ( полноценный .NET функционально-ориентированого язык с адекватной системой макросов и возможностью при желании из него сделать superset C#) со своим компилятором на базе Nitra из под крыла JetBrains подтянется наконец (что даст нормальную поддержку в Visual Studio и ReSharper), то хоронить можно будет уже скалу.
Про тренд, я, конечно же, слышал: слежу за .NET. Но всё-равно всё это выглядит очень круто.
Помрёт или нет java — не могу сказать. Уж больно много кода написано на ней, да и «восьмёрка» вполне себе хороша. Ещё же и студии нет под Linux, а для Java есть прекрасная IDEA.
Помрёт или нет java — не могу сказать. Уж больно много кода написано на ней, да и «восьмёрка» вполне себе хороша. Ещё же и студии нет под Linux, а для Java есть прекрасная IDEA.
На Java уж извините, столько энтерпрайза написано, что C# до такого показателя, очень и очень далеко. Да и нет у C# каких либо киллер фич которые давали бы повод перейти с java на C#.
Ну написано, и? Есть Sharpen, есть IKVM, всё это можно под CLR запустить после некоторой обработки напильником и автоматическими трансляторами. Вот в обратную сторону не получится, да.
Проперти, делегаты, нормальные (вменяемые) дженерики,…
..., Value-типы, P/Invoke вместо страшного сна под названием JNI, возможность прямой работы с указателями,…
Вот только это все для кодеров счастье, энтерпрайз этим не заманишь.
То есть как это? Это напрямую влияет на продуктивность.
Да, но при крупном планировании в первую очередь смотрят на коммерческую поддержку продуктов и компонентов, а также на инфраструктуру. SharePoint не отдадут.
Да не на что это не влияет. В яве лямбды появились пол года назад. В шарпе они бог знает сколько. Как же они жили до этого? Да очень просто и не принужденно.
Ну появились они, ну ок будим их использовать, да удобней, ок живем дальше.
Ну появились они, ну ок будим их использовать, да удобней, ок живем дальше.
Да ни на что это не влияет. В яве лямбды появились полгода назад. В шарпе они бог знает сколько. Как же они жили до этого? Да очень просто и непринужденно. Ну появились они, ну ок, будем их использовать, да, удобней, ок, живем дальше*.Лямбды — это не просто «стало удобнее», они дали возможность создания такой штуки как LINQ, которая
1) позволяет простыню из циклов на несколько страниц свернуть в одну-две строки и превратить императивный код в декларативный;
2) позволяет делать DSL к различным хранилищам данных;
3) позволяет делать вещи наподобие Rx;
Деревья выражений, позволившие сделать Linq2Sql и наследников, до сих пор не реализованы, и о планах пока не слышно.
*Прошу не считать подсветку красным проявлением «нечего сказать — докопайся до орфографии», просто из глаз начинает сочиться кровь от такого.
Мне кажется, что вы ответили не на мой комментарий. А на фразу, выдернутую из контекста — «стало удобнее». Потому, что я не спрашивал о том чем полезны лямбды. Проясню вам смысл.
Месседж моего комментария в том, что интерпрайзу эти лямбды сто лет в обед. Он медленный и не поворотливый. И ему просто не нужно все это новомодное и продвинутое. И основное правило там — работает не трогай.
Чем проще, понятней и сопровождаемей будет код, тем лучше.
Поэтому много где до сих пор 6 ява. Чтоб никто в свич не пихал стринги, а максимум энум. Чтоб даже возможности такой не было.
Месседж моего комментария в том, что интерпрайзу эти лямбды сто лет в обед. Он медленный и не поворотливый. И ему просто не нужно все это новомодное и продвинутое. И основное правило там — работает не трогай.
Чем проще, понятней и сопровождаемей будет код, тем лучше.
Поэтому много где до сих пор 6 ява. Чтоб никто в свич не пихал стринги, а максимум энум. Чтоб даже возможности такой не было.
Чем проще, понятней и сопровождаемей будет код, тем лучше.
1) позволяет простыню из циклов на несколько страниц свернуть в одну-две строки и превратить императивный код в декларативный;Одну строку на LINQ проще читать и поддерживать чем портянку на несколько страниц
А теперь представьте, что в каком-то интерпрайзе, а в интерпрайзе, как мы знаем, все на яве, один умник (большой любитель функцональщины и декларотивности) сделал свое дело. И через время уволился.
Напомню лямбды в яве пол года.
Какие программисты придут на его место? Что они будет со всем этим делать?
Вот вам понятность и сопровождаемость. А отладка и тестирование с лямбдами — ммм…
Спасибо джетбрейнс, что они хоть что-то в этом направлении делают.
Я видел Rx. Ничего понятного для объектно ориентированного разума там нет.
Напомню лямбды в яве пол года.
Какие программисты придут на его место? Что они будет со всем этим делать?
Вот вам понятность и сопровождаемость. А отладка и тестирование с лямбдами — ммм…
Спасибо джетбрейнс, что они хоть что-то в этом направлении делают.
Одну строку на LINQ проще читать и поддерживать чем портянку на несколько страниц
Я видел Rx. Ничего понятного для объектно ориентированного разума там нет.
Напомню лямбды в яве пол года.
Какие программисты придут на его место? Что они будет со всем этим делать?
Если разобраться с лямбдами для вас представляется сложным, то может лучше пойти вон из профессии?
А других нету, понимаете. Специалистов катастрофически не хватает.
Вот, очень показательный пример: morgen-krsk.livejournal.com/3474.html
Человек привел два кода и говорит, что познал истину. Слева у меня плохой императивный код, а справа декларативный. Значит императивный подход — плохой, а декларативный — что надо.
Вот, очень показательный пример: morgen-krsk.livejournal.com/3474.html
Человек привел два кода и говорит, что познал истину. Слева у меня плохой императивный код, а справа декларативный. Значит императивный подход — плохой, а декларативный — что надо.
Не вижу, что не так со статьёй. Тот код, что справа легче читать и поддерживать чем тот, что слева. Единственная проблема состоит в деградации производительности. Если бы ещё компилятор умел нормально разворачивать правое в левое (а это должно быть задачей компилятора, а не человека, при профилировании увидевшего что оно тормозит), было бы вообще отлично. Сейчас приходится использовать костыли типа LinqOptimizer.
Тот код, что справа легче читать и поддерживать чем тот, что слева.
Все верно. Действительно, тот код, что справа легче читать и поддерживать чем тот, что слева. Потому, что слева человек наговнокодил, а справа использовал функциональщину. И выдает все это за плюсы и минусы соответствующих подходов.
Если нужно повторное использование кода, связность и т.д. то напиши так.
Зачем сравнивать теплое с мягким.
Все верно. Действительно, тот код, что справа легче читать и поддерживать чем тот, что слева. Потому, что слева человек наговнокодил, а справа использовал функциональщину. И выдает все это за плюсы и минусы соответствующих подходов.
Если нужно повторное использование кода, связность и т.д. то напиши так.
Зачем сравнивать теплое с мягким.
Смотрю на статью, вижу там нахождение суммы значения функции от элемента массива, когда элемент больше 10. Я правда не понимаю, почему это заговнокодено. И в императивном и «декларативном» подходе оба кода оптимальные с точки зрения количества строк кода (хотя форматирование страдает), прозрачности намерений и производительности которую можно выжать при данном подходе. Если переписать код слева так, чтобы в нем была возможность повторного использования вы получите оверхед по количеству строк и понимаемости кода.
Да, статья однобокая. Императивный/функциональный подходы бывают удобны в разных случаях. Если объяснять поближе к императивному подходу — метод можно написать с рекурсией и без рекурсии, только в одном случае один подход будет красив, а в другом случае второй подход будет красив. Но тут уж такие приколы, что функциональный подход для обработки коллекция покрывает большую часть нужд программиста. Именно поэтому LINQ хорош.
Да, статья однобокая. Императивный/функциональный подходы бывают удобны в разных случаях. Если объяснять поближе к императивному подходу — метод можно написать с рекурсией и без рекурсии, только в одном случае один подход будет красив, а в другом случае второй подход будет красив. Но тут уж такие приколы, что функциональный подход для обработки коллекция покрывает большую часть нужд программиста. Именно поэтому LINQ хорош.
Вы знаете как у вас там рантайм открыт? Или как гц работает или ануего, описание есть? Про JIT много информации?
Java тоже развивается — в 9 версии заявлены Value типы. Да и вместо JNI можно использовать framework JNA.
Прямая работа с указателями есть — смотрите на Unsafe класс. Там еще много чего прямого есть ;)
Под прямой работой с указателями подразумевалось что-то типа
unsafe void Foo(IntPtr ptr, int count)
{
var s = (MyStruct*)ptr;
for(var c=0; c<count; c++)
{
s->Field = c;
s++;
}
}Проперти действительно не хватает. А что с дженериками в джаве не так? Действительно интересно.
Type Erasure. Если кратко — во время исполнения нет информации о типах, и все дженерики представлены как Object.
Type erasure :( вся инфа потерта в рантайме. Считайте дженериков и не было.
На Java уж извините, столько энтерпрайза написано, что C# до такого показателя, очень и очень далеко. Да и нет у C# каких либо киллер фич которые давали бы повод перейти с java на C#.
15 лет назад можно было бы заменить в этой фразе C# на джаву, а джаву на кобол и смысл остался бы тот же ;)
И вообще, держите несколько устаревшний список.
Каноническая ссылка: en.wikipedia.org/wiki/Comparison_of_C_Sharp_and_Java
Ваш список откровенно однобокий, а на Википедии полноценное сравнение в обе стороны. И именно в честном сравнении видна отсталость джавы, тому что читерским сравнением можно что угодно вперёд выставить, а когда в честном сравнении почти всё красно-зелёное — это показатель.
Ну уж а с выходом следующих двух версий, где всё от строковых интерполяций до паттерн-матчинга…
Ваш список откровенно однобокий, а на Википедии полноценное сравнение в обе стороны. И именно в честном сравнении видна отсталость джавы, тому что читерским сравнением можно что угодно вперёд выставить, а когда в честном сравнении почти всё красно-зелёное — это показатель.
Ну уж а с выходом следующих двух версий, где всё от строковых интерполяций до паттерн-матчинга…
Pattern-matching отложили пока до 7-ой версии.
Так и планировалось же? Шестая — фенечки, седьмая — прогресс. Из планируемого на шестую версию, но отменённого, там разве что всякие «конструкторы по умолчанию» и прочий сомнительный хлам повыкидывали (ну и объявления переменных как выражения, их жалко, да).
Зато строковую интерполяцию запили, причём с поддержкой локалей. Я уж и не ждал, всё время упирались, что нафиг надо.
Зато строковую интерполяцию запили, причём с поддержкой локалей. Я уж и не ждал, всё время упирались, что нафиг надо.
>Да и нет у C# каких либо киллер фич которые давали бы повод перейти с java на C#.
Да ну? Один Linq чего стоит!
Да ну? Один Linq чего стоит!
Не холивара ради, но в джаве есть Стримы, которые, кажется, могут представлять собой замену Linq.
Мощь Linq заключается в Expression Trees, а насколько мне известно, Стримы ничем похожим не обладают.
Более того, раз уж зашла речь, есть такая конструкция Reactive Extensions которая, я не знаю как сейчас, но имела свой аналог в Java под названием ESPER, где надо было что-то писать в строках на SQL-образном диалекте. Так вот, Rx под дотнетом намного комфортней работать. Сейчас да, возможно будет что-то похожее для Java.
github.com/ReactiveX/RxJava это чтоли?
и в чем же мощь Expression Trees?
в джаве есть Стримы, которые, кажется, могут представлять собой замену Linq
Кроме уже упомянутого отсутствия деревьев выражений, есть ещё нюанс: из-за отсутствия полноценных дженериков в стримах костыль на костыле, когда дело касается примитивных типов. Та же петрушка с функциональными интерфейсами.
Зачем нужен Nemerle, если есть C# и F# (которые уже сейчас фактически open source)? Разве что макросы писать… и то, очень спорная фича.
В C# жутко не хватает концепции всё есть выражение (полноценно и везде её вкрутить уже не получится, сломается обратная совместимость), паттерн-матчинга, гарантированной оптимизации хвостовой рекурсии и ещё по мелочи. F# не плох, но чужероден. Одна необходимость писать нижнимКемельКейсом в .NET-языке вызывает недоумение, да и он ближе к чисто функциональным языкам, чем к смеси парадигм. Nemerle этими проблемами не страдает.
Вы меня очень расстраиваете. Я только начал знакомиться со Scala на уровне A2/L1, толком ничего не писал на ней кроме заданий, но буквально влюбился в этот язык. Как думаете, есть ли шанс, что в Scala вернут поддержку .NET в связи с этими событиями?
MSIL-бакэнд уже два года как заброшен и не похоже, что им кто-то будет заниматься.
У меня вот от скалы смешанные впечатления. Вроде бы всё хорошо, но когда выяснилось, что мне нужно в полуручном режиме писать сериализацию в JSON, а при попытке работы с анонимным типом компилятор предложил разрешить использовать для этого рефлексию, так как без неё он не могёт…
В общем, посмотрите в сторону Nemerle. Оно наверняка вам понравится.
У меня вот от скалы смешанные впечатления. Вроде бы всё хорошо, но когда выяснилось, что мне нужно в полуручном режиме писать сериализацию в JSON, а при попытке работы с анонимным типом компилятор предложил разрешить использовать для этого рефлексию, так как без неё он не могёт…
В общем, посмотрите в сторону Nemerle. Оно наверняка вам понравится.
Наезд на скалу безосновательный. С JSON куча вариантов есть, можно полностью автоматически сериализовать, можно вручную но с проверкой возможности сериализовать во время компиляции, можно объединять оба подхода.
А рефлексия нужна не для анонимных типов, а для структурных, которые используются довольно редко.
А рефлексия нужна не для анонимных типов, а для структурных, которые используются довольно редко.
Ценность Java не в синтаксисе и не только в кроссплатформенности. Ее главная ценность в opensource community.
Взять тот же Spring Framework со всем обвесом (Security, Spring Data, Spring MVC, ...), за развитием которого не успевает канонический Java EE.
А сколько разных реализаций Java EE контейнеров…
Много ли Вы знаете альтернатив ASP.NET MVC, к примеру? В мире .NET кроме собственных продуктов Microsoft очень мало альтернатив.
Взять тот же Spring Framework со всем обвесом (Security, Spring Data, Spring MVC, ...), за развитием которого не успевает канонический Java EE.
А сколько разных реализаций Java EE контейнеров…
Много ли Вы знаете альтернатив ASP.NET MVC, к примеру? В мире .NET кроме собственных продуктов Microsoft очень мало альтернатив.
а нужна ли эти альтернативы, если в мире .NET они будут кое-как поспевать за родным стеком MS? Тем более ASP.NET с легкостью можеть потягаться со Spring.
На мой взгляд, коммьюнити и альтернативы это хорошо, т.к. в разных командах появляются и проверяются разные идеи, и таким образом выживают лучшие идеи. Плюс если разные команды фокусируются на разных приоритетах, то разработчик может выбрать ту альтернативу, в которой реализовано то, что важно именно ему. В мире .NET, если в Microsoft решили, что какая-то фича неважна, то разработчикам приходится годами ждать ее появления. WPF уже много лет не развивается, и тут на хабре не раз проскакивали возмущения этим фактом. В opensource коммьюнити давно бы уже кто-нибудь сделал fork проекта и продолжил его развитие.
Моя мысль в том, что Microsoft не в состоянии заменить все opensource community. Вот если вокруг opensource кроссплатформенного .NET появится массовое коммьюнити и сторонних проектов, это будет круто. В принципе, это уже сейчас реально благодаря проектам Mono и Xamarin. Но говорить о том, что теперь Java обречена, по меньшей мере наивно.
Моя мысль в том, что Microsoft не в состоянии заменить все opensource community. Вот если вокруг opensource кроссплатформенного .NET появится массовое коммьюнити и сторонних проектов, это будет круто. В принципе, это уже сейчас реально благодаря проектам Mono и Xamarin. Но говорить о том, что теперь Java обречена, по меньшей мере наивно.
как только выйдет ASP.NET vNext также opensource-проектом, ничто не мешает (если лицензия позволяет, не помню, что они там заявляли) делать форки с лучшими с точки зрения коммунити решениями на базе существующей кодовой базы.
Да, тенденция понятна. Но Microsoft тут в роли догоняющего все-таки.
догоняющего в плане коммунити — возможно и так. В плане технологий — точно нет. Как я уже заметил, написать альтернативу тому же ASP.NET vNext как есть альтернатива в виде Spring для JEE, — задача, которая ставит сообщество в догоняющие, пока не сделает действительно достойный форк основного стека, который далеко ушел от оригинала
ASP.NET ни в коей мере не аналог ни Java EE не Spring. Это скорее Servlet API + JSP.
В спринг и в ее входит гораздо больший набор технологий.
В спринг и в ее входит гораздо больший набор технологий.
я не знаю, какими критериями вы руководствовались, я лишь грубо их сопоставил. Тем более Spring — это вообще комбайн решений, поэтому да, он в сравнении впереди планеты всей. Глубокий анализ я не проводил, да и не хочу, ибо на стеке java ee писал последний раз более 3х лет назад.
Но я с радостью (это без сарказма) почитал бы информацию, на которой основывается ваше мнение, если оно не ограничивается только личным опытом.
Но я с радостью (это без сарказма) почитал бы информацию, на которой основывается ваше мнение, если оно не ограничивается только личным опытом.
ASP.NET = Servlet API + JSP? У вас низкие знания о .NET. Попрошу внимательно посмотреть на все фичи ASP.NET WebForms, ASP.NET MVC, ASP.NET Web Api, ASP.NET SignalR. Ну и на стандартную библиотеку и многие опенсорсовые библиотеки для .NET.
Сообщение случайно получилось слишком закапсленным.
Сообщение случайно получилось слишком закапсленным.
Я не говорю про стандартную библиотеку .NET (и ее бы сравнивать с Java SE) а именно о ASP.NET. Поверьте — я очень хорошо разбираюсь в .NET мире. Знаю например и о Autofac (а может Unity или NInject), NHibernate и Entity Framework. Наверное я немного сгустил краски, но ASP.NET это набор библиотек для создания web — приложений. Spring — это фреймворк для создания любых приложений и в нем намного больше всего. Как минимум поддержка работы с базами данных (Templates, Transactions) и поддержка AOP. Ну и мессаджинг.
См. Castle Project
Я не говорю про стандартную библиотеку .NET (и ее бы сравнивать с Java SE)
Некоторые вещи в spring/guava и прочих полезных хелперных либах — это разница между стандартной библиотекой .NET и стандартной библиотекой Java SE. Кстати, у вас там уже определись какой класс должен использоваться для работы с временем и датой?
Знаю например и о Autofac (а может Unity или NInject)
и поддержка AOP
Unity умеет AOP в runtime, Windsor умеет AOP в runtime (с этим работал), Fody предоставляет самые примитивные возможности code rewriting (в compile-time; работал с этим), LinFu предоставляет AOP в compile time, PostSharp (вот он правда платный) предоставляет AOP в compile time.
Наверное я немного сгустил краски, но ASP.NET это набор библиотек для создания web — приложений
Ну да. Если хотите создавать десктопные приложения есть WPF. Если кто-то думает, что можно эффективно писать десктопные, мобильные и веб-приложения на одном фреймворке, то мне кажется, что он упоролся и не понимает, что конечно же можно. Но цена этого…
Как минимум поддержка работы с базами данных (Templates, Transactions)
Сборка System.Transactions (стандартная библиотека), linq2sql, Entity Framework.
Ну и мессаджинг
Что вы подразумеваете под мессаджингом? Publish/Observe внутри одной программы, WCF или что-то типа RabbitMQ?
Нет, я верю что Spring огромен. Это DI контейнер (Unity/Autofac/Windsor/Ninject), это MVC (ASP.NET MVC), это еще куча всего. Внутри springа все побито на модули, только походу вы этого не видите и не понимаете. Просто в .NET мире принято по другому именовать модули; не вкидывая общее название в название отдельного проекта.
Кстати, я же правильно перевожу эту фразу «The spring-orm module provides integration layers for popular object-relational mapping APIs, including JPA, JDO, and Hibernate.» как «Для интеграции Hibernate в Spring нужна тонна костылей, держите spring-orm — мы уже их написали»?
>Кстати, у вас там уже определись какой класс должен использоваться для работы с временем и датой?
А вам с какой с таймзон офсетом или без него? LocalDateTime, ZonedDateTime, Instant и еще много других.
А как там в вашей стандартной библиотеки можно unix timestamp в объект времени и даты перевести?
>Unity умеет AOP в runtime, Windsor умеет AOP в runtime (с этим работал), Fody предоставляет самые примитивные возможности code rewriting (в compile-time; работал с этим), LinFu предоставляет AOP в compile time, PostSharp (вот он правда платный) предоставляет AOP в compile time.
Ага, вот Spring c помощью AspectJ умеет это делать в одном месте и сам — без попытки скрестить ежа с ужом в вашем коде.
>Ну да. Если хотите создавать десктопные приложения есть WPF. Если кто-то думает, что можно эффективно писать десктопные, мобильные и веб-приложения на одном фреймворке, то мне кажется, что он упоролся и не понимает, что конечно же можно. Но цена этого…
Воу воу — у нас только 2 типа приложений есть? Есть например сервисы обрабатывающие данные в бекэнде и их тоже можно писать с помощью Spring.
>Внутри springа все побито на модули, только походу вы этого не видите и не понимаете.
Да нет — прекрасно вижу и понимаю. Заслуга Spring в том что создатели скрестили в нормальном виде кучу библиотек и отдали нам готовый, ясный и непротиворечивый продукт, в котором есть решение для практически любой часто повторяющейся проблемы.
В .NET мире все по другому — я не спорю. Разные подходы.
Но если вы обратите внимание на начало этой ветки то вы увидите что было сравнение Spring c ASP.Net, я же в резкой и саркастической форме указал на то, что сравнение не корректно.
А вам с какой с таймзон офсетом или без него? LocalDateTime, ZonedDateTime, Instant и еще много других.
А как там в вашей стандартной библиотеки можно unix timestamp в объект времени и даты перевести?
>Unity умеет AOP в runtime, Windsor умеет AOP в runtime (с этим работал), Fody предоставляет самые примитивные возможности code rewriting (в compile-time; работал с этим), LinFu предоставляет AOP в compile time, PostSharp (вот он правда платный) предоставляет AOP в compile time.
Ага, вот Spring c помощью AspectJ умеет это делать в одном месте и сам — без попытки скрестить ежа с ужом в вашем коде.
>Ну да. Если хотите создавать десктопные приложения есть WPF. Если кто-то думает, что можно эффективно писать десктопные, мобильные и веб-приложения на одном фреймворке, то мне кажется, что он упоролся и не понимает, что конечно же можно. Но цена этого…
Воу воу — у нас только 2 типа приложений есть? Есть например сервисы обрабатывающие данные в бекэнде и их тоже можно писать с помощью Spring.
>Внутри springа все побито на модули, только походу вы этого не видите и не понимаете.
Да нет — прекрасно вижу и понимаю. Заслуга Spring в том что создатели скрестили в нормальном виде кучу библиотек и отдали нам готовый, ясный и непротиворечивый продукт, в котором есть решение для практически любой часто повторяющейся проблемы.
В .NET мире все по другому — я не спорю. Разные подходы.
Но если вы обратите внимание на начало этой ветки то вы увидите что было сравнение Spring c ASP.Net, я же в резкой и саркастической форме указал на то, что сравнение не корректно.
А вам с какой с таймзон офсетом или без него? LocalDateTime, ZonedDateTime, Instant и еще много других.
А еще java.util.Date, java.util.Calendar. Вы правда думаете, что нужно так много классов?
А как там в вашей стандартной библиотеки можно unix timestamp в объект времени и даты перевести?
Норм, C# и .NET хорошо спроектированы. В стандартной библиотеке никак, она спроектирована с учетом того, чтобы предоставить удобное API. В итоге везде можно передавать DateTime и не медитировать над тем чтобы конвертировать дату из одного класса в другой. Если мы хотим конвертировать в unixtime и обратно (правда, не очень сложный алгоритм), то можно написать extension метод для DateTime, который в коде будет выглядеть родным методом над DateTime. А, ну да, можно установить nuget package, который дает эту возможность.
Ага, вот Spring c помощью AspectJ умеет это делать в одном месте и сам — без попытки скрестить ежа с ужом в вашем коде.
Ох-ох. Почему-то для меня это не выглядит как еж с ужом; а как нормальное комбинирование подходящих библиотек. Вероятно если разработчики библиотек задумываются о возможности расширения и комбинирования, все происходит гораздо проще.
Воу воу — у нас только 2 типа приложений есть? Есть например сервисы обрабатывающие данные в бекэнде и их тоже можно писать с помощью Spring.
А зачем там Spring простите? Вот я пишу веб-приложение на ASP.NET MVC + Web API. Зачем сервису эти фреймворки-то? Доступ к системе роутинга и движку рендеринга? Ну дык, это решается подключением парочки библиотек.
Но если вы обратите внимание на начало этой ветки то вы увидите что было сравнение Spring c ASP.Net, я же в резкой и саркастической форме указал на то, что сравнение не корректно.
Меня покоробило сравнение c Servlet API + JSP. Валидации данных нет, биндинга моделей нету, security нету, к населена роботами.
Заслуга Spring в том что создатели скрестили в нормальном виде кучу библиотек и отдали нам готовый, ясный и непротиворечивый продукт, в котором есть решение для практически любой часто повторяющейся проблемы.
И почему вы думаете, что весь стек .NET это сырой, неясный и противоречивый продукт-то? Только потому что у всех библиотек нету префикса SuperPuper? Или потому что библиотеки писались так, чтобы их можно было использовать не только внутри asp.net?
>А еще java.util.Date, java.util.Calendar. Вы правда думаете, что нужно так много классов?
Ок давайте поговорим о System.Collection — которые явный костыль для совместимости с 1.0. Или 2 API для работы с XML.
>Норм, C# и .NET хорошо спроектированы. В стандартной библиотеке никак, она спроектирована с учетом того, чтобы предоставить удобное API. В итоге везде можно передавать DateTime и не медитировать над тем чтобы конвертировать дату из одного класса в другой. Если мы хотим конвертировать в unixtime и обратно (правда, не очень сложный алгоритм), то можно написать extension метод для DateTime, который в коде будет выглядеть родным методом над DateTime. А, ну да, можно установить nuget package, который дает эту возможность.
Бла-Бла-Бла — вам это не нужно, а если нужно, то просто самому написать, а если сложно самому написать у нас есть менеджер зависимостей. Вот это да, вот это я понимаю ответ! Не несите такого пожалуйста. У .Net в стандартной библиотеки есть очень хорошо написанные куски — но есть моменты где стандартного функционала явно не хватает.
> Зачем сервису эти фреймворки-то?
Оо — как зачем. А весь life-time management мне самому писать? Или разбор конфигурации в 21м веке?
> Вот я пишу веб-приложение на ASP.NET MVC + Web API. Зачем сервису эти фреймворки-то? Доступ к системе роутинга и движку рендеринга?
Не зачем — я их не подключу в бекэнд задаче
>Ну дык, это решается подключением парочки библиотек.
Да вы сделаете так — потом будем думать как сделать в winsdor lifetime scope на wcf — сессию по мультеплексированному коннекшенну, ну или создавать дерево классов руками приковывая зависимости
>Меня покоробило сравнение c Servlet API + JSP. Валидации данных нет, биндинга моделей нету, security нету, к населена роботами.
Ну я тоже признал что сравнение не корректное 2 комментариями выше.
>И почему вы думаете, что весь стек .NET это сырой, неясный и противоречивый продукт-то?
Ну где я это написал? .Net стек я люблю — у меня блин 9 лет опыта разработки на нем. Я прекрасно его знаю и знаю какие проблемы возникают при попытках скрестить разные библиотеки. Spring пытается решить эти проблемы. В .Net ему к сожалению аналогов нет. Может и не нужно — тк задача у него в generic виде дать вам ужа-ежа. В Java тоже много веселого. Попробуйте скрестить Guice и Netty, так чтобы на каждый channel создавался свой scope — найдете кучу увлекательного времяпрепровождения. Задача которую решает Spring очень сложная — создать среду где вы пишите минимум кода и все инструменты у вас под рукой и интегрированы в эту среду. Пока на .Net необходимости в такой среде нет. Но на Java жить без нее уже сложно.
Ок давайте поговорим о System.Collection — которые явный костыль для совместимости с 1.0. Или 2 API для работы с XML.
>Норм, C# и .NET хорошо спроектированы. В стандартной библиотеке никак, она спроектирована с учетом того, чтобы предоставить удобное API. В итоге везде можно передавать DateTime и не медитировать над тем чтобы конвертировать дату из одного класса в другой. Если мы хотим конвертировать в unixtime и обратно (правда, не очень сложный алгоритм), то можно написать extension метод для DateTime, который в коде будет выглядеть родным методом над DateTime. А, ну да, можно установить nuget package, который дает эту возможность.
Бла-Бла-Бла — вам это не нужно, а если нужно, то просто самому написать, а если сложно самому написать у нас есть менеджер зависимостей. Вот это да, вот это я понимаю ответ! Не несите такого пожалуйста. У .Net в стандартной библиотеки есть очень хорошо написанные куски — но есть моменты где стандартного функционала явно не хватает.
> Зачем сервису эти фреймворки-то?
Оо — как зачем. А весь life-time management мне самому писать? Или разбор конфигурации в 21м веке?
> Вот я пишу веб-приложение на ASP.NET MVC + Web API. Зачем сервису эти фреймворки-то? Доступ к системе роутинга и движку рендеринга?
Не зачем — я их не подключу в бекэнд задаче
>Ну дык, это решается подключением парочки библиотек.
Да вы сделаете так — потом будем думать как сделать в winsdor lifetime scope на wcf — сессию по мультеплексированному коннекшенну, ну или создавать дерево классов руками приковывая зависимости
>Меня покоробило сравнение c Servlet API + JSP. Валидации данных нет, биндинга моделей нету, security нету, к населена роботами.
Ну я тоже признал что сравнение не корректное 2 комментариями выше.
>И почему вы думаете, что весь стек .NET это сырой, неясный и противоречивый продукт-то?
Ну где я это написал? .Net стек я люблю — у меня блин 9 лет опыта разработки на нем. Я прекрасно его знаю и знаю какие проблемы возникают при попытках скрестить разные библиотеки. Spring пытается решить эти проблемы. В .Net ему к сожалению аналогов нет. Может и не нужно — тк задача у него в generic виде дать вам ужа-ежа. В Java тоже много веселого. Попробуйте скрестить Guice и Netty, так чтобы на каждый channel создавался свой scope — найдете кучу увлекательного времяпрепровождения. Задача которую решает Spring очень сложная — создать среду где вы пишите минимум кода и все инструменты у вас под рукой и интегрированы в эту среду. Пока на .Net необходимости в такой среде нет. Но на Java жить без нее уже сложно.
Ок давайте поговорим о System.Collection — которые явный костыль для совместимости с 1.0.
Ок, давайте поговорим о том, что в Java нету genericов в runtime и value-types тоже нету. Просто в .NET решили оставить старый код; а в Java решили жить без настоящего type safety (что смешно для языка в котором нету даже автовывода типов).
Бла-Бла-Бла — вам это не нужно, а если нужно, то просто самому написать, а если сложно самому написать у нас есть менеджер зависимостей. Вот это да, вот это я понимаю ответ! Не несите такого пожалуйста. У .Net в стандартной библиотеки есть очень хорошо написанные куски — но есть моменты где стандартного функционала явно не хватает.
Вы меня неправильно поняли. .NET пишется так: давайте сделаем поменьше, но качественнее. Так, но мы так не предоставим весь нужный функционал. Хорошо, мы остаемся в той же парадигме разработки, только делаем все, чтобы дать возможность программисту расширить существующий функционал без боли.
Оо — как зачем. А весь life-time management мне самому писать? Или разбор конфигурации в 21м веке?
O_o. Я же правильно понимаю, что мы говорим сейчас про IoC-контейнер? При описании зависимостей для Windsor считается хорошим тоном группировать описания зависимостей в специфичном классе (который реализует интерфейс IWindsorInstaller), а потом вызывать container.Install. При этом можно из одного инсталлятора вызывать другой инсталлятор, таким образом выделить сущности нужные и тому, и тому, и отдельно сервисам, и отдельно вебу. Ну или можно юзать одну и ту же конфигурацию. Проблем с управлением life-time в сервисных проектах не испытывал, так что не понимаю, о чем вы говорите.
Да вы сделаете так — потом будем думать как сделать в winsdor lifetime scope на wcf — сессию по мультеплексированному коннекшенну, ну или создавать дерево классов руками приковывая зависимости
O_o. Ручное DI это вредно. С WCF не работал серьезно, поэтому не могу ничего сказать по этому поводу. Но, вы уверенны, что есть большая проблема в прикручивании Windsorа/другого DI-контейнера к WCF?
Задача которую решает Spring очень сложная — создать среду где вы пишите минимум кода и все инструменты у вас под рукой и интегрированы в эту среду. Пока на .Net необходимости в такой среде нет. Но на Java жить без нее уже сложно.
Увы-увы, я не верю, что можно написать универсальный всем подходящий продукт, который не будет говном. Вы уверены, что Spring вот такой вот офигенный, что используется во всех компаниях которые пишут на Java? А то я знаю как минимум одну компанию не по наслышке, которая живет без Springи в куче проектов и чувствует себя нормально.
А, ну и о интегрированности продуктов. Asp.net MVC и Entity Framework вроде разные продукты, только студия из коробки имеет средства генерации контроллера и вьюх по EF-сущности. Может оно все не настолько уебищно как кажется?
А как там в вашей стандартной библиотеки можно unix timestamp в объект времени и даты перевести?
В 4.6 будет, если не путаю. Но там код в одну строчку, так что в целом пофиг.
Откройте Codeplex.com, NuGet.org (большинство доступных там библиотек открыто), поищите на том же гихабе. Есть у .Net сообщество.
Я не говорю, что его нет. Но масштабы пока несопоставимы. Посмотрите хотя бы на проекты вроде Hadoop + HBase, Hive, Impala, Spark, Pig, ZooKeeper… Это проекты, в которые помимо Apache и Cloudera вкладываются такие гиганты, как Facebook, Twitter, LinkedIn, Yahoo.
Примеров такого уровня из .NET я не знаю.
Примеров такого уровня из .NET я не знаю.
Ага, да, Spring, да, конечно. А потом начинается: на проекте Java 5/6, Spring устаревших версий.
Половина туториалов ущербны чуть более чем полностью, четверть относится к новым версиям, из оставшейся части большая часть относится к старым версиям. Ой, а что это за исключение «java.lang.NoSuchMethodError».
На Java много чего хорошего написано. Например Elasticsearch, который можно юзать и в .NET и в куче других языков.
А на erlangе написан RabbitMq, но в .NETе и кучи других языков можно использовать RabbitMq.
Дело в том, что необязательно использовать Java, чтобы использовать продукты написанные на Java.
И оп-па одно из преимуществ Java внезапно улетучивается, если правильно смотреть.
P.S: я думаю, что написать конвертер Java Bytecode -> .NET IL не такая уж трудная задача при необходимости.
Половина туториалов ущербны чуть более чем полностью, четверть относится к новым версиям, из оставшейся части большая часть относится к старым версиям. Ой, а что это за исключение «java.lang.NoSuchMethodError».
На Java много чего хорошего написано. Например Elasticsearch, который можно юзать и в .NET и в куче других языков.
А на erlangе написан RabbitMq, но в .NETе и кучи других языков можно использовать RabbitMq.
Дело в том, что необязательно использовать Java, чтобы использовать продукты написанные на Java.
И оп-па одно из преимуществ Java внезапно улетучивается, если правильно смотреть.
P.S: я думаю, что написать конвертер Java Bytecode -> .NET IL не такая уж трудная задача при необходимости.
Все уже написано и работает. www.ikvm.net/userguide/ikvmc.html It converts the Java bytecodes in the input files to .NET CIL
Ну если Scala и Clojure на .net нормально поддерживаться будут, да еще TCO на нем использовать — надо будет переходить.
IDE я все равно пользоваться так и не научился, без студии обойдусь.
IDE я все равно пользоваться так и не научился, без студии обойдусь.
Linux линуксом, подскажите, а про официальную поддержку разработки под мобильные платформы информация есть?
Внезапно.
Ущипните меня, это похоже на сон!
Кто-то когда-то шутил о том, что RMS покусал ребят из Microsoft, похоже что это была не шутка.
Кто-то когда-то шутил о том, что RMS покусал ребят из Microsoft, похоже что это была не шутка.
Я и шутил. Только вот по ходу оказалось не шуткой.
Вот ещё одна интересная картинка с конференции.
Уиииии!!! :))))) Если сделают свободную кроссплатформенную реализацию без Xamarin-рабства, будет просто конфетка!
Так в оригинале и написано: Visual Studio 2015 and .NET 2015: build for any device (Built from the ground up with support for iOS, Android and Windows)
Возможно, они таки купят Xamarin и сделают все именно на их базе.
Реально от Xamarin хочется полноценную некоммерческую версию для некоммерческой разработки и обучения. Для коммерческой разработки у них вроде бы вполне адекватные цены.
Для обучения у них есть разные программы бесплатные. Попробуйте просто им написать
Xamarin бесплатен для студентов и преподавателей xamarin.com/student
А что учиться могут только студенты и преподаватели? А если я просто сам хочу пообучаться в свободное время?
Триал — 30 дней бесплатно. (в последней статье они писали про то, что могут подарить ещё 30 дней).
Starter Edition, для маленьких по размеру приложений — бесплатно.
Starter Edition, для маленьких по размеру приложений — бесплатно.
Это никак не отменяет написанного мной в исходном комментарии, который был ответом на
Мне бы не хотелось чтобы MS покупал Xamarin, пусть лучше остаются независимыми но сделают нормальную версию для инди как Unity.
Возможно, они таки купят Xamarin и сделают все именно на их базе.
Мне бы не хотелось чтобы MS покупал Xamarin, пусть лучше остаются независимыми но сделают нормальную версию для инди как Unity.
на слайде за остальные платформы отвечает Xamarin.
Сперва посмотрел на календарь, убедился, что не первое апреля; не поверил; посмотрел на компе жены, убедился.
Я шокирован и удивлен (приятно).
Это значит, что WPF-приложения можно будет использовать на *nix?
Я шокирован и удивлен (приятно).
Это значит, что WPF-приложения можно будет использовать на *nix?
WPF если и будет, то в самую последнюю очередь.
Технические причины к этому вижу, имплементировать его на базе *nix будет непросто.
Интересно, есть ли именно намерения его в принципе имплементировать или дело в их отсутствии.
Интересно, есть ли именно намерения его в принципе имплементировать или дело в их отсутствии.
имплементировать его на базе *nix будет непросто.Им бы то, что есть открыть, там народ подтянется. Реализация Silverlight для Linux с рендерингом на OpenGL уже много лет существует.
На самом деле не так уж и сложно. Там слой графики хорошо изолирован от собственно XAML и всего такого, и портировать надо в основном его (ну и работу с WM).
К сожалению отдельно сказано, что открыт и портирован на никсы будет только серверный сабсет (asp.net 5.0). На Wpf и winforms планов, как я понял, нет
А толку и нет, на самом деле. В десктопных приложениях на каждый чих winapi тянется. Не с winelib линковать же.
То, что WinForms гвоздями прибит к WinApi это ясно, но я не очень понимаю, почему нельзя портировать Wpf? Wpf вроде не сильно завязан на WinApi. Кто-нибудь может прояснить ситуацию чайнику?
Дык есть реализация подмножества WPF, используемого в сервелате, Moonlight называется. Если открыть WPF и взять рендеринг из мунлайта, можно относительно малой кровью завести.
WPF-ное приложение можно запустить на линуксе под вайном с виндовым дотнетом? А то как-то фигово гуглится. С одной стороны, встречаются ответы «WPF под линуком не работает», с другой — в багтрекере вайна можно встретить исправленные баги типа «под .NET такой-то версии не грузятся картинки в WPF», что как бы намекает, что что-то работает (и в комментариях увлекательное чтиво — эпическая декомпиляция с анализом недокументированных методов в недокументированных интерфейсах).
WPF поторохами упирается в энное количество виндовых интерфейсов, как я понимаю, то есть при наличии сорцов WPF с одной стороны и вайна со всеми виндовыми поторохами с другой, портирование WPF становится уже не настолько фантастическим. Ну и линуксоидные стили прикрутить.
WPF поторохами упирается в энное количество виндовых интерфейсов, как я понимаю, то есть при наличии сорцов WPF с одной стороны и вайна со всеми виндовыми поторохами с другой, портирование WPF становится уже не настолько фантастическим. Ну и линуксоидные стили прикрутить.
Для открытия и портирования winforms им, наверное, половину winapi портировать и открыть придётся.
Есть WinPR, можно на его базе что-то сделать.
А что мешает оставить существующие интерфейсы, а реализацию написать новую?
Подозреваю, что это долго, дорого и почти никому не нужно. Всё-таки winforms приложения не основной козырь .NET платформы.
Проблема в том, что в WinForms практически все классы — это обёртки к винапишным контролам. В Mono есть managed-реализация, но она местами хромает.
Вот уж надеюсь, что нельзя будет. Статья «7 лет WPF» уже сколько висит, уже далеко не 7 лет, а воз и ныне там.
Сделать бы аналог, с вменяемым синтаксисом и платформенной независимостью (раз уж как раз назрела необходимость) — цены бы не было. А портировать индусский код на линукс — не стоит. Насколько прекрасен Asp.Net, настолько ужасен WPF.
Сделать бы аналог, с вменяемым синтаксисом и платформенной независимостью (раз уж как раз назрела необходимость) — цены бы не было. А портировать индусский код на линукс — не стоит. Насколько прекрасен Asp.Net, настолько ужасен WPF.
Сама идея с декларативным UI на XAML и MVP была хороша. Сейчас в Xamarin.Forms используется.
Возможность использовать имеющиеся приложения, написанные на WPF, где-либо, кроме винды — уже благо.
Есть GTK#. На нем Monodevelop написан, например.
Вот только не особо удобно его юзать, даже если прикрутить Glade.
Когда последний раз его тыкал, с небольшими костылями удалось сложный интерфейс вменяемо реализовать. На линуксах вышло отлично; на венде тема для gtk была на тот момент кривовата. Не уверен как сейчас.
Вот только не особо удобно его юзать, даже если прикрутить Glade.
Когда последний раз его тыкал, с небольшими костылями удалось сложный интерфейс вменяемо реализовать. На линуксах вышло отлично; на венде тема для gtk была на тот момент кривовата. Не уверен как сейчас.
Вау! Вот это поворот! :)
Не верится, что я до этого дожил! :D
Майкрософт в последнее приятно время удивляет! Еще бы сделали свободную реализацию для мобильных платформ (помимо виндафона) и будет просто БОМБА! ^____^
Не верится, что я до этого дожил! :D
Майкрософт в последнее приятно время удивляет! Еще бы сделали свободную реализацию для мобильных платформ (помимо виндафона) и будет просто БОМБА! ^____^
[тэг «диванная аналитика»]
Кмк, они увидели готовность рынка к приёму этого продукта и перспективу отжать у него (рынка) бОльшую долю.
Смотрите: несколько лет назад почти весь веб (кроме энтерпрайза и узких нишевых вещей) писался на PHP. Какие-то более суровые языки — ой, да зачем они нам? Изучать долго, инфраструктура сложнее и дороже… Оставим их большим корпорациям, а мы тут по-быстренькому на LAMP-е и замечательно. Поддерживать в таких условиях .NET под Линукс — это большой гемор, который в обозримом будущем не окупится.
Что сейчас? Народ избаловался, проникся любовью к плюшкам, новомодных технологий не чурается, железо подешевело. Всякие там питоны, руби, го, ноды, хаскелы-шмаскелы внезапно получили не только академическую, но и совершенно практическую популярность.
И почему бы не подвинуть их си-шарпом?!
Кмк, они увидели готовность рынка к приёму этого продукта и перспективу отжать у него (рынка) бОльшую долю.
Смотрите: несколько лет назад почти весь веб (кроме энтерпрайза и узких нишевых вещей) писался на PHP. Какие-то более суровые языки — ой, да зачем они нам? Изучать долго, инфраструктура сложнее и дороже… Оставим их большим корпорациям, а мы тут по-быстренькому на LAMP-е и замечательно. Поддерживать в таких условиях .NET под Линукс — это большой гемор, который в обозримом будущем не окупится.
Что сейчас? Народ избаловался, проникся любовью к плюшкам, новомодных технологий не чурается, железо подешевело. Всякие там питоны, руби, го, ноды, хаскелы-шмаскелы внезапно получили не только академическую, но и совершенно практическую популярность.
И почему бы не подвинуть их си-шарпом?!
Ну с вебом то особенно ничего и не поменялось. Все также большинство написано на том же пхп, а для некоторых узких целей используются другие языки, типа ноды и т.д.
Сколько я не наблюдаю за новыми модно-хипстерскими веяниями в вебе, ничего пока путного не получается, и вами названые питоны, руби, ноды и т.д. используются для специфических задач.
Врядли кто-то будет писать простенький сайт с фоточками котов на Го или хаскеле, да даже на ноде врядли, оно просто незачем.
Сколько я не наблюдаю за новыми модно-хипстерскими веяниями в вебе, ничего пока путного не получается, и вами названые питоны, руби, ноды и т.д. используются для специфических задач.
Врядли кто-то будет писать простенький сайт с фоточками котов на Го или хаскеле, да даже на ноде врядли, оно просто незачем.
Хмм, а когда Haskell успел стать супер-популярным?
Это просто праздник какой-то!
Ну это просто праздник какой-то! Больше слов нет, одни чувства =)
Восхитительно! Вот так корпорации зла становятся корпорациями добра :)
Действительно! Не только MIT лицензия, но и отказ от судебного преследования за использование патентов!
Теперь халтурка и под linux будет у меня…
В стане джавистов аж всем поплохело )
Не поплохело :) Наоборот, джависты всячески приветствуют эту тенденцию. Наконец-то народ начнёт понимать внятно, как внутри оно работает. Ещё лет 5 чтобы догнать рантайм Java и еще лет 10, чтобы отвоевать долю рынка. По фичам языка дотнет — впереди. По фичам рантайма — впереди джава.
В общем, и я и все мои знакомые джависты очень рады за вас! Поздравляю!
В общем, и я и все мои знакомые джависты очень рады за вас! Поздравляю!
Это по каким таким фичам рантайма впереди джава? Что, неужели там генерики появились? Value Types? App Domains? Ngen? RyuJIT?
- Value Types — принято. Но на худой конец, кому очень нужен перфоманс, вопрос решается массивами.
- App Domains — не принято: не понимаю, что в этом такого особенного
- Ngen — принято: хорош для клиентских приложений. Для серверных не принципиален. Но фича интересная.
- RyuJIT — не принято. Да, он лучше чем предыдущий, но непонятно, как он выглядит на фоне JIT-ов для HotSpot или других JVM.
Ограниченные привилегии куску кода. Компиляция в SIMD есть?
привилегии куску кодаAppDomain
Компиляция в SIMD есть?Mono.Simd
Дак я спрашиваю про джаву. И RyuJIT умеет сам в SIMD.
SIMD есть, конечно. Особенно в последних версиях JVM. Но есть тонкости: на целой арифметике оно работает, а вот на вещественной нет. Потому что вещественная арифметика в Java не ассоциативна. И при анроллингах не получается переупорядочить последовательные сложения.
про привилегии: надо смотреть, как устроена Java Security Model. Там каждый кусок кода может требовать определённые пермиссии. И если SecurityManager их не даёт, то летит исключение времени выполнения.
Видимо, имеется ввиду HotSpot VM с его адаптивной оптимизацией кода (горячие участки проходят более дорогую и продвинутую оптимизацию) и особым, уличным GC.
много, много всего. Я не спец по дотнету, но из того, про что в дотнете сходу не помню — Biased Locking, on stack replacement. Но самое интересное — это, конечно, JIT. Фишка в том, что он очень разный. Только в HotSpot 2 JIT-компилятора, а в других VM — тоже есть свои. И это видно: на разных JVM очень разные сценарии частенько получаются. Ну и с GC та же история. Сейчас в продакшенах по всему миру трудится десяток разных GC :)
On stack replacement к дотнету не применим в принципе, весь прогоняется через JIT всегда (если до этого не обработан NGen или Mono-вским AOT-компилятором, конечно), интерпретатора нет (единственный интерпретатор MSIL о котором я слышал использовался в Mono на заре проекта). С мониторами тоже проблем нет, они практически бесплатны если не заняты другим потоком. JIT же сейчас переписывается с большим прицелом x64 (шёл 2014-ый год, да)
- про x64 забавно, да :))) Легаси оно такое легаси...
- про On stack replacement — интересно! Расскажите, плиз!
- про мониторы понятно, наверняка почти ничего не стоит без контеншена и спинлупы в промежуточном случае
- про JIT и GC — мой «упрёк» в том, что мало разнообразия. И настроек кстати немного.
Слушайте, а как дела обстоят со спекулятивными оптимизациями?
про On stack replacement — интересно! Расскажите, плиз!Ну, если я всё правильно помню, то в Java оно нужно в случае, если рантайм решает, что метод надо бы уже скомпилировать, а он на данный момент выполняется и выполняться будет ещё долго. В .NET компиляция в машинные коды производится при первом вызове. Это же и его недостаток — JIT вынужден применять ко всему коду один и тот же набор оптимизаций, а не заниматься глубокой оптимизацией конкретного участка.
почти. Может быть так: от менее оптимизированного JIT-кода к более оптимизированному. То есть от скомпилированного к скомпилированному. Но вообще, да, видимо в дотнете компилируется один раз и поэтому не актуально.
А что с Escape Analysis?
А что с Escape Analysis?
А можете пояснить, это какая-то особенность .NET, или возможна какая-то другая релизация JIT, которая будет использовать отложенную компиляцию кода, например как в Java?
Так реализовано как в CLR, так и в Mono, в принципе, ничто не мешает сделать иначе, просто не было особой нужды ввиду изначального отсутствия интерпретации кода.
23derevo вы случайно не знаете, есть ли какая-нибудь статистика по тому, какой прирост производительности даёт подобная фича в Java(имеется ввиду отложенная компиляция)?
Я просто не могу понять почему MS её не реализовало? Это дорого? Это того не стоит? Лень поддерживать две версии JIT?
Я просто не могу понять почему MS её не реализовало? Это дорого? Это того не стоит? Лень поддерживать две версии JIT?
У меня подозрение, что так исторически сложилось, в Java изначально был интерпретируемый байткод, в .NET изначально JIT-компиляция.
Дорого и легаси. Сделать такой JIT, чтобы он на всех сценариях какой-то другой — не выйдет. Даже приближение к этому — это много-много лет работы. Если же просто заменить один JIT на другой, то у многих кастомеров начнятся деградация производительности. Они начнут гнать на майкрософт, а майкрософт этого не хочет.
Я не очень понял аргумент насчет легаси, возможно же создание нового JIT не вместо, а как альтернатива уже имеющемуся. Т.е. по-умолчанию пусть работает как есть, а для продвинутых можно использовать другю опцию.
Это правда. Но тогда придётся поддерживать два джита. А это дорого.
RyuJIT именно это из себя и представляет — альтернативный джит. И ничего, поддерживают. Понятно, что в перспективе он станет основным.
Это не «альтернативный JIT», это следующая версия. Просто его переписали с нуля и пафосно назвали. Насколько я понимаю, новый JIT целиком и полностью заменяет старый во всех областях применения, и причин использовать старый не будет.
Так вроде об этом и разговор выше по треду — что новый улучшенный JIT можно изначально зарелизить как альтернативу, чтобы не ломать легаси (как это и сделали для RyuJIT), а потом уже назначить его основной реализацией, и дропнуть старую еще через релиз.
Так будут две версии сосуществовать или нет? Я думал, что к релизу старый JIT выпиливают и RyuJIT полностью его заменяет, то есть они сосуществуют только на стадии беты, когда никакой масштабной поддержки не надо, только баг-трекер для энтузиастов.
Думаю, происходит как с различными API — в новом релизе старое помечают как deprecated, а в следующем уже выпиливают. Т.е 2 версии сосуществуют лишь в одном релизе, который будет переходным.
В .NET 4.6 RyuJIT по умолчанию (т.е. уже не бета), но старый пока оставили как опцию. В перспективе — да, его тоже выпилят когда-нибудь, но некоторое время будет поддержка обоих.
Мне доводилось слышать мнение, что джавский байткод изначально затачивался под эффективный его интерпретатор, а вот в дотнете такой задачи не ставилось, поэтому там его дизайн не шибко этому способствует.
Не берусь сказать, в чем именно это проявляется, но слышал я это от человека, занимающегося VM в .NET.
Не берусь сказать, в чем именно это проявляется, но слышал я это от человека, занимающегося VM в .NET.
Как вариант, можно предварительно скомпилировать код, один раз сделал и все.
А вообще, со скорым приходом нативной компиляции о JIT можно будет не париться)
А вообще, со скорым приходом нативной компиляции о JIT можно будет не париться)
Часть кодогенерации всё равно останется в рантайме. Например, дженерики компилируются на каждую специализацию, да и генерация MSIL во время выполнения сейчас весьма активно используется в сериализаторах, ORM, DI-контейнерах и прочих инфраструктурных вещах.
Конечно же нет. Глубокий инлайнинг и оптимизации на основе динамического профиля. То есть, на основе статистики вызываемого кода. Например, есть целый класс спекулятивных оптимизаций, которые ahead-of-time компиляторы не могут сделать.
Mono жалко
Не похоже, что они сами себя жалеют.
Ну как, в комментариях же внизу написано, что «Пока .NET не заменит Mono везде, где оно работает, Mono будет существовать». Не слишком радужно, что уж и говорить)
Мигель вроде бы объяснил, что .NET не планирует заменять mono, активно будет совместно дорабатываться (до кроссплатформенности) только .NET Core, а .NET Framework Class Libraries останутся win-only, а mono оттуда надергает на замену того, что было еще недоделано.
Xamarin едва ли уйдет с mono в ближайшее время.
MSFT заявили что они активно работают совместно с Mono чтобы смерджить код. Вангую что через n лет люди из Mono просто мягко перетекут в MSFT и продолжать делать то что делали.
Там ещё компиляцию в нативный код обещают. Так что если переход на C был обусловлен требованиями производительности, можно возвращаться.
А сейчас во что компилируется? Не в нативный код?
В MSIL, который на целевой машине уже JIT компилирует.
А, типа AOT. Понял. И почему же это так волшебно улучшит производительность?
Потому что в рантайме не будет затрат на JIT. Как минимум, должно ускорить запуск приложений.
Но overhead на GC и всякие проверки границ массивов останется, разумеется.
Но overhead на GC и всякие проверки границ массивов останется, разумеется.
У JIT есть ограничения на время работы из-за которых нельзя делать агрессивно оптимизацию. В случае со статической они снимаются.
Ну если в данный момент JIT в C# компилирует без профиля, то да, оффлайн должен улучшить производительность. Хотя без спекулятивного инлайнинга, переупорядочивания бранчей и прочих оптимизаций, основанных на профиле, как в Java и С/С++, не говоря уж об оверхеде рантайма и GC, не понятно, о каком возврате на C# с C можно говорить.
Ну PGO-то должны прикрутить, если уж AOT делают.
Если прикрутят, перейду с Java на C# :)
Кстати, интересно, что в C# с гарантиями точности трассировки стека? Ведь есть штучки, которые AOT «не имеет права», скажем так, оптимизировать, например.
Кстати, интересно, что в C# с гарантиями точности трассировки стека? Ведь есть штучки, которые AOT «не имеет права», скажем так, оптимизировать, например.
В .NET Native для генерации кода используется бэкенд от VC++, если что.
Спольски мечтал об этом с 2004 года.
А рассматривать внутренности, а конкретно работу с кодировками, то как, интересно, будут обстоять дела в MS .NET под *nix? В Mono, понятное дело, везде внутри используется utf-8 для хранения строк, даже методы маршаллинга вроде Marshal.StringToHGlobalAnsi на самом деле на выходе дают utf-8. Как все это будет шевелиться, интересно)
В любом случае для порта на *nix придется проделать большую работу по абстракции от платформы в mscorlib как минимум…
В любом случае для порта на *nix придется проделать большую работу по абстракции от платформы в mscorlib как минимум…
Волшебно, конечно. Но пока только щелочку приоткрыли. До полноценного кодирования на .net под никсами еще лет пять, наверное.
Наконец-то не только Java разработчиков будут мучать вопросами по внутренней реализации коллекций, многопоточности и прочего. На самом деле это хорошо, готовьтесь, коллеги :)
Три раза дату перепроверил. Это невероятная новость и очень неожиданная, хоть и одна из самых желанных. Времена меняются и эти перемены радуют.
Супер. Не терпится попробовать :)
Это конечно безумно радует. Но не понятна мотивация.
MS давно пытается отвоевать рынок серверов. И .Net был на мой взгляд самым существенным аргументом.
Если он будет портирован в хорошем качестве (все понимают что в mono в разы больше багов и производительность заметно ниже), то это должно ударить по продажам Windows Server. Как-то это странно.
Вспоминается комментарий Спольски про самоубийство Sun, зарабатывавшей на серверах, но выпустившей кросплатформенную Java.
Не повторит ли MS её путь?
С другой стороны если MS сконцентрируется на том, что ей удаётся хорошо, и уйдёт с поляны Open Source, да ещё оставив миру такую потрясную вещь как .NET, то это будет замечательно. Для всех кроме самого MS.
MS давно пытается отвоевать рынок серверов. И .Net был на мой взгляд самым существенным аргументом.
Если он будет портирован в хорошем качестве (все понимают что в mono в разы больше багов и производительность заметно ниже), то это должно ударить по продажам Windows Server. Как-то это странно.
Вспоминается комментарий Спольски про самоубийство Sun, зарабатывавшей на серверах, но выпустившей кросплатформенную Java.
Не повторит ли MS её путь?
С другой стороны если MS сконцентрируется на том, что ей удаётся хорошо, и уйдёт с поляны Open Source, да ещё оставив миру такую потрясную вещь как .NET, то это будет замечательно. Для всех кроме самого MS.
У MS огромная проблема с разработчиками в мобильном и серверном сегменте. Думаю, немало народа обожглись, вкусив их бездумную политику vendor lock-in'а, ну и синдром Not Invented Here сыграл свою злую шутку, что мало кто хочет с ними связываться, тратить время на изучение технологии, которую могут очень легко ещё живой и здоровой похоронить на уровне менеджмента, и технология, таки, умрёт в этом гробу, т.к. сообщество форк не сделает по причине закрытого кода. Если так будет продолжаться и дальше, хуже для компании в условиях меняющегося рынка не сделаешь.
Видимо, дела идут совсем плохо, что MS решила отдать .NET в open source. Возможно, решат сосредоточиться на более перспективных направлениях, чем Windows Server (опять же, крупные компании никуда не денутся, т.к. им нужен enterprise со всеми вытекающими), например, будут прокачивать облачный сегмент со своей Azure.
Так у них хоть есть шанс заинтересовать разработчиков своими технологиями. Особенно в мобильной среде. А может, здесь и хитрый план есть, по завоеванию мирового господства, который пока ещё неясен. Посмотрим.
Видимо, дела идут совсем плохо, что MS решила отдать .NET в open source. Возможно, решат сосредоточиться на более перспективных направлениях, чем Windows Server (опять же, крупные компании никуда не денутся, т.к. им нужен enterprise со всеми вытекающими), например, будут прокачивать облачный сегмент со своей Azure.
Так у них хоть есть шанс заинтересовать разработчиков своими технологиями. Особенно в мобильной среде. А может, здесь и хитрый план есть, по завоеванию мирового господства, который пока ещё неясен. Посмотрим.
Извините, но у вас комментарий в стиле давно известной олимпиады «венде скоро капец».
Дела идут у MS вполне себе неплохо, а уж в плане развития .NET они вообще впереди планеты всей. IDE — одна из лучших, C# — самый развивающийся язык программирования. Виндовыми серверами как пользовались так и пользуются и не обязательно большой энтерпрайз: мелкий и средний бизнес также им пользуется — стоимость поддержки все еще ниже чем линукс. Плюс, с webmatrix, хостить всякий пэхэпэ стало делом нескольких кликов.
У Микрософта интересная стратегия — помимо своей инфраструктуры, они активно лезут на поля конкурентов. Запилили офис на Android и iOS, теперь вот дотнет портируют. Хитрый план.
Дела идут у MS вполне себе неплохо, а уж в плане развития .NET они вообще впереди планеты всей. IDE — одна из лучших, C# — самый развивающийся язык программирования. Виндовыми серверами как пользовались так и пользуются и не обязательно большой энтерпрайз: мелкий и средний бизнес также им пользуется — стоимость поддержки все еще ниже чем линукс. Плюс, с webmatrix, хостить всякий пэхэпэ стало делом нескольких кликов.
У Микрософта интересная стратегия — помимо своей инфраструктуры, они активно лезут на поля конкурентов. Запилили офис на Android и iOS, теперь вот дотнет портируют. Хитрый план.
не понятна мотивацияEmbrace, extend, extinguish?
Я кончил.
Может тогда и SQL Server с SSAS в openSource? А вдруг? Ну или хотя бы olap движок вынести в отдельный открытый продукт.
techrights.org/2014/11/12/openwashing-lockin/
Если верить анализу по этой ссылке, то не все так радужно. Во-первых, открывают не весь фреймворк, а только его часть.
Во-вторых, «студия бесплатна для скачивания» это не то же, что «опенсорс».
Если верить анализу по этой ссылке, то не все так радужно. Во-первых, открывают не весь фреймворк, а только его часть.
Во-вторых, «студия бесплатна для скачивания» это не то же, что «опенсорс».
А зачем опенсорсовая IDE? Для расширения функциональности есть плагины. Даже если среду заопенсорсить, то 99% кода всё равно будут писать в Майкрософте. Риска, что забьют на разработку, нет. Разработка тесно переплетена с кучей проектов.
Если от заопенсорсивания языка профит очевидный, то среды — уже не очень. Майкрософту, соответственно, тоже невыгодно впустую тратить ресурсы.
Если от заопенсорсивания языка профит очевидный, то среды — уже не очень. Майкрософту, соответственно, тоже невыгодно впустую тратить ресурсы.
там опенсорс только серверных компонентов. десктопный .NET остается закрытым.
Десктопный код сильно завязан на winapi и портировать его нереально дорого.
Ждем опенсорсных разработок и портов WPF :)
Ждем опенсорсных разработок и портов WPF :)
Открывают весь фреймворк, просто не сразу. Постепенно выкатят все.
Видимо за некоторые комментарии в коде стыдно. Вот почистят и… :)
Комментарии уже чистили, когда выкладывали сорцы под Ms-RSL.
sourceof.net
Некоторые забавные комментарии выживали, надо сказать. И в основном чистили, вроде, чтобы не палить уязвимости.
sourceof.net
Некоторые забавные комментарии выживали, надо сказать. И в основном чистили, вроде, чтобы не палить уязвимости.
Давно пора.
Как-то непоследовательно…
При разработке энтерпрайз приложений на. Net под Линукс вместо MS sqlserver предполагается использовать постгре? Или они предполагают не потерять продажи серверов базы данных?
При разработке энтерпрайз приложений на. Net под Линукс вместо MS sqlserver предполагается использовать постгре? Или они предполагают не потерять продажи серверов базы данных?
Эта новость сделала мой день.
Same 
палите какую-то голосовалку )
Скрытый текст
... jQuery17201666310257698811_1415889108864({«cmd»:«vote»,«status»:«ACK»,«data»:{«questionaryId»:«197»,«scheduleId»:«194»,«questionId»:«20644»,«uniqueType»:«4»,«voteType»:1,«rate»:«22»}})
Что интересно, на мой взгляд Mono давно уже более «каноничен», чем .Net. Задумайтесь, в .Net для Windows Store/Windows Phone уже нет System.Xml, System.Data, System.Drawing, изменена работа с System.IO, нельзя подключить библиотеки от «нормальных» .Net 2-4.5. И все это, чтобы «было удобнее разрабатывать».
Гм… Да, в текущем виде ситуация печальная, я как бывший разработчик Windows Store/Windows Phone говорю. Но, .NET сделался таким по многим причинам. Портировать весь .NET на планшеты (ARM) и телефоны нереально и в общем-то не особо нужно. Т.е. да многих фич не хватает, но когда нужные добавят то останется еще куча фич, которые есть в десктопном .NET, но которые не нужны на планшетах и телефонах.
По поводу System.Xml ничего не знаю, но с сериализацией/десериализацией в XML и JSON проблем не было.
В Windows RT практически весь UI реализован нативно (для скорости, естественно), а .NET видит только интерфейсы к ним. Предлагает тащить туда GDI+, Windows Forms и WPF? System.Drawing не нужен
В PCL нету System.Data и вы считаете это ужасным? Вы правда хотите написать мобильное приложение которое напрямую общается с удаленным SQL Serverом? Поддержка SQlite в Windows Store/Windows Phone есть (возможно кривая).
Изменена работа с System.IO, банально потому что часть фич не нужна (потому что слоупочно и никому не нужно); потому что работа с файловой системой другая (заточенная на больший контроль за приложением).
Так же изменено API для работы с рефлексией.
Вы сейчас видите изменения которые происходят с .NETом. И это:
1) Портирование .NET фич на другие платформы в порядке приоритета и необходимости.
2) Рефакторинг кода
3) Удаление старого ненужного кода.
По поводу System.Xml ничего не знаю, но с сериализацией/десериализацией в XML и JSON проблем не было.
В Windows RT практически весь UI реализован нативно (для скорости, естественно), а .NET видит только интерфейсы к ним. Предлагает тащить туда GDI+, Windows Forms и WPF? System.Drawing не нужен
В PCL нету System.Data и вы считаете это ужасным? Вы правда хотите написать мобильное приложение которое напрямую общается с удаленным SQL Serverом? Поддержка SQlite в Windows Store/Windows Phone есть (возможно кривая).
Изменена работа с System.IO, банально потому что часть фич не нужна (потому что слоупочно и никому не нужно); потому что работа с файловой системой другая (заточенная на больший контроль за приложением).
Так же изменено API для работы с рефлексией.
Вы сейчас видите изменения которые происходят с .NETом. И это:
1) Портирование .NET фич на другие платформы в порядке приоритета и необходимости.
2) Рефакторинг кода
3) Удаление старого ненужного кода.
Погодите, я не утверждал, что работать в таком формате нельзя. Вполне можно, почему бы и нет? Но если в библиотеке не сделан велосипед вроде собственного Rectangle и Point, то большая вероятность, что она использует System.Drawing и без перекомпиляции работать не станет. Или если где-то вдруг был задействован File.ReadAllText, XmlDocument, а к базе был коннект через System.Data.SQLite, а не самописный враппер над нативными вызовами, то будут проблемы. О не совместимости Silverlight/WPF кода с Windows Store я вообще молчу.
В то же время на Mono уже 5 (!!) лет пишутся программы для Android и iOS, к любой из которых можно подключить готовые части кода и библиотеки из мира .Net. Хотите архивацию ZIP — берете в чистом виде ICSharpZipLib, хотите ORM — берете NHibernate, нужна работа с базой — берете коннектор вроде System.Data.SQLite или любой другой. По большому счету портирование десктопных .Net приложений там было задачей замены и переработки GUI, а не перехода на целиком другую технологию (хотя это и не самый лучший путь на мой взгляд). В стане же Windows Store для работы c SQLite первые пол-года вообще не было ничего схожего с базами данных, пока сами SQLite не собрали с грехом пополам враппер. Вдумайтесь, нам предлагали делать W8 приложения без локального хранения структурированных данных вообще!
Я рад, что над фреймворком работают, развивают его. Но одновременно хочу рассказать историю про некий кросс-платформенный движок: во время аудита его C++ исходников мы удивились, что не использованы в принципе STL, Boost, не говоря о QT, wxWidgets и пр. Все, что можно и нельзя написано с нуля. Автор ответил просто: не хотел заморачиваться совместимостью с разными версиями STL от STLPort, Dinkum, SGI и пр., потому для настоящей кросс-платформенности сделал все сам, с иерархией дефайнов, подключаемыми на разных платформах файлами и пр.
Так вот, сейчас для приложений мобильная бизнес-логика на C# для Android, iOS и WP/W8 выглядит именно так — куча велосипедов, гроздья дефайнов, дополнительные файлы именно для WP8/W8, где, например, сделана имитация System.Console.WriteLine через Debug.WriteLine и т.д.
В то же время на Mono уже 5 (!!) лет пишутся программы для Android и iOS, к любой из которых можно подключить готовые части кода и библиотеки из мира .Net. Хотите архивацию ZIP — берете в чистом виде ICSharpZipLib, хотите ORM — берете NHibernate, нужна работа с базой — берете коннектор вроде System.Data.SQLite или любой другой. По большому счету портирование десктопных .Net приложений там было задачей замены и переработки GUI, а не перехода на целиком другую технологию (хотя это и не самый лучший путь на мой взгляд). В стане же Windows Store для работы c SQLite первые пол-года вообще не было ничего схожего с базами данных, пока сами SQLite не собрали с грехом пополам враппер. Вдумайтесь, нам предлагали делать W8 приложения без локального хранения структурированных данных вообще!
Я рад, что над фреймворком работают, развивают его. Но одновременно хочу рассказать историю про некий кросс-платформенный движок: во время аудита его C++ исходников мы удивились, что не использованы в принципе STL, Boost, не говоря о QT, wxWidgets и пр. Все, что можно и нельзя написано с нуля. Автор ответил просто: не хотел заморачиваться совместимостью с разными версиями STL от STLPort, Dinkum, SGI и пр., потому для настоящей кросс-платформенности сделал все сам, с иерархией дефайнов, подключаемыми на разных платформах файлами и пр.
Так вот, сейчас для приложений мобильная бизнес-логика на C# для Android, iOS и WP/W8 выглядит именно так — куча велосипедов, гроздья дефайнов, дополнительные файлы именно для WP8/W8, где, например, сделана имитация System.Console.WriteLine через Debug.WriteLine и т.д.
Новая бесплатная редакция Visual Studio с поддержкой расширений;
Цитата по ссылке:
This edition of Visual Studio is available at no cost for non-enterprise application development.
Люди, как правильно произносится RyuJIT?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
.NET Framework скоро Open Source и на *nix