Week 12
What did you do this past week?
It was the end (discounting the upcoming due date) of a pretty busy few weeks for me, as I finished up some homework and exams that were put off because of projects.
What’s in your way?
Not too much. We’ll see how the rest of the semester treats me.
What will you do next week?
Next week is hopefully a “normal” week, as in no projects or exams due; this should allow me to get homework done early and start working on upcoming projects, and maybe I’ll even have some free time!
If you read it, what did you think of Paper #12: More Getters and Setters?
I think the author has a point, but they aren’t communicating it very well. The paper is bogged down by long code samples and explanations weren’t very clear, as could be seen from the variety of confused annotations.
The paper is very much focused on an object-oriented point of view, using data abstraction and creating lots of boilerplate in the name of making code maintainable. While reading it, I theorized an alternative functional design. If the Employee class is equivalent to a functional module
module Employee(name, id, salary, make) wheredata Employee = {- private -}name :: Employee -> String
id :: Employee -> String
salary :: Employee -> String
make :: (String, String, String) -> Employee
Yes, these are basically ‘getters’. But it’s no different than a builder that has functions interfacing with name, id, and salary, which also provides an internal view into the employee.
Writing UIs is still simple; create type classes
class ToHtml a where
toHtml :: a -> HtmlRepclass ToSomeUIFramework a where
toSomeUIFramework :: a -> UIFrameworkMonad ()
And when you need to use Employee with some UI, define the appropriate function and use it (the inclusion of monad just shows you can have varying types for the function). The type classes are completely unnecessary, but serve as some analogue to builder classes, except they aren’t actually classes, but simply show the fact that you would define functions that handled UI instead. So abstraction just happens behind a function rather than a class.
What are the disadvantages? Well, maybe you need to be able to do UI to the same framework in different ways. The builder pattern would create two different builders, but we seemingly run into the roadblock where we can’t create two different implementations of toHtml, for example. But we can! Just make two different functions. The typeclasses are decoration anyways, and you would hopefully describe those functions different anyways. It’s no different than two different builder classes, and arguably less verbose.
Another disadvantage was alluded to in the paper — what if the builder interface changes. This is certainly terrible, and it’s terrible because this is bad design. The open-closed principle says that modules are open to extension but close to modification, so you shouldn’t be modifying the interface at all. In the case that you need to, yes, this design is certainly bad. But what change warrants an interface modification besides harebrained design from the beginning? There are so many other options, like adapting the interface, that you can go through before resorting to modification. And the OOD implementation shares much of the same disadvantage in that there could be many builder classes floating around that need change.
The paper definitely showcases a good usage of object-oriented design though. There’s just also different paradigms that exist and have the same capabilities (perhaps with minor advantages or drawbacks).
What was your experience of cross join, theta join, natural join, and SQL?
Cross join, theta join, and natural join were pretty easy to understand. It’s basically relational-algebra-specific compositions of filtering and mapping, which was demonstrated to us by the exercises we did. I would have enjoyed more discussion and less exercises though; there were four exercises in a row, doing remarkably similar things, and they felt more like Python exercises than understanding databases.
SQL was fun. Since it is a language with a limited domain, it can get away without many generic features that allow us to write typical programs, and provide syntax that is a lot clearer in the domain of databases. A lot of it reads like English, which makes it pretty easy to understand what the code is going to do to the data.
What made you happy this week?
Finishing up an exam gave me a bit of time to relax.
What’s your pick-of-the-week or tip-of-the-week?
C++ coroutines are cool, albeit clunky. They’re defined in the coroutine TS in C++20, which provides a bunch of very versatile low-level tools for building suspendable and resumable computations. You can replicate the generator pattern with yield in python using this, as well as do asynchronous computation by scheduling suspended coroutines. There’s a huge amount of customization to be had, which isn’t necessarily the tool for a user, but provides a good groundwork for someone who wants to write a coroutine library.
