Can someone explain the concept of mindrot?
Does Visual Studio Rot the Mind? (2005)
41–50 of 122 posts
Re: Does Visual Studio Rot the Mind? (2005)
#42Anecdote from this week: I've been working on a Python project that uses several classes and subclasses, with code paths that move around a lot through the class hierarchy. I was trying to add some functionality but kept getting bogged down trying to make sure all the subclasses implement the same interface, using Atom as the text editor. Then I installed PyCharm and completed the task in just a few hours thanks to t…
You definitely don't need to go to a full IDE just to get find-definition and find-references. Those are basic features of any ctags-enabled editor, and nowadays with the momentum behind LSPs you get carrier-grade versions of it without even needing to generate a tag file. (In fact, Neovim's next version will actually ship with an LSP client, you won't even need an extension for it). I just bind 'gd' and 'gr' to go t…
Emacs has dumb-jump, which is just... Fantastic. Absolutely fantastic.
It doesn't perform any deep semantic analysis; it just abuses whatever existing grep-like tools you have and a bare minimum understanding of the language syntax to find likely correct definitions.
Re: Does Visual Studio Rot the Mind? (2005)
#43> In order to get IntelliSense to work correctly, bottom-up programming is best. IntelliSense wants every class, every method, every property, every field, every method parameter, every local variable properly defined before you refer to it. If that’s not the case, then IntelliSense will try to correct what you’re typing by using something that has been defined, and which is probably just plain wrong. Maybe I'm spoil…
Also in VS 2005 you didn't have compilation on-the-fly - so you wouldn't get the annoying squiggly lines for undeclared properties. That only came in 2008 SP1 I think. And Generate property was also added to VS quite a long time ago - but sometimes it doesn't have enough information of course like
if (object.nonexistant != null) ....Re: Does Visual Studio Rot the Mind? (2005)
#44While some of his complaints now have solutions[1], when WPF (previously known as Avalon) is used with care, the resulting XAML is much more diff-able and code-review-able. The CodeDOM serialization method is dense and small changes can cause huge code diffs.
On the other hand, WPF is a lot more complex than WinForms. There are a lot of different ways to use, many of which involve data binding that is not evaluated till runtime. There are ways to make some databinding type-checked at compile time, but it is not built in. WinForms data binding is pretty limited, so generally it is easier to track down what piece of code is causing something to display on the screen.
WinForms (and the Win32 resource scripts that can before it) are more limited in what they can easily express. So the resulting UIs tend to be a bit visually and behaviorly similar. This is nice for devs because you have a design already laid out for you. It's also nice for users since the apps are more consistent and predictable. WPF gives you a big blank canvas where it is hard to make something look decent. And enables making your app look completely different than anything else.
So in conclusion, I agree that WPF enables more understandable code to be created by people who care. Unfortunately it is often to used to add a bunch of needless complexity.
[1]: For example, the GenerateMember option in the WinForms design can be used to suppress generating fields for controls.
Re: Does Visual Studio Rot the Mind? (2005)
#45Can someone explain the concept of mindrot?
it's like trying to navigate around town after you've turned the GPS off.
Re: Does Visual Studio Rot the Mind? (2005)
#46Yeah I read the shit like okay, they gonna bring this full circle to 2020 or...... wtf did I just read..
You're aware that this article is from 2005, right? It's prominently stated at the top of the article.
Re: Does Visual Studio Rot the Mind? (2005)
#47Petzold's books on Windows GUI programming were pretty much the Bibles if you wanted to understand how stuff worked under the covers of Visual Studio's designers/codegen. Great author from the perspective of someone how needs to know the innards, not just churn out code.
His book "Code" is an amazing exploration of how computers work. One of the best books I've ever read.
Re: Does Visual Studio Rot the Mind? (2005)
#48This was prescient back then. Because the Visual Studio mindset was all about patterns and conforming to patterns, the IDE behaved as though you were only a patterns-based programmer. It wants to force you to follow _their_ patterns. And in that, the VS juggernaut of code-generation has enlarged so colossally that you need only start a new REST API project to see the mind-numbing amounts of DTO objects and code required for layer after layer of interfaces/controllers etc for a single dataset.
If a single dataset from a single table in your SQL Server database requires so much code, isn't it time we rethought the _concept_ behind the _need_ for code-generation - especially in the IDE?
Re: Does Visual Studio Rot the Mind? (2005)
#49> But Avalon is currently missing some amenities we take for granted, such as standard File Open, File Close, and Font dialogs, a split panel, and it has nothing approaching the new and totally astonishing DataGridView control in Windows Forms 2.0.
15 years later we still don't have a decent directory chooser, no DataGridView and a nice default theme.
If you these things (and more), you have to buy a set of components from a third party that costs about $1000, which is not possible in my company.
Re: Does Visual Studio Rot the Mind? (2005)
#50I started on Vim, then moved to Spacemacs, then Emacs with Vim bindings, now on VScode with Vim bindings... honestly, a good IDE does a lot of things for developer productivity.
We have to remember that, while we are defined by our tools, we are all still building the same thing: code. What your employer/boss/client cares about is /what/ code you produce and what business value it generates. They don't really care about /how/ you do it.