4 ms·

This begs the question of how legacy something would have to be for them to initially setup the project in such a shitshow fashion in the first place. Too chea

by douche 11y ago

This begs the question of how legacy something would have to be for them to initially setup the project in such a shitshow fashion in the first place. Too cheap to buy VS licenses, back when the community edition/express editions weren't a thing? Or maybe that I have so much Stockholm Syndrome from living inside Visual Studio world for too long.

alexc05 11y ago
Well, we're talking about a company that is ~15 years old but the legacy portion of this system is likely less than 10. (I've been there near 5 and it was old when I got there) I never thought the arguments in favor of using RUBY to compile your C# held a lot of water. "Visual studio is a slow and clunky resource hog" was one argument, which I don't feel has been true for a long while. They were mostly preference based decisions. But (IMO) ones that optimized for the wrong result. Dynamically loading .DLL means that if the DLL is in the bin folder you can use it anywhere in your code without requiring a using statement. Let me tell you how many hours I've spent hunting down namespace conflicts. Compiling .cs saves time & conflicts in managing CSPROJ files... But if you decide to leave the framework in 2005 & the tools keep moving forward for 10 years, you eventually either miss out on a lot of really important features, or spend time implementing things that are not your core business or competency. We wound up getting locked in to dozens of horrifically limiting technologies because of the design choices. I feel like it was a bit of a case of "programmer hubris" that lead to the shit-show. Thinking "I personally can do it better" (than the billion dollar company dedicating more resources to this tool than the size of our entire company) can be a pretty bad decision. I've had a few discussions about the choices and preferences with the original dev. He still thinks VS is crap, MSBuild doesn't do anything that you can't get from CSC.exe, and docker is just a VM. It's a difference of opinion.
alexc05 11y ago
Well, we're talking about a company that is ~15 years old but the legacy portion of this system is likely less than 10. (I've been there near 5 and it was old when I got there) I never thought the arguments in favor of using RUBY to compile your C# held a lot of water. "Visual studio is a slow and clunky resource hog" was one argument, which I don't feel has been true for a long while. They were mostly preference based decisions. But (IMO) ones that optimized for the wrong result. Dynamically loading .DLL means that if the DLL is in the bin folder you can use it anywhere in your code without requiring a using statement. Let me tell you how many hours I've spent hunting down namespace conflicts. Compiling .cs saves time & conflicts in managing CSPROJ files... But if you decide to leave the framework in 2005 & the tools keep moving forward for 10 years, you eventually either miss out on a lot of really important features, or spend time implementing things that are not your core business or competency. We wound up getting locked in to dozens of horrifically limiting technologies because of the design choices. I feel like it was a bit of a case of "programmer hubris" that lead to the shit-show. Thinking "I personally can do it better" (than the billion dollar company dedicating more resources to this tool than the size of our entire company) can be a pretty bad decision. I've had a few discussions about the choices and preferences with the original dev. He still thinks VS is crap, MSBuild doesn't do anything that you can't get from CSC.exe, and docker is just a VM. It's a difference of opinion.

by douche 11y ago

alexc05 11y ago

Well, we're talking about a company that is ~15 years old but the legacy portion of this system is likely less than 10. (I've been there near 5 and it was old when I got there) I never thought the arguments in favor of using RUBY to compile your C# held a lot of water. "Visual studio is a slow and clunky resource hog" was one argument, which I don't feel has been true for a long while. They were mostly preference based decisions. But (IMO) ones that optimized for the wrong result. Dynamically loading .DLL means that if the DLL is in the bin folder you can use it anywhere in your code without requiring a using statement. Let me tell you how many hours I've spent hunting down namespace conflicts. Compiling .cs saves time & conflicts in managing CSPROJ files... But if you decide to leave the framework in 2005 & the tools keep moving forward for 10 years, you eventually either miss out on a lot of really important features, or spend time implementing things that are not your core business or competency. We wound up getting locked in to dozens of horrifically limiting technologies because of the design choices. I feel like it was a bit of a case of "programmer hubris" that lead to the shit-show. Thinking "I personally can do it better" (than the billion dollar company dedicating more resources to this tool than the size of our entire company) can be a pretty bad decision. I've had a few discussions about the choices and preferences with the original dev. He still thinks VS is crap, MSBuild doesn't do anything that you can't get from CSC.exe, and docker is just a VM. It's a difference of opinion.

alexc05 11y ago