5 Programming Languages You Need To Know

I was inspired to write this by the following youtube videos:

It is not enough for a developer to only know one programming language these days. Our industry has evolved to the point where we are expected to do everything from frontend web development, backend business application development, mobile development, cloud computing, etc … Unfortunately, no single programming language is going to be able to do all of these things; so, it fall on us to increase our breadth.

From what I can see of where the industry is moving, in order to stay relevant (and in-demand) as a developer, you should know at least 5 of these languages..

1. One object oriented programming language (C++, JAVA, C#)

Business is very invested in these languages; so, they are going to have to maintain these systems for a very long time (probably longer than they should, too). If you know at least one of these languages then you are guaranteed employment for the rest of your life.

The downside is that doing maintenance programming is incredibly boring. However, it’s one thing not to like your job; it’s another thing not to have a job.

I personally enjoy not being poor.

2. One web scripting language (Ruby, Python, PHP)

The web is ubiquitous. However, programming a web application with a general purpose programming language is extremely painful. I’ve had the misfortune of having had to build very complicated web applications using JAVA and C#; so, I know from experience how torturous that kind of development is.

Web scripting languages like Ruby, Python, and PHP are amazing at building web apps. For example, I use VI to develop in PHP and run unit tests on the command line. That’s how powerful PHP is for the web.

The only reason JAVA and C# are even viable options for web development is because of the extremely powerful IDE’s and enterprise frameworks built to support it. In my opinion, if your language has to rely on a boatload of extra stuff to work then maybe your language isn’t up to the challenge.

Any experienced web developer will know that web scripting languages provide the easiest and most straightforward way for you to build a website. The solution may not necccessarily be as elegant as something built with ASP.NET or JAVA Spring, but it will get the job done.

You might be tempted to respond with something like “but .NET is beautiful” or “PHP is so ugly”. That kind of thinking is the result of programmers constantly being told that “what we are doing is art”.

NO! NO! NO! NO!

The person paying you to build him a website, isn’t paying you to be an artist. He is paying you to build him a website. Period. Choose the simplest most cost effective way to do that.

Software architecture as art will promote aesthetics over utility. I’ve worked with too many web frameworks built with super elaborate class diagrams that you had to memorize in order to do the most basic thing.

I have a suspicion that the people who create these frameworks are not actually using them. Instead, they are appreciating the beauty of their class diagrams.

Sure, some of the web scripting frameworks might not be the best, but you are still better off using one of them than something like Spring or .NET MVC.

3. One functional programming language (Erlang, F#, Scala, Clojure, Haskell)

Programming languages have a tendency of coming and going in waves. Functional programming is the next wave. To understand why, you have to understand where we were before, where we are now, and where we are going next.

The 1970’s introduced the imperative programming wave because it freed developers from having to write low-level assembly language. C, COBOL, Fortran, and BASIC were able to create applications that were independent of a computer’s architecture, which at the time was a big deal.

The 1990’s introduced the object oriented programming wave. As applications became more and more sophisticated the need to simplify very complex conditional logic drove the industry toward polymorphism. There were other styles of polymorphism but class based polymorphism ended up being the implementation of choice.

The 2000’s (primarily the later half) was all about web scripting languages. The web 2.0 revolution meant that you had to build a website fast and iterate fast. For better or worse, scripting languages allowed you to hack together a website pretty quickly.

These transitions were made possible by Moore’s law. Moore’s law states that processor speeds would essentially double every 18 months. It is this phenomenon that allowed developers to move from one wave to the next: we had to wait for the computer engineers to build the hardware that could power a certain type of development.

For example, scripting languages are horrendously inefficient compared to compiled languages. However, with a fast enough machine, that doesn’t really matter. What matters is how fast you can get a working product out.

At some point, Moore’s law began to fail (we’ve been stuck with 3.0 Ghz processors for at the last 10 years). To compensate for hitting that wall, the computer engineers began to add multiple cores to a CPU.

For example, my current laptop has 8 cores inside of it running at 2.5 Ghz, but in order to take advantage of those 8 cores, my software has to be explicitly written to spread the execution across all those cores.

Concurrent programming is extremely painful; so, developers simply don’t do it.

However, technology stops for no-one, and the CPU arms race will continue to double the amount of cores available in a computer. It’s very likely that 18 months from now we will have 16 core machines, and 18 months after that we will have 32 core machines.

Your days of programming for a single machines and a single thread are over. The systems of the future are going to be highly distributed and multi-cored, and the way that we currently build software doesn’t deal with that.

Are you up for the challenge of building systems that can take advantage of 32, 64 or 128 cores? My guess is that you are not; so, you had better start learning how to do that, now. Employers will not like the fact that they are buying hardware that you can not take full advantage of.

If you think that you will be writing concurrent applications in C++ and JAVA then you are either the best programmer in the entire world or simply crazy. The traditional shared memory model is too error prone and unpredictable.

The shared memory model introduces problems like deadlock, livelock, and starvation. While we have methods to deal with them, they are not easy. For example, it is not uncommon to spend months chasing a multi-threaded bug. Imagine how painful it will be when we have 32, 64, or 128 cores.

Functional programming languages removes the shared memory model by operating on immutable data types and working with side effect free functions.  Once you remove the shared memory model, you also remove all the complexity associated with them.

Further, functions in functional languages behave very similar to mathematical functions; so, it’s much easier to reason about program correctness with them.

These properties makes concurrent programming more predictable and manageable in functional languages. That is a huge competitive advantage over procedural or object oriented languages. The caveat is that it introduces a completely new way of thinking.

Do you like getting paid? Well, you had better start picking up a functional programming language.

4. HTML5 + javascript + CSS for Single Page Applications (SPA)

OK. That is technically 3 different programming languages, but it is pretty much impossible to building anything useful with one of them in isolation.

We no longer need JVM or CLR technology in order to get cross-platform applications. Thanks to the universal adoption of HTML5 every HTML5 application can easily be deployed to any OS or device

At least, that is the promise of HTML5. We are still building the technology to support the HTML5 infrastructure, but the future definitely looks promising.

I’m particularly impressed with Phonegap. I haven’t created a native android or ios app in a year because now I can just deploy an HTML5 app to those devices.

Unless you really enjoy writing multiple applications to support multiple platforms then I would suggest you start learning how to write SPAs. There are plenty of options: Durandal.js, Angular.js, Ember.js, and Sencha Ext JS are just a few from the top of my head.

5. SQL

The relational model that SQL is built on top of is incredibly powerful. 40+ years of research has gone into developing it. It has been studied from top to bottom and left to right. The use of normal forms for OLTP, and data marts for OLAP are incredible tools. There simply is no equivalent to them. Although, there is some attempt to try and create one (see: http://queue.acm.org/detail.cfm?id=1961297).

Ultimately, it is the way of thinking about your data that SQL requires you to do that is important.

Some of you reading this might be thinking “What about ORMs?” or “What about NoSQL?”. Well, let me address your concerns.

The fact that ORMs exist are not an excuse to ignore SQL and the relational model. ORMs are a convenience. They are not meant to serve as a drop in replacement for database knowledge (or at least they should not be).

It is a shame that people have invested so much time and effort into thinking of strategies to prevent software developers from actually having to learn database theory. I’m amazed that entire frameworks have been invented so that programmer would never have to understand the details of how a database works (i.e. hibernate).

These frameworks have essentially given developers the license to be stupid. It’s never a good idea to let developers be stupid.

NoSQL was driven mostly by non-functional requirements: scalability and partition tolerance.  In order to achieve that goal, most NoSQL implementations had to relax certain properties in order to achieve that end. That isn’t necessarily a bad thing, but it points to the fact that NoSQL isn’t trying to do the exact same thing as SQL. Simply because something else exists doesn’t give you license not to understand something else.

Conclusion

Of course, this is all just my own opinion. Your goals may be very different from mine.

If you really love JAVA and don’t want to do anything other than JAVA then by all means do so. However, I seriously doubt that 10 – 20 years from now, you want to be the legacy JAVA programmer that the new young developers make fun of. If you think that that can’t happen then consider that 20 years ago we still had a lot of COBOL programmers.

Our industry moves really fast: faster than any industry, probably. If you are not constantly updating your skillsets or mastering fundamentals then your are in serious jeopardy of being left behind.

Advertisements

MongoDB, MySQL, and ORMs: when and where to use them

I had a really interesting conversation on facebook today with a friend I knew from school. We are both professional developers now, and we occasionally exchange ideas on software development. I feel that this particular conversation was worth documenting for posterity because of the natural progression of ideas. I think that the overall conversation simplifies  a lot of very complicated ideas into a narrative structure.

Edgar: What’s your opinion on this hilarious discussion?

Me: I’ve actually seen this. We use both MongoDB and MySQL at work. There is a religious war between different teams, here.

Edgar: I think MySQL is better in situations where you need reliability above all else.

Me: You can get reliability with MongoDB. You just don’t have transactions across documents. Databases have transactions across tables. MongoDB only supports transactions for a single document. That issue is important when you design your application.

Me: The problem is that people want to use their pet technologies with MySQL or MongoDB. If their pet technologies doesn’t support one or the other then from their view that technology is automatically bad.

Edgar: You sound biased. hehe

Edgar: Wouldn’t it be beneficial to simply keep everything in one massive tree?

Me: No. To say you must always use a database means you must always use a b-tree because internally that is what a database engine uses to persist information. Imagine if someone told you that you are only ever allowed to store information in a b-tree in your application code. How painful would that layer be?

Me: Data structures and algorithms are interconnected. That means that the way you access information and the way that you store information are interconnected.

Me: The reason we used databases is because we used to store information on rotating cylinders. This made our secondary storage very slow because you had to worry about seek time and rotational latency in addition to access time. Therefore, we wanted to find ways to structure our data in order to minimize the seek time and rotational latency. Therefore, relational algebra was born.

Me: On top of that we defined mathematical functions to guarantee data integrity using relational algebra. That is where 1st, 2nd, 3rd, 4th, and 5th normal forms come from.

Me: Depending on your data, you might want to have a certain type of data integrity; so, you choose a particular normal form to guarantee that level of data integrity.

Edgar: I see

Me: Now we have solid state drives. Those have no cylinders and therefore no more seek time or rotational latency; so, the motivating factor behind databases no longer exists. We are now allowed to think of new ways of doing data persistence.

Edgar: That makes sense.

Me: Sometimes a database is the best tool for a job; sometimes it isn’t. So, going back to my original point: when I see people fight over MySQL vs MongoDB, I think that they are stupid. What matters is your data and application. That is what determines how you persist your information.

Edgar: At that point it is just a convenience thing for the developer I guess, and a few features missing here or there.

Me: No. It should not be a convenience thing that determines the choice of technologies. You are likely to make very bad decisions if you think that way. Putting convenience (I am assuming you are talking about application code) over things like scalability and data integrity will increase you technical debt.

Me: One of my biggest complaints about some of our engineers at work is their love of ORM tools. They love the convenience of automatic object persistence, but it comes at a very high price. Whenever I see a new project starting with an ORM, I always tell the development team to write apology letters to their future selves.

Edgar: haha. Really? Why do you dislike ORMs? (Entity Framework is pretty awesome)

Me: Actually, Entity Framework is one of the ORMs that get’s it right. Microsoft did a good job at learning from the mistakes of other implementations.

Edgar: How is it better than say Hibernate?

Me: The Entity Framework fluent API gives the developer the flexibility they need to do proper mappings.

Edgar: So your problem is with the annotations and its lack of control

Me: Not necessarily. Hibernate definitely went overboard with the overuse of annotations, but it is possible to work around it.

Edgar: I see.

Me: The problem is when you use hibernate to automatically persist object from your domain layer. If you don’t create an indirection layer in between your domain layer and your persistence layer then you have essentially married yourself to hibernate. The Entity Framework makes it easy to create that indirection layer.

Edgar: So you are saying that having the need to have certain attributes and classes to make the persistence layer work even though you probably wouldn’t need it in your actual domain model. Am I understanding you correctly?

Me: Pretty much. Although, that indirection layer may not always be necessary. It depends on your application. For example, Ruby on Rails uses the active record pattern which essentially mixes the domain model with the persistence model. That is fine for a lot of applications.

Me: The problem is when you need to have a complicated domain model, and at the same time have a proper database schema. A complicated domain model uses the notions of polymorphism, while a database schema uses notions of normal forms. That’s called the impedence mismatch.

Edgar: Right.

Me: When you combine a complicated domain model with a persistence model, you have one set of classes where you need to do polymorphism and normalization at the same time. That’s not possible. That is why you need the indirection layer.

Me: One layer does the polymorphism you need to power the domain model; One layer does the data persistence using normal forms; One layer does the mapping between the two classes.

Edgar: Well, I’m not sure how other frameworks handle it, but the Entity Framework out-of-the-box just puts all classes and subclasses in one big table.

Me: Out-of-the-box, yes; but, it is configurable to perform the data mappings, well. That is where the Fluent API comes in. In Java, I have to manually create a set of classes to handle the impedence mismatch. .NET provides a framework for you to handle that, easily.

Edgar: Oh, Right.

Me: Going back to my original point of mongoDB vs MySQL. If you use mongoDB as a persistence engine then the data mapping becomes dead simple. If you use MySQL then the data mapping gets really hard. You could spend more time performing the data mapping than the actual application code. Therefore, you should make damn sure that you really need to use a SQL database.

Edgar: Unless of course you use an ORM, and accept the fact that it will be sub-optimal

Me: Well, using an ORM is not necessarily sub-optimal. My problem is that people just assume that they need to use an ORM without actually thinking about why they need to use an ORM. An ORM is just a tool.

Edgar: Right. To quickly persist data.

Me: Yes. Sometimes you really just want to persist information quickly, and that’s fine for simple apps.

Edgar: Yeah.

Me: If all I wanted to do was power a data entry system then you can bet that I’m going to be using an ORM where my domain model and persistence model are the same thing. I would have that thing done in less than a week. However, if I wanted to power a social network then I would never use an ORM; or, if I were to use an ORM I would put it off to the side somewhere (away from my domain model).

Me: A social network would likely have a lot of conditional logic. I would want to use polymorphism to simplify my app development. However, that means that I would have to spend time performing the mappings to my persistence layer.

Edgar: Like using a lot of factories and things of that nature.

Me: Yup. Making persistence easy is not as important as getting my business logic right. If you do not have a lot of business logic then by all means use an ORM to power your domain.