Java isn’t just a language; it’s an ecosystem. You can write code for the JVM without writing any Java. This gives you the option of using a more modern language. Some of the shortcomings of Java are obvious. It makes you write a lot of boilerplate code. It supports functional programming only as an afterthought; the lambda feature is a kludge. The NullPointerException is every Java programmer’s bane.

In 2004, a group led by Martin Odersky released an updated version of the language, called Scala (“scalable language”). It added features such as objects for everything, functions as assignable data, type inference, and pattern matching. It compiles to Java bytecodes and can be mixed with Java code.

Another language aimed at the same goals is Kotlin, released by JetBrains in 2012. It built on people’s experience with Scala. A common complaint with Scala is slow compilation time, and Kotlin offers compile speeds comparable to Java. It’s recently gotten a big boost from Google, which has declared it a first-class language for Android development.

If some features of Java constantly annoy you, you’ll find things to like in both languages. If you’re annoyed enough to make the jump, which way should you go? Should you choose the maturity of Scala or the freshness of Kotlin? There are benefits to each.

Solving problems different ways

Kotlin and Scala, like Java, are statically typed. Whatever type a variable starts out as, it will keep it for its whole life. But both of them save you some of the effort of declaring every variable. You can implicitly declare a type with an initializer. In either language you can write

var count = 1

That makes count an integer. Notice that no semicolon is required. The difference between the languages is that Scala goes much further in allowing implicit conversions. If you use x.transmogrify(), and x belongs to a class which doesn’t have a transmogrify function, that isn’t necessarily an error. You can create an implicit class which has a transmogrify method, and the compiler will figure out, without making you do any casting, whether it can step in to do the job.

Kotlin’s creators found this a little too free-wheeling. It lets you define extension methods on a class, adding custom functionality. You can do this even on standard data types. (Remember, everything is an object, so every data type is a class. Boxing of simple data types is no longer needed.)

Null values are a huge headache in Java. Scala helps to relieve this in a couple of ways. First, variables must be initialized. You can initialize them to the default value (var a:Int = _), which is often null, but at least it makes you aware you’re doing it. Second, the Option class helps in guaranteeing null-safety in parameters and returned values. It’s one of the more complicated features of the language to understand, but it gives you a lot of control.

Kotlin gets right to the point. By default, it doesn’t allow variables to have the value null. You can declare a variable to be nullable if you really need to, by putting a question mark after the type. If you’ve worked with Swift, this approach will sound familiar. If you use nullable values, the compiler does extensive checking to make sure you aren’t putting them at risk of a NullPointerException and will give you a compile-time error if you are.

Java makes you use a regular class or an enum if you just want to package some data together in an object. Scala and Kotlin offer some better options. Scala gives you the case class, which a specialized class for data objects. It automatically defines accessor functions (why doesn’t Java just do that?). Instances are compared by structure rather than reference. A copy function is automatically provided to do a shallow copy.

Kotlin’s data class does pretty much the same thing. The main difference is that Scala has a powerful pattern matching feature which Kotlin didn’t pick up. A match statement is like a bionically enhanced case statement. Patterns can check not only literal values but types, lists, and ranges. Scala can do matching on all kinds of objects, but the feature is especially powerful with case classes.

Scala provides strong support for XML. You can put XML directly into Scala code and assign it to an XML object. This creates complications, since a <operator that isn’t followed by a space may be read as the start of an XML expression. Kotlin uses the more traditional approach of classes to handle XML objects.

Type classes are a feature of Scala that doesn’t have an equivalent in Kotlin. A type class defines a set of operations which member classes must support. This isn’t like subclassing in Java; a type class can be added to types that already exist. It lets the developer create new kinds of polymorphism with existing types. Extension functions in Kotlin aren’t the same thing, but they let you add common ground to different types, so they address some of the same needs.

The feel of the language

