fgtx | 10 years ago | on: The DROWN Attack
fgtx's comments
fgtx | 10 years ago | on: Show HN: Send your items worldwide with travelers or make money while traveling
fgtx | 10 years ago | on: The 4$ smartphone
fgtx | 10 years ago | on: Imba: A new programming language for web apps
fgtx | 10 years ago | on: Project Rider – A C# IDE
> Will ReSharper take advantage of Roslyn? The short answer to this tremendously popular question is, no, ReSharper will not use Roslyn. There are at least two major reasons behind this.
The first reason is the effort it would take, in terms of rewriting, testing and stabilizing. We’ve been developing and evolving ReSharper for 10 years, and we have a very successful platform for implementing our inspections and refactorings. In many ways, Roslyn is very similar to the model we already have for ReSharper: we build abstract syntax trees of the code and create a semantic model for type resolution which we use to implement the many inspections and refactorings. Replacing that much code would take an enormous amount of time, and risk destabilizing currently working code. We’d rather concentrate on the functionality we want to add or optimize, rather than spend the next release cycle reimplementing what we’ve already got working.
The second reason is architectural. Many things that ReSharper does cannot be supported with Roslyn, as they’re too dependent on concepts in our own code model. Examples of these features include Solution-Wide Error Analysis, code inspections requiring fast lookup of inheritors, and code inspections that require having the “big picture” such as finding unused public classes. In cases where Roslyn does provide suitable core APIs, they don’t provide the benefit of having years of optimization behind them: say, finding all derived types of a given type in Roslyn implies enumerating through all classes and checking whether each of them is derived. On the ReSharper side, this functionality belongs to the core and is highly optimized.
The code model underlying ReSharper features is conceptually different from Roslyn’s code model. This is highlighted by drastically different approaches to processing and updating syntax trees. In contrast to ReSharper, Roslyn syntax trees are immutable, meaning that a new tree is built for every change.
Another core difference is that Roslyn covers exactly two languages, C# and VB.NET, whereas ReSharper architecture is multilingual, supporting cross-language references and non-trivial language mixtures such as Razor. Moreover, ReSharper provides an internal feature framework that streamlines consistent feature coverage for each new supported language. This is something that Roslyn doesn’t have by definition.
fgtx | 10 years ago | on: Alcoholism drug brings dormant HIV virus out of hiding
Couldn't this be due to the virus actually multiplying instead of waking up?
fgtx | 10 years ago | on: Show HN: Fetch – A Chrome plugin to manage your history
fgtx | 10 years ago | on: Swiftkey's new neural network keyboard
fgtx | 10 years ago | on: Ask HN: Canvas Drawing Library
fgtx | 10 years ago | on: Show HN: Cancel your Comcast in 5 minutes
fgtx | 10 years ago | on: Synthesizing Hi-Hats with Web Audio
fgtx | 10 years ago | on: Show HN: Live Simple – Tiny homes
fgtx | 10 years ago | on: How to Write Unmaintainable Code (1999)
fgtx | 10 years ago | on: The Apple iOS 9 Review
fgtx | 10 years ago | on: Show HN: Chic Translator – Translations that don't suck
fgtx | 10 years ago | on: Ship of Theseus
Would that be the same link or is it a new one?
fgtx | 10 years ago | on: Show HN: ReelSurvey – Acquire customer insights from exiting visitors
PS: Unless you're playing one of those 'erase your c:\windows folder and your computer will be faster' jokes. Then you win.
fgtx | 10 years ago | on: Show HN: ReelSurvey – Acquire customer insights from exiting visitors
fgtx | 10 years ago | on: Webmaker for Android
fgtx | 10 years ago | on: Show HN: Image Processing for Everybody
Also, IMHO a high level abstraction would be preferred when porting/coding said logic to another programming language.