thank you, everything you said supported what I said, you just slapped some "no"s in there to make it sound like your answer. kudos superman

every time you use sql server for more than crud then you are married to sql server. joining, aggregating, filtering, projections, unions these are just a few of the business logic decisions totally married to your database implementation. they are next to impossible to implement solely in code without reinventing the wheel. that's just what all these other databases are doing. No-Sql (like Cassandra), kvp (Redis) outside of crud operations they present just as hard of a curve for creating the above needs.

the biggest drawback to "separating your data layer" idea is that people forget just how much logic is baked into their SQL calls. people are writing business logic in their SQL. the challenge is to see if you can "separate" that into a layer. the only idea I had was DSLs. those are really hard to implement. this is why i can see someone wanting to keep the sql and switch the implementation.

i agree. using a linter for suggestions is great, being bound to its 'rules' isn't. code reviews would be better, some type of paired programming would be better. If the code compiles, then a linter may interfere with the writer's intentions. If the code compiles and it wasn't the writer's intention, then having a second eye is better than a linter. AND if someone is writing code that requires linting I would think that person shouldn't be writing code. I've never been happy with linters; they force you to write code according to someone else's style. If we're just using linters to 'teach' people how to write code then that person probably shouldn't be writing code. like the quote from Ratatouille cartoon, "Anybody one can cook, but not anyone should cook"

wow, where to start? Windows Forms with .Net is NOT as bad as everyone thinks. What's bad about Windows Forms is how people use it. What happens is someone with ZERO programming experience builds a business application on the platform and crams all their code in the code-behind class. They put the business logic, the persistence logic, and any logging and metrics all in that one class behind the form. They also only have ONE form for every part of the application. They don't make sub-forms or sub-controls, it's all one huge monolithic beast. They also don't apply any patterns to aid in decoupling any cross-cutting concerns, namely, using MVP to separate the form from any logic or using some message bus pattern for event handling across the app. Yeah, Windows Forms are horrible because the apps built on them are horribly done. If done properly, Windows Forms can be a quick and clean way to build internal tools for your business. See: Windows Forms Best Practices | Pluralsight[^]

I like your reply. If there was ever a red flag about some technology, to use or not use or abuse, it's those knee-jerk reactions to all flood one side of an argument like a holy war. Engineering is really just a bunch of tradeoffs in favor of the most 'optimum' solution at the time and available smarts. Just look what they did with a simple adjective like 'agile' and all those tussles over to normalize data or to not. Thanks for this lively discussion.

When I say 'human-readable' I mean "it's not a binary file that only a proprietary algorithm can decipher and that you can output the text to your output device of choice and actually read the information therein and with some cognitive overhead understand what is being stored/transmitted" what I don't mean is that it will be like reading Edgar Allen Poe or your favorite Robert Ludlum novel. I mean a human can get in there, do cursory searches and nail down information or even a bug. "Oh, look, John sent a thingabob instead of a hoopadadoop, now I know why the serializer crashed." And again, XML isn't a fixall magic drug that can solve all serialization problems, nor is JSON. Engineering is a set of tradeoffs. This is better than that at this moment in time for this problem. I'm glad I knew about XML at that particular time for that particular need. The same goes for any other serialization. I'm glad I knew about binary serializers, got the info across fast, and in a situation where humans were really never going to need to read the intermediate data anyway.

IDKW people are bad-mouthing XML OR barking that JSON is the magic carpet of serialization. XML was an attempt by some fairly smart people (smarter than me) to make a standardized, text-based, human-readable serialize standard. Is it 'easily' human-readable? Most but not all the time, still useful. Can you just open it in a text editor and read it? Yes, didn't say you'd enjoy the experience but you could, can, and do. Is it a good standard? Well, people are still using it, today, it works, and 'works' gives programmers and interested parties (those with the money) this warm fuzzy feeling inside. And consider this, you can make some REALLY simple XML, read, serialize, transmit it, and you can make some seriously complex XML, read, serialize, and transmit that. Things you couldn't imagine serializing in JSON. That's what the X stands for Extensible. Nevertheless, just like someone else said on this post, EVERYONE IS USING XML EVERY DAY, it's called the internet, it's called HTML which, really deep down, is XML that transmits some of the greatest amounts of information around the world billions and billions of times over, and it just works, not perfect, but it does.

it's because of GDPR, a new law in Europe regarding internet sites to inform users about saving their data. Cookies is a form of saving a user's data. GDPR, The Checklist For Compliance[^]

i'm sorry you missed my point MICROSOFT ISN'T USING IT so if Microsoft isn't using it then guess what it's trajectory is? saying "I don't understand it so i'm not using it" is like being a horse cart driver in the 1800's and saying "I don't know how to drive therefore i'm not buying into this automobile market"

as soon as I read this post I thought, "you aren't using GIT?" I can bet there's pluralsight courses on TFS but even MICROSOFT internally moved all there repositories to GIT! GIT IT! Writing on the wall. Any business leader who doesn't understand that is making a grave BUSINESS mistake.

Even if it really is, their dirty "safer than chrome" ads aren't building any confidence in me.

appropriately named SAP because it's for saps

I would tell the manager to rephrase the request to: "We're making a new policy which restricts the use of nicknames." that way the whole world is happier with the mess they created. because, believe me, if you want more rules just keep suing people over stuff like this and there will come a day when you'll be reading 1984 as a policy guide.

but we own the programming language community. LOL

Salesforce, Sharepoint, Willy Wonka Chocolate factory. All very well contrived fantasies to allure you to a 'one size fits all' idea of software. Who on earth wants to learn YOUR platform when you could just learn how to program.

long live web mail!!!

the longer I live the more I find that just because you're in charge doesn't mean you can think.

nope, still heavily in use. I worked for a dev shop that used it. The current version is build in Java on eclipse (I believe) and it crashes a lot. The navigation is totally un-user-friendly. Makes you appreciate Outlook, which is a bloated whale.

you know, Python is a simple clean language and I really haven't seen many bad examples. The question is 'Why does VB attract bad coding?' Maybe because it's touted as the 'easier' way to program. I also started learning programming from VBA in MS Office and wrestled with what .net language I would learn to get involved in .net. I chose C# because it was too hard for me to grasp concepts in VB.net that were totally different from VBA. This could be similar to VB.net users in general. They don't get out of the box of VB 6 programming. Very procedural and functional.