OK, there are differences between the languages, but they aim at more or less the same thing. You can learn either one. Are there bigger, more philosophical reasons for choosing one or the other?

To some people, the difference is that Scala is more aimed at exploring new ideas, and Kotlin is more focused on getting results. Kotlin’s emphasis on fast compilation and its removal of some of Scala’s more esoteric features reflect this. Scala just lets you do lots of things. The operator name ?:+ appears to be legal, and maybe there’s a reason you’d want to use it. Kotlin is more restrictive. Some would say saner.

If you love functional programming, Scala has more of its features than Kotlin. Type classes are a functional programming feature. As another example, Scala supports currying and partial application, which are ways to break down functions that take multiple arguments. This provides additional flexibility in using argument lists. Kotlin provides ways to do the same things, but they might not be as mathematically elegant.

People who have learned Scala thoroughly love it. It takes more effort, but it lets developers do things they can’t do in Kotlin. Kotlin adherents often find that much flexibility more confusing than useful.

Practical considerations

Sometimes the realities of what you’re trying to do are the main factor. You need to pick the language that will let you do the job, even if you don’t like it quite as much. If you ‘re going to do Android development, Kotlin is the only choice. Android doesn’t use Oracle’s JVM, so you can’t use any old JVM-compatible language. Kotlin has the tools for compiling, debugging, and running software on Android. It’s built into Android Studio, starting with version 3.0.

Outside Android, Kotlin’s options are more limited. Are you committed to Eclipse for your IDE? You can use it to work with both languages, up to a point. The Scala IDE for Eclipse is more mature than the Kotlin plugin, which is a bit painful to set up. Some users have reported trouble getting the latter to work. The situation for NetBeans is similar. With Kotlin’s growing popularity, the situation may be more equal in a year or two. If you like working from the command line, the IDE situation isn’t an issue, and Kotlin has all the necessary tools.

Kotlin is still maturing, but many Java people find adopting it is an easier transition than Scala is. The one that works best for your needs will depend on your personal style and your practical aims. Look at both carefully before making a decision.

If you enjoyed this article please share it! This is the biggest compliment you can give a writer! Thank you!

Artificial intelligence (AI) is a lot like life’s relationships. Sometimes what you put into it is pretty straightforward, leading to the output or outcome that you wanted. Other times, let’s just say, the process gets a bit more convoluted and sometimes the outcome isn’t exactly what you envisioned. In other words, you may input the same into both relationships, but different paths lead you to different results. Nevertheless, both are learning processes. In the AI world, this is called supervised and unsupervised deep learning–and like most relationships, the shortest distance between what you input to what you get as output isn’t always the proverbial straight line.

What is Deep Learning?

Before we delve into what supervised and unsupervised deep learning is, you should know that deep learning evolved from a process called machine learning. Machine learning employs an algorithm, or set of rules, that creates output without specific programming. Think about how social networking mines data from your posts. For instance, you go out to eat with your friends at your favorite sushi place and share facts online about your experience–what you loved, found distasteful, photos, would you return–once you input these into your social network, an algorithm picks up tidbits about your input to extract patterns about what you like, don’t like, even what you look like based upon your pictures. The algorithm may discover that you are around 23 years old, eat out at this particular type of restaurant twice a month with your friends and like California rolls over eel sushi. It then sends you ads based upon that data. Machine learning iteratively gleans information about input despite not being told how to do so or where to look for that information.

Deep learning kicks it up a notch. It takes your input, finds that it can either categorize it without issue (supervised) or clusters unlabeled information, attempting to categorize it so that it makes sense (unsupervised), before taking that input and creating some sort of viable output. It’s a layered architecture making sense of data that can be quite abstract from one layer to another. That’s how deep learning emulates the multi-faceted complexity of the human brain–its neural pathways processing copious amounts of information that doesn’t make sense until it does (or not).

Supervised Deep Learning: The KISS Pathway That Leads To The Expected

