In most cases I would go with the intrinsic argument... I took 1 year of Comp Sci, realized that it was just a glorified math class (the lack of female students didn't help either), and switched to political science! Now I have the pleasure of interviewing junior developers to join my ASP.NET team, and I have found, almost without exception, that the computer science grads are utterly clueless in terms of understanding the user experience, and have no idea about web application architecture (they try to make everything so strictly OOP that it takes them three months to build a login module!) I think part of the problem is that Comp Sci programs do not teach practical things like web application development and user interface development and instead focus on the writing of highly optimized algorithms that are not really relevant in a client-server environment, since the delays caused by an inefficient sorting algorithm in this context are totally unnoticeable relative to the very real problem of network latency and inefficient database queries. Maybe its also that the self-taught developers have a personality more suited to the agile development mixed with cowboy coding methodology prevalent in Web 2.0 shops... you've got to be a pretty rigid thinker to make it through the tedium of Big-O and other such computer science concepts. Interesting, the one exception is the director of my department, who got his Comp Sci degree but far prefers doing creative stuff like wireframing and user experience architecture than writing code at all.

Here's a little architectural dilemma regarding "round-trip" data access I've encountered using LINQ in my ASP.NET applications... would like to hear some perspectives. Due to the nature of the projects I've been working on, its not really an option to build proper classes to hold much of the data retrieved from the database because the schema changes on a weekly basis and there is the need to be able to reflect these changes in the front-end without having to go into the App_Code every time. A typical example: an ASP.NET page displays information about a user. Each time the page is viewed, the users table in the database must be updated to reflect the number of times that particular user as been viewed. As far as I can tell, there are 3 general approaches for doing this with LINQ, all of which are unsatisfactory. 1) Do your query in the code-behind (BAD) ... MyDataContext dc = new MyDataContext(); user u = (from u in dc.users where u.screenName = Request.QueryString["screenName"] select u).First(); u.views++; dc.SubmitChanges(); SomeFrontEndElement.DataSource = u; SomeFrontEndElement.DataBind(); ... 2) Use LINQ for selection, and SQL for inserts / updates (UGLY) [in some static class in the App_Code] public static user GetUser(string screenName) { MyDataContext dc = new MyDataContext(); return (from u in dc.users where u.screenName = Request.QueryString["screenName"] select u).First(); } public static user UpdateViews(user u) { u.views++; //No way to submit this - the DataContext is long gone ExecuteNonQuery("update users set views = "+u.views+" where screenName = "+u.screenName); } [in the code-behind] user u = SomeClass.GetUser(Request.QueryString["screenName"]); SomeFrontEndElement.DataSource = u; SomeFrontEndElement.DataBind(); SomeClass.UpdateViews(u); 3) Bundle the DataContext and the LINQ results together in a class (BETTER) public class User { private MyDataContext dc; public user Obj{get; set;} public User(string screenName) { dc = new MyDataContext(); U = (from u in dc.users where u.screenName = Request.QueryString["screenName"] select u).First(); } public SubmitChanges(); { dc.SubmitChanges(); } } then in the code-behind: ... User u = new User(Request.QueryString["screenName"]); u.Obj.views++; u.SubmitChanges(); SomeFrontEndElement.DataSource = u; SomeFrontEndElement.DataBind(); ... Certainly, the pattern that I've ju

I don't know if a month of X86 assembler would have me writing apps more productively than using the .NET framework LOL :)

C# seems scary if you come from VBLand, like I did... I used it for about a month, no joke, and was writing code faster than I did in VB... I'd advise everyone to switch over. In my personal, biased opinion :)