Pull to refresh
23
0
Виктор Лова @nsinreal

Пользователь

Send message
А Roslyn не cross platform или тяжко допиливается? roslyn.codeplex.com/

Code fix / Code refactoring — это все делает и так, и Roslyn не нужен, просто пока я ленюсь.

Суть в том, что будет куча полезных расширений с помощью Microsoft CodeAnalysis, который вроде бы open source. Т.е. можно заюзать extensionы от студии / или девелопить и под студии, и под вашу IDE с минимум затрат. Т.е. это тупо позволит сократить время доведения IDE до ума силами сторонних разработчиков
Для того чтобы взлетело, прикрути Roslyn и функционал code fix/code refactoring от студии 2015 (которая вот-вот выйдет) и легкую поддержку VSIX. Скоро повыходит куча расширений полезных на студию, которые снизят необходимость решарпера.
Один из фейлов некоторых сервисов заключается в том, что они неправильно берут имя пользователя. Банальщина — я покупаю какой-нибудь продукт у компании; при это до оплаты был создан аккаунт (с моими правильными ФИО); расплачиваюсь я чужой карточкой (с чужими ФИО). В итоге приходит мне приходит персонализированное письмо на имя владельца карты…
Да вы сделаете так — потом будем думать как сделать в winsdor lifetime scope на wcf — сессию по мультеплексированному коннекшенну, ну или создавать дерево классов руками приковывая зависимости

O_o. Ручное DI это вредно. С WCF не работал серьезно, поэтому не могу ничего сказать по этому поводу. Но, вы уверенны, что есть большая проблема в прикручивании Windsorа/другого DI-контейнера к WCF?

Задача которую решает Spring очень сложная — создать среду где вы пишите минимум кода и все инструменты у вас под рукой и интегрированы в эту среду. Пока на .Net необходимости в такой среде нет. Но на Java жить без нее уже сложно.

Увы-увы, я не верю, что можно написать универсальный всем подходящий продукт, который не будет говном. Вы уверены, что Spring вот такой вот офигенный, что используется во всех компаниях которые пишут на Java? А то я знаю как минимум одну компанию не по наслышке, которая живет без Springи в куче проектов и чувствует себя нормально.

А, ну и о интегрированности продуктов. Asp.net MVC и Entity Framework вроде разные продукты, только студия из коробки имеет средства генерации контроллера и вьюх по EF-сущности. Может оно все не настолько уебищно как кажется?

Ок давайте поговорим о 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 в сервисных проектах не испытывал, так что не понимаю, о чем вы говорите.
А вам с какой с таймзон офсетом или без него? 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?
Я не говорю про стандартную библиотеку .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 — мы уже их написали»?
ASP.NET = Servlet API + JSP? У вас низкие знания о .NET. Попрошу внимательно посмотреть на все фичи ASP.NET WebForms, ASP.NET MVC, ASP.NET Web Api, ASP.NET SignalR. Ну и на стандартную библиотеку и многие опенсорсовые библиотеки для .NET.

Сообщение случайно получилось слишком закапсленным.
Смотрю на статью, вижу там нахождение суммы значения функции от элемента массива, когда элемент больше 10. Я правда не понимаю, почему это заговнокодено. И в императивном и «декларативном» подходе оба кода оптимальные с точки зрения количества строк кода (хотя форматирование страдает), прозрачности намерений и производительности которую можно выжать при данном подходе. Если переписать код слева так, чтобы в нем была возможность повторного использования вы получите оверхед по количеству строк и понимаемости кода.

Да, статья однобокая. Императивный/функциональный подходы бывают удобны в разных случаях. Если объяснять поближе к императивному подходу — метод можно написать с рекурсией и без рекурсии, только в одном случае один подход будет красив, а в другом случае второй подход будет красив. Но тут уж такие приколы, что функциональный подход для обработки коллекция покрывает большую часть нужд программиста. Именно поэтому LINQ хорош.
Напомню лямбды в яве пол года.
Какие программисты придут на его место? Что они будет со всем этим делать?

