When I’ve spoken to people about certifications (anywhere in IT, whether it’s programming, databases, sys-ops, etc…), I’ve always encountered very heated positions. There seems to be no middle term on this debate… opinions seem to revolve around the ones who think they are a great idea and the ones who actively dislike hate them.
Typical arguments I’ve heard in favour of them:
Learning the tools will make you a better builder.
We tend to live like everything is going well, as if failure would only happen at some big little moments in life, when things don’t go our way:
Broken relationships. Failed exams. Unsuccessful job interviews. A friend is not there for you. Sickness. But that’s quite unfair. Reality is way more subtle than that. What we perceive as failure is generally just a mismatch between our expectations and reality.
When you’re writing a library (or any code, really), you should make sure that you’re not only writing code which will cover your use case for it, but also that you’re doing it in a way that others could benefit from it. With this I don’t mean early optimisations, or functionality which could be easily labeled as YAGNI, let me be clear on that. But effective code should be self-explanatory, not only in the naming and its modularity, but also in the way it can be used.
More formally, on the JDK 8 Stream javadocs:
Intermediate operations return a new stream. They are always lazy; executing an intermediate operation such as filter() does not actually perform any filtering, but instead creates a new stream that, when traversed, contains the elements of the initial stream that match the given predicate. Traversal of the pipeline source does not begin until the terminal operation of the pipeline is executed.
Accessing an element of a List is NOT a constant operation
At least not always... this should be a pretty straightforward fact for any software developer, but I must confess that it bit me as I was implementing the Oracle MOOC homework in Scala for Week 3. Maybe I got too used to a particular implementation of a List, the ArrayList, which access any of its elements by an index in constant time. But it can only do this due to its particular implementation, we have to be careful when choosing our data structures.
Oracle MOOC on Lambdas and Streams: Week 3 homework in Java and Scala
Part 1: A file called “words” is provided containing a large collection of words. A template file, RandomWords.java, is also provided. In the constructor you need to read all the words (which are one per line) from the source file into a list (remember to use a stream to do this). You also need to write the body of the createList() method. This generates a list of the size specified as a parameter selecting words at random from the list read in the constructor.
Oracle MOOC on Lambdas and Streams: Week 2 homework in Java and Scala
Exercise 1: Create a new list with all the strings from original list converted to lower case and print them out.
For this week homework we’ll start using the infamous Java 8 Streams, finally, being restricted as we were last week. The Collection interface had a new method added on the JDK 8, a default one, called stream(). It will, as its Javadoc states, “Returns a sequential Stream with this collection as its source”.
Oracle MOOC on Lambdas and Streams: Week 1 homework in Java and Scala
This post is the first of a series covering the implementation of the home work for this MOOC by Oracle. The course is about Lambdas and Streams on Java 8, but I felt compelled to implement them also in Scala, and compare both implementations. On this post and the next two, I’ll try to explain the main differences between these implementations and the way both languages empower you to use high order functions as part of a functional programming way of solving problems.