> You have to hunt around in a zillion different (laggy as all hell) interfaces to find the right location where that code can live. Or maybe it's not code - but a toggle somewhere... OMG... kill me.
> since all the tutorials, blogs, youtube videos - all assume that your data all lives in Sharepoint or some other MS resource
If you have to troubleshoot software advertised and explained by happy smilling people dragging and dropping things, code automagically appearing from snippets, claiming that "it's easy" - RUN AWAY. Your mental health is at stake.
I was not having the best time mental-health-wise anyway about 10 years ago. I was freelancing and writing an application for a doctor's surgery in C#, using some of the cool new toys they'd produced for it. Including Entity Framework. Which came with lazy loading of object properties, cool. Except I kept bumping into cases where the object hadn't lazy-loaded, and data I knew should be there, wasn't. Digging in through myriad stacks of documentation and notes, all of which said that data would be loaded if it was asked for without needing to load it, I finally bump into a small note, obviously written by an actual dev, that cheerfully pointed out something like "to ensure your data is actually loaded into the object, you'll need to call the loadData() method before using it" (I paraphrase from memory).
I lost it. I completed that project, then uninstalled Windows, installed Ubuntu, and started learning Go (I intended to also learn Rails and Python, but fell in love with Go's simplicity and haven't moved on since).
It actually helped with my mental health. Realising that at least part of my problem was that people were professionally lying to me was an insight I needed.
I'm never trusting a Microsoft technology again. It's always nice and slick on the surface, and then a twisting pile of mess underneath.
Note that the EF will not create proxies for types where there is nothing for the proxy to do.
This means that you can also avoid proxies by having types that are sealed and/or
have no virtual properties.</quote>
This is a common rookie mistake, unfortunately.
Entity Framework is an absolutely top-tier ORM (if you like ORMs). Because lazy loading is frowned upon by some purists (and DBAs), EF also support controlled/eager loading where nothing happens (lazily) behind the scene.
You can - for instance - in the query use <code>.Include(x => x.RelatedEntity)</code> to load a related entity eagerly without going back to the database server to load the related entity for each row (the so-called N+1 problem).
Because Linux is open about everything, but particularly about what works and what doesn't.
Working with Microsoft tech felt like being gaslighted by an abusive partner. Their documentation absolutely did not match what their tech actually did.
I'm really happy working in Go on Linux. Why would I want to switch back?
If the thing which would be intuitively obvious to 90% of people in your audience doesn't work, then your framework is wrong, not the people. It shouldn't take a mountain of documentation to clarify a basic feature.
There can be many "basic features" in a large framework that can't be made more intuitive without making the other features less intuitive.
Just because there are some unintuitive edge cases which you can identify in a technology doesn't mean the technology is "wrong". Pick your favourite technology and I am sure you can find many such unintuitive edge cases if you purposefully look for them.
I’ve had similar experiences with Microsoft’s documentation. My memory is fuzzy but one instance I can recall the documentation was clearly what was meant to be in the final product but most definitely was not what shipped. To make matters worse the docs as they were would often result in a configuration that worked on the first sync but subsequently failed or even caused the service to reach a permanent state of limbo where it could never finish starting. This left a lot of people thinking things were broken for other reasons.
They took ages to for them to finally update the pages. In fact it took a well known consultant, one of their mvps, writing not just documentation that worked, but also thorough instructions on how to fix the predicament Microsoft got you in. I wouldn’t be surprised if the team writing the docs were completely lost until they read his blog. The service was just one component but it was ridiculously complex for what it did. Sometimes I wonder if they crammed the service (Forefront Identity Manager) in to save the team working on it since they cancelled the standalone version of it.
Their docs can be good and are certainly improving but it does still feel like disjointed teams doing their own thing sometimes.
My assumption on this site is that most people talk from the perspective of devs. So I assume your experience with Microsoft's documentation is also on the dev side of things. I can't speak to that, I'm a sys admin so I have a different experience. And my job has me approaching technology from the opposite end. From what I have seen, Microsoft's is generally pretty good. Not the best but definitely far from the worst.
I’m afraid not. Those docs would have been used by both sides, especially for non-prod environments but they were definitely operations oriented.
I would agree they’re usually good but when they were bad, they were real bad. And bad seemed to happen a lot more outside of the “big” internal fiefdoms at the time (Desktop, Server, AD, Exchange, etc.).
They did seem to hit a rough patch during the transition but the only thing I’ve seen is gaps here and there due to what I assume is incongruity between teams. Like tools being moved from an installer and therefore the installer docs but corresponding docs for how to get those tools not being created/updated elsewhere.
I've always like C# for its multi-paradigm nature, good runtime, and excellent collections framework. It's basically what Java could/should have been.
Unfortunately the legacy tooling is infuriating to work with. It's been steadily improving for the past few years with the advent of .NET Core but in practice this doesn't mean much. If you work at a ".NET shop" then odds are that the devs that work there have been firing up Visual Studio and creating solution files for the better part of two decades; good luck getting them to use dotnet or Docker Compose, not to mention the long-lived legacy apps floating around that are still built that way and live on IIS in a corporate datacenter someplace.
Yes, C#'s greatest weakness is the tooling. There's no autoformatter, for heavens sake. (There are two in theory, but one is prettier's support for an old version of C# and one just doesn't work). And, yes, solution files and project=assembly are both absurd.
There's autoformatting tools in C# editors (VS, VSCode) and also the dotnet-format command-line tool for non-editing environments. Have you tried these?
The modern .NET tech stack has radically changed so much in the past 4 years that it's not surprising that so many folks are still having flashbacks to the old proprietary days.
Yeah but no. Linux is pretty open and honest about the twisting mess. There are years-long discussions about them. The Xorg/Wayland thing has been surfacing a few times on HN recently.
If you search for a Linux problem, you'll get 50 different people telling you 25 different ways of fixing it, most of which work.
If you search for a Microsoft problem, you'll get 50 pages of corporate bullshit that pretend everything's OK. You have to ignore those and dig further to find some unofficial blogger or random dev post that actually tells you something useful.
Also looking at you, Apple - less bullshit and more honesty in your support pages please
> If you search for a Linux problem, you'll get 50 different people telling you 25 different ways of fixing it, most of which work.
Not in my experience. They may have worked for some version of some distro, but it is almost always not the one I'm trying to fix the problem on.
> If you search for a Microsoft problem, you'll get 50 pages of corporate bullshit that pretend everything's OK. You have to ignore those and dig further to find some unofficial blogger or random dev post that actually tells you something useful.
Unfortunately that is also pretty accurate, and it has been getting worse since Windows 10, resembling more and more the problem with searching for solutions to Linux issues. Does this fix still work for 1901 or did it only work for 1607?
> You kind of just described Linux, Unix, modern Web dev, iOS dev, Android dev etc.
More devs seem to have this opinion of Microsoft technologies though. Their desktop OS is the most dreaded as a platform, and the most dreaded of any OS except for Android (by 4‰, and of course devs already killed Windows Mobile)¹. And even more relevant to the link we’re discussing, another relatively low-barrier-to-entry language they created is the single most-hated programming language there is².
That is interesting. I assume it's because corporate takes over and honest communication is no longer possible when the financial stakes of admitting error become too large. But I could be wrong.
I am pretty sure the reason Stack Overflow was created is to provide help understanding what MS code actually does vs what MS documentation says it does. They just happened to hit on a formula that was useful for other people too.
I remember participating in a Microsoft sponsored meeting when LINQ to SQL just came out. Failed to have an answer on how to reasonably implement paging.
I was always ORMphobic person and especially I afraid EF. This framework lets you think query DB is easy and you don't have to dig into details, but it always turns out you have to know how the DB works plus you have to learn how EF works internally. I am trying to stick with micro-ORMs, like Dapper or something like SQLBuiler. Raw SQL is no good too.
I've experienced similar when working with android's api. Docs say x should work, but it's just not happening. Five hacks later, and you've got a working app that feels choppy. Granted this was back in the 4.4.4 days, so things may have gotten easier since then.
To be honest I can't remember (and I'm definitely not going to look). It was pretty early in the development of EF - I understand that this problem no longer exists and lazy loading works fine now.
Which I would totally have understood and forgiven if they'd been honest about it. But all the documentation was lying, except this one tiny bit buried deep in the tech docs. That wasn't the first time I've encountered this phenomenon in Microsoft tech. It seems there's a mis-communication between the documentation team and the actual dev team, and they end up documenting what should happen instead of what actually happens.
You said yourself that the lazy loading actually did work most of the time except for these problem cases, right?
So doesn't that sound more like it might just be an unintentional bug or maybe you had your environment configured differently from what the docs were expecting?
It really sounds to me like you threw the baby out with the bathwater over a small bug, when bugs of a similar magnitude will likely be present on every other platform too (including documentation bugs)
I've never used EF or developed business apps in .NET, but I have used similar technologies like Hibernate in Java and I think you are basically describing standard caveats with any ORM. Lazy loading is often a non-obvious behavior.
If your documentation says in several places that your system does X, but it doesn't, it does Y, then that's lies.
It might be caused by a bug, and what you're documenting is intended behaviour not actual behaviour. But then you need to say that somewhere - something like "We expect the system to do X but we haven't actually tested it so it might not". Not saying that, and instead saying "the system does X" is lying.
And yeah, I stopped using ORMs too :) They just get in the way.
With this definition, every software which has undocumented bugs (i.e. every software) is lying. That doesn't seem useful to me and I don't see how the problem is solved by moving away from EF either.
No, I think there's a difference between undocumented bugs and professional documentation that very clearly documents behaviour that doesn't actually match what the system does.
As others have said, it's a problem that's particularly apparent with Microsoft - it feels disjointed. Like the documentation team read a different spec than the development team.
No, but I do have a longstanding annoyance with the general form of argument in which technologies are dismissed just because they have some weird edge cases. All substantial technologies have weird edge cases.
> since all the tutorials, blogs, youtube videos - all assume that your data all lives in Sharepoint or some other MS resource
If you have to troubleshoot software advertised and explained by happy smilling people dragging and dropping things, code automagically appearing from snippets, claiming that "it's easy" - RUN AWAY. Your mental health is at stake.