Too Many Tongues?

The art and science of software development contains more than a few different languages. As you can imagine, communication can be... difficult. Thankfully, unlike our normal means of written and verbal communication, we have an advantage when it comes to software development:

Regardless of the programming language we choose, we're all just doing the same thing: expressing solutions to our problems in ways that can be reliably performed by our machines.

Object Oriented?

Object Oriented Programming, or OOP, is a programming paradigm in which all system components are modeled as virtual objects, like our Cup and Cereal examples in the first lecture. These objects may or may not encapsulate state (store information about an object; say, the contents of our particular Cup or the nutritional data for our individual Box of Cereal). These nouns may or may not know various methods which is another of way saying "know how to perform certain actions" or verbs (to complement our idea of an object or a noun).

Functional Programming?

In the programming industry, a programming paradigm called functional programming has become more popular. Whereas OOP modeled software as a "kingdom of nouns", the functional programming (or FP) style models the universe as a collection of functions free of unwanted side effects.

Huh?

Essentially, this means that FP hackers try really hard to write "pure" software that is free from bugs because the compiler uses the type system to enforce the "correctness" of our software.

What?

If I have a function called makeApplesauce(), I should never be able to pass in a collection of pears. However, if I have a function called makeSauceFromFruit(var fruit: List<Fruit>), I should able expect to call makeSauceFromFruit, pass in a collection of Apples, and receive AppleSauce as my output.

Can't we do that in the OOP world by creating a SauceMaker object that has a .make() method and on, and on, and on, etc.

Yes, of course we can. However, the FP paradigm looks more like an equation and less like a recipe. Since this is a course for beginners, we will subtly work in FP concepts into our solutions, but we will be writing OOP code.

How to Pick a Language & Get Up to Speed

Picking a first, second, or even third language is a wonderful experience. Proficiency in one often translates into a reduced learning curve in the next language. It's important to understand that the actual written lines of code are far less important than a clear understanding of the problem and a lucid plan to implement our solution.

Good and great programmers embrace the right language for the job. And there are a lot of factors at any given job that can - and will! - influence the technology available to us. Some of our choices are limited by company politics, or open source licensing restrictions, or existing investment in legacy systems and codebases, or a myriad of other reasons.

However, if we remember our simple steps to solve any problem, we will look forward to working in a variety of languages and frameworks. That's one of the beauties of working as a full-stack developer.

It's better - and by that I mean, more lucrative! - to be a Distributed Systems Engineer than it is to be a Visual Basic developer. (And yes, I deliberately chose two extremes, from a niche specialization to a specific language.)

It is almost always wise to reuse as much existing code as possible and the language it was written in.

Why?

The learning curve shifts away from tools, language, and syntax peculiars to focusing upon mastery of the actual problem domain with such an ease that the tools become an extension of one's creativity the same way a musician experiences an instrument becoming a part of them. This is the state of "flow" when the musician and their instrument are one, and the music just pours out. Programmers can also achieve a state of "flow" and this flow state becomes easier to attain with experience and practice.

How do you practice? Use our iterative problem solving approach to write a lot of code to solve a lot of problems.

Get into your optimal "flow" faster by moving with the team instead of against the team.