Kotlin is fun

I'm having fun learning Kotlin so it's time to jump ahead. All of my previous posts have recounted my journey learning programming in chronological order. I was up to my time leaning Java in the Stanford course. There's more that I could write about that and about an Android course I started based on Java. And while I may get back to those topics at some point, I'm going to jump ahead.

I've recently started an Android course using Kotlin. I had heard about the new language and once it became an official language of Android I started thinking more about learning it. The course name is The Kotlin Developer Masterclass on Udemy, taught by Paulo Dichone.

Kotlin is fun

There are definitely things I like in Kotlin more than in Java. Kotlin is short and succinct. While it goes well beyond this, just a simple "Hello World" comparison shows some of this succinctness.

Java

    public static void main(String[] args) {
         System.out.println("Hello, World");
    }  

Kotlin

    fun main(args: Array<String>) {
         println("Hello, world!")
    } 




Note the differences. 

First, the function is declared with the simple fun. While I have seem some programmers online complaining about this, I like it. It's short and sweet and I think programming is fun so typing "fun" all the time is fine by me. On a more serious note, I like how more things can be inferred. If the return type is void (Unit in Kotlin) it doesn't need to be explicitly stated. What's more, if it's a single expression function and the compiler can infer the type, it doesn't even need to be indicated then. Less typing is a good thing.

    fun double(x: Int) = x * 2

Second, println() is better than System.out.println(). The Kotlin builds upon the Java code and saves some typing and extra code to read through.

And third, semicolons are not required. I liked this when I took a look into Python. You'd think that with as much OmniScript I write on a daily basis that adding semicolons, which are required, would be automatic, but I still find that I forget them here and there. I won't miss having to add while writing Kotlin.

I have some fun app ideas that I want to get to, but in the meantime I'm enjoying learning the differences between Kotlin and Java and the other languages I've worked with.

i++

Search Algorithms

You know that a topic is interesting to you when you get excited about it even though the lecture you learn about it in isn't the best. Most of the lectures in the Stanford Programming Methodology Java course were pretty good and easy to follow for me but one taught by the teaching assistant was more difficult to follow. No offense is intended to that teaching assistant, I'm sure with more experience he's a better teacher now. Thankfully, as I said, the topic grabbed me anyway.

Seek and You Will Find

We learned about arrays, creating them and valuing them. Then we had to write something to reverse the order of the items in an array. But what about searching them for a value? That was one thing I was always curious about when creating queries in Access or writing things in OmniScript to search for database records. What was going on under the hood to make searching faster? Was writing something one way going to make for a quicker, more efficient search or not? Therefore I was quite interested in learning about search algorithms.

Linear Searches

Linear searches are the most basic kind of searches. To search an array for a value with a linear search is to look at each value in the array, one at a time, in sequential order, until the search value is found or the end of the array is reached. Naturally this takes some time. Computers are very fast, but if the array is very large, this still takes some time. If an array has 100,000 values, each one might have to be looked at.  I realized that there must be some more efficient ways to search, and there are.

Binary Searches

As long as an array's values are sorted in order, you can do a binary search. With a binary search, the value in the middle of the array is looked at first, and if that value in the middle is lower than the value being searched for, then the whole first half of the array can be eliminated as the value being searched for must be in the second half of the array, if it exists. The opposite is true if the value in the middle is higher than the value being searched for. So if the array has 100,000 values, with the first search, 50,000 values are eliminated and no longer need to be looked at.

Next, the middle value of the remaining values is looked at and the process is repeated. If needed, it is repeated again and again, each time cutting the number of values that need to be looked in half. This, of course, makes the search much more efficient and greatly reduces the time needed to perform the search.

A binary search is much like we humans would search a dictionary or phone book. We don't look at every entry, we jump in at a point and decide which way we need to turn to find what we're looking for and we repeat that until we find our entry.

So Which to Use?

Because binary searches can be so much quicker, one might think they are always preferred. But again, in order to do a binary search, the array has to already be sorted. So if an array is already sorted, then a binary search is the obvious choice. But what if the array isn't sorted? Of course you could sort the array so that you can do a binary search. But of course that's going to take time. So for each case you have to decide what's going to be faster. If you are going to need to do a lot of searches on this array then it's probably best to spend the time to sort it as each binary search you do will save a lot of time. If on the other hand, the search only needs to be performed once or a couple of times, then just running the linear search might be the fastest thing.

