They also filled it up to the edge with Ruby-like magic all over the place.
ASP.NET MVC is the only place I've ever seen in mainstream compiled languages where the code can break in untraceable ways if you change the name of a method parameter (f.ex. for controller actions). Or where models suddenly don't get data because you forget to add "{get; set;}" to the code somewhere. Absolutely no way to find out why it went wrong. The data just isn't there.
Sure, you can learn this and then not make the mistake again, but the reason I don't use Ruby or Python much anymore is because I've had with with having to spend a full day going through a framework's source code to find out why my bug is a bug. In an ecosystem and language like C#, you expect things to either work or to get a pretty OK error message, preferably at compile time. The more magic, the more time I waste tracing bugs.
What's the point of using a compiled language if half your code is a dynamic viewbag of string keys and liberal JSON parsers that just ignore fields it doesn't expect or can't fill?
> Sure, you can learn this and then not make the mistake again, but the reason I don't use Ruby or Python much anymore is because I've had with with having to spend a full day going through a framework's source code to find out why my bug is a bug. In an ecosystem and language like C#, you expect things to either work or to get a pretty OK error message, preferably at compile time.
No, that's what you expect. I expect that the traits of frameworks you describe to be features of particular frameworks and to be largely independent of language, except that in languages that don't provide introspection/metaprogramming facilities that enable them, you probably won't find them (probably, because usually there may be elaborate ways of hacking around language limitations to do magic, and then even examining the source code will make the magic less obvious.)
You can easily have magic-free frameworks in Ruby or Python, and easily heavy-magic frameworks in most (mostly) statically-typed compiled languages like C# and friends as long as they have some introspection/metaprogramming facilities (and optional dynamic typing like C# makes this more viable, too.)
If you want to choose a language so as to avoid any need to examine the traits of particular frameworks so that you don't run into a heavy-magic one, you are going to need a much more limited language than C#.
> What's the point of using a compiled language if half your code is a dynamic viewbag of string keys and liberal JSON parsers that just ignore fields it doesn't expect or can't fill?
The point is the other half of the code. (The part that, in Python or Ruby you might be tempted to drop down to a C or Java [for JRuby] extension to do.)
ASP.NET MVC is the only place I've ever seen in mainstream compiled languages where the code can break in untraceable ways if you change the name of a method parameter (f.ex. for controller actions). Or where models suddenly don't get data because you forget to add "{get; set;}" to the code somewhere. Absolutely no way to find out why it went wrong. The data just isn't there.
Sure, you can learn this and then not make the mistake again, but the reason I don't use Ruby or Python much anymore is because I've had with with having to spend a full day going through a framework's source code to find out why my bug is a bug. In an ecosystem and language like C#, you expect things to either work or to get a pretty OK error message, preferably at compile time. The more magic, the more time I waste tracing bugs.
What's the point of using a compiled language if half your code is a dynamic viewbag of string keys and liberal JSON parsers that just ignore fields it doesn't expect or can't fill?
It's just Ruby, but then in Visual Studio.