What happens when your supervisor’s hanging over your shoulder at work? Like most, it drives you batty, so you tend to take the path of least resistance to find the most non-challenging way to get your job done quickly and still meet the expectations of your supervisor, right? Let’s say that particular supervisor trained you to process credit applications. Said supervisor knows what’s in those applications and that the expected outcome of any application is approval or not approval. You learned from your training set how to function in the best way to get to the desired outcome, i.e. the results that your supervisor needs. Supervised deep learning is like that. We humans tend to process in a specific hierarchy: we take in life’s input and based on our experiences (training), we organize that input so that our prior knowledge can make sense of it, process it to some expected outcome. Supervised deep learning belongs to that Keep-It-Simple-Stupid (KISS) pathway, that literal path of least resistance leading to some fulfilled expectation.

Supervised deep learning is well suited for decision-making: take our credit card example for instance. The bank takes your application and runs it against its categories of risk before taking action for or against approving you. Here’s the procedural gist:

Application is input from customer

The bank inputs data from application into the algorithm

The algorithm notices from past applications that data follows certain pathways (modeling)

For example: marital status–single, married, divorced, widowed all have a yes or no answer

The algorithm takes that application data, the yes or no answers, as determined by the bank and follows its flowchart (pathway rules)

Data flows through that pathway as the algorithm decides which of the primary categories of approved and not approved the data belongs in

The expected decision of approved or not approved is rendered

The customer is approved and is a happy camper or is not approved and wonders how to fix his credit score (had to throw that in).

Supervised deep learning is more than your typical lights on, lights off binary function. The algorithm classifies criteria into the bank’s expectation of risk, processing that risk into one of two decisions. This method of classification is known as binomial classification (two choices) or multi-class (more than two choices).

Unsupervised Deep Learning: An Exploratory Journey To Figuring Out the Unknown

If supervised deep learning is a path to expected output, unsupervised deep learning takes that same input and attempts to make sense of it before eschewing some output. Let’s take a trip to the art museum with your best friend as an example. You both become captivated with a painting of a rose. One of you sees it rather literally, the other sees it figuratively. To you, a rose is a just a rose and you want to move on to the Van Gogh exhibit. To your friend that rose is yellow when it should be red and your friend cannot figure out why the painting denotes friendship and not love. There’s no Van Gogh until there’s ready to go–and that’s not happening until your friend muses about that rose and why her current relationship is hanging on that museum wall.

Unsupervised deep learning has no target, no expectation from the input. It relies on exploring layers of possibilities to get to some conclusion. While you can move on to the Van Gogh exhibit, your friend struggles to figure out how to classify all the many pathways friendship and love can take someone from convolution to happy life and how one can learn from their mistakes.

Decision Time: If You Knew Then What You Know Now

Humans are subjectively sentient creatures with decision-making processes that cater more to the unexpected (unsupervised deep learning) than to the expected (supervised deep learning). Computers don’t have the human factor. They don’t have experiences. They just have data sets, functions, and “thinking” based on layers of pooling information together in either ordered or non-ordered ways.

As neural nets and AI become more complex, so do the deep learning algorithms. You can choose among supervised, unsupervised or a combo-pack of deep learning to tackle anything from credit approvals to the complexities of mind-boggling, robotic data sets. Remember the social networking example? When you uploaded images, something called Convolutional Neural Networks (CNN) picked out traits before it came to the conclusion that you around 23, pooling together relevant data: restaurant, friends laughing, friends frowning, facial recognition, background recognition. Combine and categorize those subgroups and your image spoke volumes about who you are and how you live. Imagine what they’d unpack from what you say on an uploaded video (Recurrent NN)? Yet, sometimes life has to unfold unsupervised by knowns, reconstructing (autoencoding) the data-driven universe while self-organizing maps translate often nebulous data patterns into two-dimensions (think topographic maps) that allow you further muse as to why that rose by any other name is just backpropagation (wink).