Если разобраться с лямбдами для вас представляется сложным, то может лучше пойти вон из профессии?
Гм… Да, в текущем виде ситуация печальная, я как бывший разработчик 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) Удаление старого ненужного кода.
Ага, да, Spring, да, конечно. А потом начинается: на проекте Java 5/6, Spring устаревших версий.
Половина туториалов ущербны чуть более чем полностью, четверть относится к новым версиям, из оставшейся части большая часть относится к старым версиям. Ой, а что это за исключение «java.lang.NoSuchMethodError».

На Java много чего хорошего написано. Например Elasticsearch, который можно юзать и в .NET и в куче других языков.
А на erlangе написан RabbitMq, но в .NETе и кучи других языков можно использовать RabbitMq.
Дело в том, что необязательно использовать Java, чтобы использовать продукты написанные на Java.
И оп-па одно из преимуществ Java внезапно улетучивается, если правильно смотреть.

P.S: я думаю, что написать конвертер Java Bytecode -> .NET IL не такая уж трудная задача при необходимости.
Боюсь в этом году точно не получится, но в следующем был бы рад выступить.
Не согласен я с тем, что value type — это панацея

Все перечисления (enums) в .NET — это value types, DateTime — struct, Timespan — struct Point — struct, Color — struct, KeyValuePair<,> — struct, Enumeratorы во многих случаях структуры. В .NETовской библиотеке очень много value types, это снижает оверхед на GC. Хотите чтобы переменным типа какой-то структуры можно было присвоить null? Есть Nullable<> (к примеру Nullable<int> или алиас — int?) — который тоже структура

Если у джависта где-то «GC работает как угорелый», то он в этом месте убирает аллокацию избыточную, например, имитируя value type массивами.

И получаем ерунду потому что мы не можем вызывать add() на массиве, нет? А если мы описываем сложную структуру из трех полей? Три массива держать? Ну блин, это же не вариант, это говнокод в полный рост. LINQ и ленивые коллекции есть? Они тоже снижают оверхед на тот же GC на обработке коллекций при грамотном использовании (и да, при грамотном использовании обычные коллекции лучше и быстрее, но говнокодистее, а потому неюзабельнее). Нет, фичи делающие возможностью адекватную реализацию LINQ появились только в Java 8. В результате адекватно обрабатывать коллекции можно только заводя промежуточные коллекции или пользуясь новомодными трансьюдерами.

Что касается GC — всё окей у джавы. Я не очень понимаю, почему Вы так агрессивно на джавовые сборщики наезжаете.

Извините, не могу подкрепить другими фактами, просто знаю, что на сам Java GC очень сильно ругаются. Мои основные аргументы — что GC в Java сильнее нагружается, чем в .NET (ну собственно говоря песнь про value types и разделение сборок между процессами).

Сколько у дотнетовского рантайма ручек, управляющих сборкой мусора? Количество GC-потоков можно регулировать?

У дотнетовского рантайма очень мало ручек по поводу сборщика мусора, да, всего лишь один класс GC и парочка елементов в xml-конфигурации (ну и класс GCSettings). Есть общая информация по поводу того как это все работает, парочка приколов по типу того, что сборщик мусора в Release режиме может собрать объект до завершения его конструктора. Ну и слабые ссылки для избавления от утечек памяти. Но мне реально увидеть проблемы с памятью довелось всего лишь пару раз когда в коде реально держались ссылки на ненужные объекты в root-объектах.

Посмотрите доклад Кирилла Скрыгана в посте — там memory traffic в полный рост

Я не спорю что есть случаи когда проблема с памятью и сборщиком мусора реально есть. Просто мне с такими вещами повезло практически не сталкиваться благодаря грамотно написаному коду, что своему, что стороннему.

