Comments 15
как тормазил 5 лет, так и продолжает тормозить
С dynamic похоже не дружит.
вы не могли бы поделиться примером кода или солюшеном в котором у вас проблема с dynamic, чтобы мы могли воспроизвести проблему и исправить?
Уже снес, но походу было везде в aspx.
везде в aspx — это не кейз, интересно какие конкретно были проблемы и в каких случаях
С aspx сейчас вообще все грустно. Не хватает кнопки «отключить анализ aspx» по крайней мере для бэтт
а что именно грустно? расскажите с примерами
криво парсит html
— подсвечивает как ошибку Conditional comments, я эту багу в трекере еще полгода назад заводил. Да и вообще пытается парсить комментарии и естественно что-то там находит не то.
— некоторые теги парсит некорректно, например <img align=«absmiddle»… подсвечивает как ошибку.
Причем пока что от билда к билду все хуже. На одном и том же проекте находятся все больше и больше ошибок, которые на самом деле не ошибки.
Может вообще html-ные ошибки как варнинги трактовать?
— подсвечивает как ошибку Conditional comments, я эту багу в трекере еще полгода назад заводил. Да и вообще пытается парсить комментарии и естественно что-то там находит не то.
— некоторые теги парсит некорректно, например <img align=«absmiddle»… подсвечивает как ошибку.
Причем пока что от билда к билду все хуже. На одном и том же проекте находятся все больше и больше ошибок, которые на самом деле не ошибки.
Может вообще html-ные ошибки как варнинги трактовать?
Вы знаете, попробовали, тормозит жутко, не на самом плохом двухъядерном железе. Странно всё это. Выше правильно про тормоза сказали. Как-то незаметно производительность повысилась…
даже пытаться ставить не буду, не даёт он такого выигрыша в производительности, который бы покрыл его тормоза. В студии и так почти всё нужное есть.
На самом деле R#5 сам по себе существенно быстрее предыдущих версий. Проблема в новой студии, новом редакторе и старых студийных болячках. В каких-то местах студию существенно улучшили, а в каких-то она наоборот стала просто чудовищьно тормозить. Переход на WPF заставил вылизать остальной код, но так как основные тормоза по прежнему в редакторе, то сильно это делу не помогло.
Ну и плюс, кривой студийный API — без слез не взглянешь… Ну это все разговоры в пользу бедных.
На данный момент важно одно — те бенефиты которые я получаю от использования R# настолько превышают дискомфорт от чуть более чем обычно тормозящей студии, что я полюбому голосую за решарпер.
Ну и плюс, кривой студийный API — без слез не взглянешь… Ну это все разговоры в пользу бедных.
На данный момент важно одно — те бенефиты которые я получаю от использования R# настолько превышают дискомфорт от чуть более чем обычно тормозящей студии, что я полюбому голосую за решарпер.
Вообще, ситуация в студии лично меня немного удручает…
Ситуация такова, что действительно эффективно работать в студии, можно только при наличии решарпера и ряда подобных инструментов. И это нормально, это правильно.
Проблема в том, что даже идеально написанный тул, типа решарпера, ужасно сложно интегрировать в студию, чтобы он еще при этом и эффективно работал… Кто не верит, может попробовать поставить CodeRush — на тех проектах, где решарпер еще ведет себя довольно приемлимо (пара десятков мегабайт исходников), CR перестает подавать признаки жизни, но речь не о том.
Речь о том, что в этой ситуации в MS принимается решение реализовать в студии то, что уже есть в R#. Этим занимается две команды на редкость талантливых людей, реально серьезных товарищей, без дураков. Одна команда делает рефакторинги, вторая compiler as service.
Что мы ждем от compiler as service? Лично мне эта штука интересна в качестве инструмента для метапрограммирования, для того чтобы вклинится в пайплайн компилятора и поменять на лету AST. Но эту фичу не дадут, а все примеры использования ориентированы на то, как полазить по исходному коду и поделать рефакторинг. Кто-то собирается делать собственные рефакторинги для студии? Если кто и собирается, то у того же R# есть уже готовая инфраструктура, включая механизм плагинов, а без инфраструктуры это вообще мало кому интересно.
И так, что мы имеем.
MS в IDE занимается тем, что лечит симптомы вместо болезни. Примерно к 12-й версии VS мы получим в студии функционал, который уже сейчас есть в тулах типа решарпера. И на это уйдут ресурсы в количестве двух команд по пару десятков человек в каждой в течении 3-4 лет. Причем, повторюсь, не абы кого, а реально крутых товарищей, я знаю, я проверял. И это вместо того, чтобы отправить этих товарищий на вылизывание API и SDK студии таким образом, чтобы плагины типа решарпера не тормозили и не состояли процентов на пятьдесят из обхода косяков студии. Или такой факт, вы знаете, например, что одна из основных причин бедности C# 4 на фичи заключается в том, что у команды студии не хватило ресурсов эти фичи поддержать у себя? И в такой ситуации большое количество ресурсов бросается на реализацию того, что и так уже есть.
Да, я понимаю, это очень популярное решение — все хотят решарпер нахаляву… Но это решение очень не дальновидное. Это еще больше отодвинет появление нормальной студии. Разработчики из MS огребут ровно те же самые проблемы, что сейчас ребята из JB и их решение не будет сильно быстрее или качественнее, скорее наоборот… Кроме того, это подкосит рынок плагинов — кто захочит писать хороший плагин к студии, если через некоторое время придет MS и напишет точно такой же плагин, но другой?
Прошу прощения за поток сознания, я просто под впечатлением, наболело…
P. S.
Я не имею никакого отношения к JetBrains вообще и к решарперу в частности… :)
Ситуация такова, что действительно эффективно работать в студии, можно только при наличии решарпера и ряда подобных инструментов. И это нормально, это правильно.
Проблема в том, что даже идеально написанный тул, типа решарпера, ужасно сложно интегрировать в студию, чтобы он еще при этом и эффективно работал… Кто не верит, может попробовать поставить CodeRush — на тех проектах, где решарпер еще ведет себя довольно приемлимо (пара десятков мегабайт исходников), CR перестает подавать признаки жизни, но речь не о том.
Речь о том, что в этой ситуации в MS принимается решение реализовать в студии то, что уже есть в R#. Этим занимается две команды на редкость талантливых людей, реально серьезных товарищей, без дураков. Одна команда делает рефакторинги, вторая compiler as service.
Что мы ждем от compiler as service? Лично мне эта штука интересна в качестве инструмента для метапрограммирования, для того чтобы вклинится в пайплайн компилятора и поменять на лету AST. Но эту фичу не дадут, а все примеры использования ориентированы на то, как полазить по исходному коду и поделать рефакторинг. Кто-то собирается делать собственные рефакторинги для студии? Если кто и собирается, то у того же R# есть уже готовая инфраструктура, включая механизм плагинов, а без инфраструктуры это вообще мало кому интересно.
И так, что мы имеем.
MS в IDE занимается тем, что лечит симптомы вместо болезни. Примерно к 12-й версии VS мы получим в студии функционал, который уже сейчас есть в тулах типа решарпера. И на это уйдут ресурсы в количестве двух команд по пару десятков человек в каждой в течении 3-4 лет. Причем, повторюсь, не абы кого, а реально крутых товарищей, я знаю, я проверял. И это вместо того, чтобы отправить этих товарищий на вылизывание API и SDK студии таким образом, чтобы плагины типа решарпера не тормозили и не состояли процентов на пятьдесят из обхода косяков студии. Или такой факт, вы знаете, например, что одна из основных причин бедности C# 4 на фичи заключается в том, что у команды студии не хватило ресурсов эти фичи поддержать у себя? И в такой ситуации большое количество ресурсов бросается на реализацию того, что и так уже есть.
Да, я понимаю, это очень популярное решение — все хотят решарпер нахаляву… Но это решение очень не дальновидное. Это еще больше отодвинет появление нормальной студии. Разработчики из MS огребут ровно те же самые проблемы, что сейчас ребята из JB и их решение не будет сильно быстрее или качественнее, скорее наоборот… Кроме того, это подкосит рынок плагинов — кто захочит писать хороший плагин к студии, если через некоторое время придет MS и напишет точно такой же плагин, но другой?
Прошу прощения за поток сознания, я просто под впечатлением, наболело…
P. S.
Я не имею никакого отношения к JetBrains вообще и к решарперу в частности… :)
не ну в 2010 студии улучшения редактора есть, но не на столько чтобы отказаться от R#
Sign up to leave a comment.
Вышла вторая бета Resharper 5