Here’s some random thoughts about technology and software engineering I’ve been thinking about lately. Because these topics are not yet mature enough to have a post of their own, I’m publishing these here in case someone else might find them inspiring.
Javascript’s structural weaknesses
I don’t like Javascript. It’s easy to write, and it’s easy to just bang things out in effort to be as productive as possible. After a while, you’ll notice you have a big ball of mud in your hands, if you haven’t been super careful and actually thought about beforehand how your software should be architected.
Granted, a good framework can help you in this by introducing a common set of layers and concepts. Even then, if you have an MVC framework, after a while you might notice you have controllers 200+ code lines long fetching stuff, updating views and whatnot. Your view usually has lots of stuff going on, and trying to update them in the same controller is just nightmare after the application gets to medium size. The complexity monster has not been contained.
Concept of building individual components seem to offer some solutions for this problem. One chunk of code is responsible for one part of the view, and responsibilities are clearly defined.
Another thing that bothers me even more is almost complete lack of types. My JS development flow is usually annoying process of coding, running the code and stepping through debugger trying to figure out why given function arguments were not in the correct format. Facebook’s Flow is an interesting attempt to bring static typing into JS development. I don’t have yet experience with it, so cannot say if it actually helps or not. It’s also an extra compile step in development workflow compared to just writing JS and refreshing browser.
Overengineered libraries
The IEEE have produced a report today where they strongly recommend that from now on, the discipline of Computer Programming should be officially renamed to “Googling Stackoverflow”. – Theallium
Overengineered libraries can be easily recognized by the fact, that you have to Google almost everything right down to precise syntax for each use case in order to do anything with them. On the other hand, some libraries are just intuitive to use, you easily grasp the concepts, syntax and more importantly, the intent of the designer how (s)he intended the library to be used.
How well a developer gets to grips with a particular library naturally varies greatly. If you have a choice, it’s a good idea to evaluate and use stuff that you feel comfortable with and therefore are most productive. I’m making a bold claim here that some libraries are objectively vastly more better than others in this respect, and therefore are superior choices for a development team as a whole.
One good example of grossly overengineered library is Scala database abstraction called Slick 3. I’ve used the previous version Slick 2 quite a lot, but Slick 3 was so different conceptually that I spent days just trying to learn how to do the most basic queries with it. Slick advertises itself as “Functional Relational Mapping (FRM)” library trying to abstract the SQL away into Scala collections API. Slick 3 however ups the game by making all queries asynchronous, therefore forcing to use futures and callbacks. Asynchronous, non-blocking, functional, reactive, offers reactive streams… Buzzword bingo is off to a good start. Trying to figure out Slick DSL usage is made worse by Scala’s concept of implicits, which means hiding function/method parameters by bringing them in “implicitly”, and making type conversions in the background. Slick utilizes them heavily in effort of trying to make the DSL seem simple and almost prosaic, but makes it very difficult of trying to figure out what really happens when you make an SQL query.
My learning experience with Slick 3 was very much “Googling Stackoverflow”, but because the library is still quite new, I wasn’t able to find answers to all of my problems and had to figure out workarounds for individual problems. In the end, I decided that the fight was not worth it and switched to more simple JDBC wrapper called Anorm. After that I was able to concentrate on the actual business logic instead of fighting with the DB abstraction.