i++

Random Number Generators

Another interesting topic I came to early in the Stanford Programming Methodology Java course was the generation of random numbers. As someone who early on thought about making simple video games, I knew that you would need a way to come up with random numbers to make aspects of the game unpredictable.

RandomGenerator

As the Stanford course uses the ACM libraries, professor Sahami had us use the RandomGenerator class. I've come to learn that the use of the ACM libraries is somewhat looked down upon and they aren't used very much outside of the academic setting, but this worked fine as an introduction. I believe this was also one of the earlier instances we had of learning about constructors for new objects.

The RandomGenerator methods include nextInt() for integers, nextDouble() for decimal values, nextBoolean() for true or false (1 or 0) values, and, unique to the ACM version, nextColor() for a randomly generated opaque color, with values 0-255.

The first example used was to simulate a six-sided die roll with the code below. As someone who has had an interest in dice, from the six-sided up to the twenty-sided dice used in role playing games, this was a fun application.

 int dieRoll = rgen.nextInt(1,6);  

PseudoRandomness

But are the numbers produced by computers through random number generators really random? No, they are actually determined by a complex algorithm, based on an initial value. Given the same initial value, the seed, they will always produce the same sequence of "random" numbers. For most practical needs, however, pseudorandom numbers are sufficient because the user does not know the what the seed is and so cannot determine the sequence of values that will be produced. The ACM RandomGenerator uses the system time in milliseconds, which no one will know, for the seed.

A process (or data produced by a process) is said to be pseudorandom when the outcome is deterministic, yet also effectively random, as long as the internal action of the process is hidden from observation. (NIST.gov)

Of course from a programming perspective, it's good that, though seemingly random to the user, the sequence is determined and will always be the same, given the same seed. That's for the purpose of debugging. If there was a problem in your program and it only occurred when a certain "random" number was used, you might have a very hard time tracking down the bug. If, on the other, hand, you can set the seed used and so always produce the same sequence of numbers, it will be much easier to reproduce the problem and find the bug that is causing it.

In a future post I want to write about a virtual dice throwing app that I just installed. Rather than just generating random number results, it uses a physics engine to throw the dice and the dice will even interact with each other, affecting the way that they land, just like with real dice.

i++

Been Looping for a While / 2 AM Debugging

It has been a while since I've written here on the blog. The primary reason was that work was just too busy. For two and a half years I was working on new website for our retirement plan participants and sponsors. Almost 20 internal employees and lots of external resources were working on the development of this site. It has lots of new features compared to the old site and everything had to be built from the ground up.

My role in the project, along with two others, was writing OmniScript to pull the needed participant data from our recordkeeping system and send it to the web in the form of XML. As each retirement plan has it's own set of features and options, this involved a lot of variations. I'll write later about some of these various aspects and what I learned through the project, which was a lot.

After a lot of work and some optimization, the site went through extensive UAT testing and was finally launched to participants at the beginning of December. Overall the launch went very well and it was great to see all of that work finally in use in production. Naturally there were some bugs that were found over the first few weeks and that continued to keep us busy. Finally, though, things are slowing down, at least until the next big project, and I plan to get back to blogging about my experiences in learning programming.

2 AM Debugging

I just wanted to share one programming story, going along with the new website. When you become one of the experts on a new website that allows people control over their money, their retirement savings, then when there's a problem, your phone can ring at any hour of the day or night. I discovered this on New Year's Eve. I hadn't been in bed for long when I noticed at 2:00 AM that I had a couple of missed calls and texts. With the turn of the new year, something was preventing anyone from logging into the website.

So I woke myself up and called my boss back and proceeded to get logged in to find out where the error was coming from. I was probably not at my clearest thinking, and as it was coming from a script that I had not worked on, it took a little while to figure out the problem. By 3:00 AM I had found the problem, a logic bug that, with the turn of the year, was causing the low date in a date range to be higher than the high date. This produced a fatal error.

My boss and I talked it over and decided on a temporary fix that would work until we returned to the office. By 3:30 I had made the fix and people were once again able to log in, though who's trying to log in to their retirement savings site at 3:30 AM on New Year's Day, I do not know. 😃

i++