Mar 30, 2017
Implicit Parameters in Scala
Because Scala compiler can infer types that are not explicitly declared, it also makes it possible to use implicit parameters.
Because Scala compiler can infer types that are not explicitly declared, it also makes it possible to use implicit parameters.
One of the arguments used to praise functional programming is that “it is easy to reason about”. In a simplistic sense, it is in fact easy to think that something takes an input and returns an output. But there is much more to that argument.
When we start thinking about how to represent data in Object Oriented programming, we usually think about a way to make it extensible, so that we can use some design principles that will allow us to make changes to the program without changing existing code. With functional programming, that can be a little bit trickier.
A quick answer to the question of the title of this post is: it allows us to use pattern matching when comparing its instances and it does not need the keyword new in order be initialized. But why? How?
While building a toy HTTP server, it is possible to easily identify things that can impact its performance: how we read a file and send it through a socket is one of those things. There are many, many more variables to that equation if we are dealing with a real world server, but we at least get the basics right while we have only a toy server.
When dealing with generic polymorphism and type parameterization, we can set some limitation to which type a method can accept.
Scala, as a functional and an object-oriented language, can implement both subtype and generic polymorphism. The first one is usually associated with OO languages, and the second, with functional.
From all the SOLID principles, I think that the “O” is the most difficult to understand. The definition of the Open-Closed Principle (OCP) says that Software entities (classes, modules, functions etc) should be open for extension, but closed for modification. We use the design principles in order to be able to adapt for future changes without having to modify existing code, so that definition seems redundant and unhelpful.
About 8 years ago, people were discussing how helpful technology had been during the election. It was the first time that candidates intensilly used social networks to reach voters and get donations. On the election night, The New York Times had an app showing everything we needed to know about the results. At that time, it was new and exciting. Now, back to 2016, the discussion is about how damaging technology can be.
The use of packets in the TCP/IP connection made possible for multiple transfers of data to happen at the same time. A packet is very small and so many of them can be transferred on the same wire. And, of course, servers can accept more than one connection at a time. This is often done with the use of Threads.
Understanding how to develop a server that is able to receive a simple GET request and send a simple response is relatively easy. There are tons of good resources to help us with that. Testing the server is the most difficult part.
The server has a socket that listens for connections at a port of a given number. When that socket is created and bound to a port, it starts accepting connections. It does it by creating yet another socket, that will process requests and responses. Wait. What?
In the Internet Protocol Suite (TCP/IP — subject of the previous post), the application layer on the client side writes to a stream that is then passed to the transport layer. On the server side, the layer reads from a stream after data is reassembled by the transport layer. But what is that stream thing?
If you ever tried to understand how your computer connects to the internet, you probably learned that a client — usually, but not always, a browser — sends a request to a server, located at the address you typed in in the browser’s address bar; then the server sends back a response to the client. That’s is pretty accurate. But there is much more to that.
If a function is declared inside an object, is it a function or a method?
One of the first things we learn when we start writing Scala code is that var is mutable and val, immutable. And that we can use them whichever way we need. But no beginners tutorial says that we should not use vars inside an object.
The Scala evaluation method makes it more efficient to use immutable values, but it still give us the chance to easily deal with mutable data. It is possible to write a program following the Functional Programming paradigm while being able to rely on mutable variables. Thanks to that, it is reasonably easy to implement the negamax with alpha beta pruning algorithm, improving the performance of an unbeatable computer in a Tic Tac Toe game.
In dynamically typed languages, it is a trivial task to write functions that return something or nothing. In a statically typed language like Scala, something does not have the same type as nothing. It is possible to check if something exists and handle the exception, but this is not exactly a good way to solve that kind of problem. Having an Option is.
The same way that expressions can be written in different ways, code written in Scala can also be evaluated in different ways.
The fact that Scala can be written as an Object Oriented or a Functional language gives us at least two different ways to accomplish the same thing. But it is not only that: common tasks, like defining a function/method, also can be done in different ways.
Clojure has a special way to guarantee the tail recursion optimization, with the macro recur. In Scala, we can call the function by its name, but there is also a special notation to make sure that the optimization will happen.
After three months as a student apprentice at 8th Light, I’m starting over, now as a resident. And this is not something trivial. I moved from another city to Chicago because of the apprenticeship, and of course I really wanted to continue in the program as a resident. I couldn’t be happier with the project that I developed as a student and with the project that I started working on.
If the thread macros that I wrote about on the previous post are a nice way to make nested forms easier to read, destructuring is a technique that makes code easier to read by making binding a more intuitive process.
The thread macros in Clojure are an excellent way to make things clearer and easier to read, but it can be hard to understand what they do and when to use them.
One of the requirements of the Tic Tac Toe was that the user should be able to quit a game. Simple, right? The detail was that it should not only quit the game, but also clear the terminal screen.
Last week I spent some hours re-reading and testing manually the functions that handle the medium computer. One of the tests wouldn’t pass, and it was hard to figure out why: the code was right, the test was wrong.
After adding an easy computer and an unbeatable computer to the Tic Tac Toe game, it was difficult to think was a medium computer would be like, how it would behave, what kind of moves it would make.
I tried to use Vim a couple of times before and I never went very far. It felt overly complicated and other code editors would do the job just fine. None of the reasons to use it — it has a lot of plugins, you’ll be very fast when you get used to it — seemed good enough. Other editors also have tons of plugins and you can be fast when you get used to them. But then, the real reason to use it came up.
One of the most interesting things that can happen while working on a project is dealing with the unknown. So, everybody knows how to play a Tic Tac Toe and knows how it works. But, what if we play with symbols other than x and o? What if we can give the option to save the game? What if we play with a 5x5 board?
Just like the minimax, I thought that adding colors to the output of my Tic Tac Toe would be easy. And just like the minimax, it was a lot more difficult than I thought it would be.
Why would you rebase if you can merge without it? To keep things organized.
If you want to collaborate with a project, would you rather branch from the commit “animation works” or from “Add animation to homepage”. Which gives you the idea of a reliable point of the project? If the developer took care of writing a good commit message, can we trust that that commit is a good place to start working?
One of the multimethods that I use on the Tic Tac Toe project is related to how players select a spot on the board. The hardest thing to do while implementing the methods was, actually, dealing with dependencies.
The popular wisdom says that “He who chases two rabbits will catch neither”, or “Don’t spread yourself too thin”. Just like people, classes, modules and functions are also not good at multitasking.
It’s been almost two months since I started learning Clojure and I think I’m finally letting it go my problem with the documentation — that is, for me, one of the most complicated things about the language.
One of my recent assignments was to pair with another apprentice in the Game of Life. What was weird at first was the requirement to throw the code away after the game was done.
One of the requirements of the Tic Tac Toe project was that the screen should be cleared after getting an input from the user. Everything on screen should disappear, except the representation of the current state of the board. The problem was that my tests started to disappear as well.
Physical exercises can reduce stress, ease anxiety and depression, and boost self-esteem. Programming exercises can do the same.
This week, when one of my mentors sat by my side to talk to me about Git, it was a bit embarrassing. He looked at the history of the commits of my project and there they were: bad commits messages.
I always liked learning. Seriously. I was that kind of a kid that liked going to school to watch the classes that other kids thought it was difficult. And I was good at that. But when I started reading code, I started to question my ability to learn. If it would take me so long to understand what the names of the variables meant, how much longer would it take to read a whole program?
The minimax algorithm assumes that both players make the best possible move they can. What if one of the players makes only incredibly bad moves?
While debugging the minimax implementation, I decided to create a record named Game, so the analysis of the board could be done accordingly to the type of a game: if it is human vs unbeatable computer, human vs human, and so on. In total, 6 types of games, and 10 conditionals, depending on the role of the two players.
It finally came the day when I was asked to implement an unbeatable player in the Tic Tac Toe project. I had (horribly) done it before in Ruby, so I thought it would be reasonably easy: I knew the algorithm already and I thought I had a good grasp of how recursion works in Clojure. What could go wrong? Everything.
How easy would it be to use a multimethod that could handle multiple arguments? And what is the point of having such methods? Wouldn’t they add complexity to the problem? I deferred answering those questions as much as I could while developing the Tic Tac Toe.
There are tons of articles out there trying to help people to make the best use of the tools they have available: “Google Tricks that Give You Better Search Results”, “There Are More Things in Smartphones and Tablets Than Are Dreamt of in Your Philosophy”
While building my Tic Tac Toe, I came across a situation like the following:
After a week using Clojure, I think I finally started to get used to reading it. Maybe because I’m not a native English speaker or because I am used to Ruby, I’ve been having a hard time with some conventions.
As soon as I started working as a reporter some years ago, I heard about a guy who used to work at the same newspaper. He was famous for the things he wouldn’t do.