Tag: c#

Which Programming Language(s) Should I Learn?

Posted on by Scott

I had an interesting conversation with a friend of mine (a computer science professor) and one of his students last week.  Beyond the basic which language(s) question were a couple more intriguing ones:

  1. If you had to do it all over again, would you still stick with the Microsoft platform for your entire development career?
  2. Will Microsoft be relevant in another ten years?

The first question I hadn’t really contemplated in quite some time.  I distinctly recall a moment when there was a choice between two projects at the place where I was working–one project was a Microsoft project (probably ASP, VB6 and SQL Server) and the other one wasn’t (probably Java).  I chose the former because I’d had prior experience with all three of the technologies on the Microsoft platform and none with the others.  I probably wanted an early win at the company and picking familiar technology was the quickest way to accomplish that.  A couple of years later (in 2001), I was at another company and took them up on an opportunity to learn about .NET (which at the time was still in beta) from the people at DevelopMentor.  It only took one presentation by Don Box to convince me that .NET (and C#) were the way to go.  While it would be two more years before I wrote and deployed a working C# application to production, I’ve been writing production applications (console apps, web forms, ASP.NET MVC) in C# from then to now.  While it’s difficult to know for sure how that other project (or my career) would have turned out had I gone the Java route instead of the Microsoft route, I suspect the Java route would have been better.

One thing that seemed apparent even in 1999 was that Java developers (the good ones anyway) had a great grasp of object-oriented design (the principles Michael Feathers would apply the acronym SOLID to).  In addition, quite a number of open source and commercial software products were being built in Java.  The same could not be said of C# until much later.

To the question of whether Microsoft will still be relevant in another ten years, I believe the answer is yes.  With Satya Nadella at the helm, Microsoft seems to be doubling-down on their efforts to maintain and expand their foothold in the enterprise space.  There are still tons of business of various sizes (not to mention state governments and the federal government) that view Microsoft as a familiar and safe choice both for COTS solutions and custom solutions.  So I expect it to remain possible to have a long and productive career writing software with the Microsoft platform and tools.

As more and more software is written for the web (and mobile browsers), whatever “primary” language a developer chooses (whether Java, C#, or something else altogether), they would be wise to learn JavaScript in significant depth.  One of the trends I noticed over the past couple of years of regularly attending .NET user groups, fewer and fewer of the talks had much to do with the intricacies and syntactic tricks of Microsoft-specific technologies like C# or LINQ.  There would be talks about Bootstrap, Knockout.js, node.js, Angular, and JavaScript.  Multiple presenters, including those who worked for Microsoft partners advocated quite effectively for us to learn these technologies in addition to what Microsoft put on the market in order to help us make the best, most flexible and responsive web applications we could.  Even if you’re writing applications in PHP or Python, JavaScript and JavaScript frameworks are becoming a more significant part of the web every day.

One other language worth knowing is SQL.  While NoSQL databases seem to have a lot of buzz these days, the reality is that there is tons of structured, relational data in companies and governments of every size.  There are tons of applications that still remain to be written (not to mention the ones in active use and maintenance) that expose and manipulate data stored in Microsoft (or Sybase) SQL Server, Oracle, MySQL, and Postgresql.  Many of the so-called business intelligence projects and products today have a SQL database as one of any number of data sources.

Perhaps the best advice about learning programming languages comes from The Pragmatic Programmer:

Learn at least one new language every year.

One of a number of useful things about a good computer science program is that after teaching you fundamentals, they push you to apply those fundamentals in multiple programming languages over the course of a semester or a year.  Finishing a computer science degree should not mean the end of striving to learn new languages.  They give us different tools for solving similar problems–and that ultimately helps make our code better, regardless of what language we’re writing it in.

LINQ Aggregate for Comma-Separated Lists of Values

Posted on by Scott

A couple of days ago, while pairing with my colleague Alexei on bug fixes to a new feature, we came across a bit of code that attempted to take an integer array and construct a string with a comma-delimited list of the numbers from it. The existing code didn’t quite work, so we wrote a basic for-each loop and used ReSharper to see what LINQ alternative it might construct. Here’s what ReSharper came up with:

int[] numbers = new[] {1, 5, 8, 26, 35, 42};
var result = numbers.Aggregate("", (current, item) => current + item.ToString() + ",");

Before ReSharper served this up, I wasn’t familiar with the Aggregate operator. When I checked out 101 LINQ Samples for it, the vast majority of the examples used numbers.

Filtering Heterogeneous Arrays in .NET

Posted on by Scott

One of the bugs I was recently asked to fix for an application required me to determine whether or not to display one of the members of a list.  This proved somewhat challenging since the lists in question were heterogeneous (two difference subtypes of an abstract base class).  It turned out that LINQ provides a nice solution to this sort of problem in the form of the OfType<T> method.

Given an IEnumerable collection with elements of multiple types, calling OfType<T> on the collection where T is the desired type will return a collection containing only elements of type T.  Before learning about OfType<T>, I’d been using the Cast<T> method.  This was fine as long as all the collection elements were of the type T I wanted.  The moment this wasn’t the case, my LINQ query threw a cast exception.  OfType<T> seems to work similarly to the “as” operator in C#, in that it doesn’t complain if a list element isn’t type T–it simply excludes it from the returned collection.