По .NETовскому рантайму действительно очень мало документации — тут я согласен. Поэтому когда хочешь залезть в дебри реально сталкиваешься с вакуумом и нету понятия откуда начинать гуглить. По C# и IL документации более-менее достаточно, да и всегда можно посмотреть во что конкретно компилируется код. Ну так уж получилось, что большинству .NET-разработчиков достаточно тех ручек, которые есть. Я спихиваю это на то, что Java не очень-то хорошо продумана, но может быть дело и в разных задачах которые решаются на разных платформах.

Btw, я немного злюсь на фразы которые восхваляют программистов Java по сравнению с .NET. Началось все с книги Боба Мартина «Принципы, паттерны и методики гибкой разработки на языке C#», в которой он обосрал .NET-чиков, а потом написал кучу ерунды в книге. Так что я немного предвзят по отношению к Java.

Мне бы лично были бы более интересны доклады по пост-обработке скомпилированного кода (те же PostSharp и Fody), по автогенерации кода. Кстати, у тех же JetBrains есть очень клевый продукт — Metaprogramming System Language, который мне очень интересен.
Иными словами, закрытость CLR приводит к тому, что народ в дотнет-мире не очень привык лезть в дебри, а больше ориентирован на практические вещи

А вы не думали, что причина в том, что все работает более-менее адекватно? Я слышал жалобы дотнетчиков на GC в Java, что он не адекватный и постоянно течет память по сравнению с .NET.

В Java нету структур, поэтому напедалить вещи которые не будут испытывать потребности в сборщике мусора нереально.

В Java нету нормальных genericов, поэтому даже коллекция примитивных типов — это коллекция Integer, а не int (т.е. reference type, а не value type), поэтому даже тут GC работает как угорелый, нет? В Java вообще нету нормальных genericов, обеспечивающих type safety. К примеру: http://ideone.com/HAPYjw

В .NET сборки загруженные в память шарятся (благодаря GAC), в Java вроде бы нет. Поэтому если запустить одновременно две программы на .NET они будут кушать памяти меньше, чем суммарно они едят при запуске по отдельности. В Java при запуске двух программ одновременно они жрут столько памяти, сколько можно. Кроме того, GAC позволяет избавляться от кучи проблем с версионированием (типа NoSuchMethodError)

Нет, я понимаю жалобы на недокументированность рантайма. К примеру, нельзя напедалить фичу самостоятельного удаления объектов).

Я считаю, что хардкорные вещи прокатывают на Java конференциях потому что в Java все изначально криво. Отсутствие структур, кривой GC, кривое версионирование, неработающая проблемная политика non-breaking changes, отсутствие generics, отсутствие нормальной асинхронности, отсутствие автовывода типов, неудобный синтаксис языка. В стандартных либах Java вместо удобной работы с датами и временем какая-то фигня.
cbrwizard: это же перевод )
Помимо всего прочего, почему вы думаете, что предел нейронов для мозга = текущее количество нейронов +- погрешность?
Вы исходите из предположения, что навешивание функций на нейроны происходит только на основе программы заложенной в ДНК и совсем не зависит от того, как он развивается во время своей жизни. Соответственно если в детстве докинуть нейронов и добавить питания, то мозг может подхватить новые нейроны и чувствовать себя хорошо и лучше. А вот во взрослом возрасте такого может вообще не произойти, как раз по причине «уже все распределено». Хотя возможно стресс-нагрузка на мозг активирует дополнительные нейроны. Но это все предположения, да )
Почему вы не думаете, что мозг сам не навешает и не перераспределит?
Как для чего? Чем больше нейронов, тем больше можно создать групп нейронов отвечающих за какую-то функцию. А сейчас учишь новую функцию — есть риск потери старой, из-за того, что нейроны переадаптируются под новую. Конечно на уровне нейронов нету таких навыков как «английский язык», «японский язык», «императивное программирование», «функциональное программирование», но чисто теоретически человек сможет развиваться в разных областях быстрее и без потери результатов обучения от старой.
Плюс память работает на нейронах, поэтому происходит повышение объема оперативной памяти. Т.е. перезатирание памяти для новых данных будет происходить реже. Круто же

Information

Rating
Does not participate
Location
Харьков, Харьковская обл., Украина
Registered
Activity