As someone fairly new to coding, learning new languages is both fun and painful. When I heard we were going to be doing some web development, I figured Javascript would be involved, and I had a brief moment of panic. I am a frequenter of subreddits like /r/programmerhumor, or other humor-based tech blogs, and there is a lot of dogpiling on Javascript as a language. It gets a lot of flak for being very weakly typed, and for its default behaviors utilizing this weak typing leading to a lot of wacky and confusing results for people who aren’t deeply familiar with the language. A quick example:

When I discovered we would be using Typescript (And what Typescript was), it was a bit of a relief. The way that the language looks just feels more comfortable to me, especially as someone who has mostly been learning Java. I have been trying to expand my horizons as of late, and wanted to look into people that may feel the opposite. Maybe the verbosity and strictness of a strongly-typed object oriented language is bad if you know what you’re doing, and I found a very interesting blog expressing just that.

In the blog post “Shit Javascript Coders Say” by Dave Sag found here: https://medium.com/@davesag/shit-javascript-coders-say-7a2d2881228d,
he utilizes a very pointed and crass writing style to express his distaste for OOP and strong-typed languages in general compared to Javascript. He also does not like Typescript. One reason I find this funny is because in this Software Architecture class I am writing this blog for, there is a big focus on creating interfaces, organizing classes, and figuring out the best ways to group and create objects. These are all things, according to Dave Sag, that are not needed in Javascript, and that Typescript “encourages the use of these practices as a weak, wobbly crutch” (paraphrasing).

I found this juxtaposition very amusing, and would be very interested in going down the rabbit hole more and finding out about best pure Javascript practices, or if Mr. Sag’s views are commonly held in some communities (I found plenty of blog posts praising Typescript, for what it’s worth).

In my brief time with Typescript so far, I have found it a bit verbose and clunky (though I am certainly a neophyte coder). Hopefully as I continue to learn, these distinctions become more clear and I can post an updated perspective.

From the blog CS@Worcester – Alan Birdgulch's Blog by cjsteinbrecher and used with permission of the author. All other rights reserved by the author.

As we start to learn about more design patterns and their implementations in class, I wonder more and more about their application in the real world, as well as how they are perceived by modern developers. So far, for each design pattern we have learned, a relatively good job has been done in showing the advantages and pitfalls associated with them.

I became particularly interested in the Singleton pattern after finding the blog post: “Understanding What Singleton Pattern Costs You.” found here: https://blog.ndepend.com/singleton-pattern-costs/. There are also other sources I found that seemed to really dislike the Singleton design pattern, and I wanted to delve deeper into why that is.

In our in-class example with ducks, the Singleton solution seemed to make some sense for what we were trying to do. Rather than creating a new object every time we wanted our ducks to fly, we could have a single object and change its instance when needed. Because of the limited scope of what we were doing with the singleton pattern, we didn’t get a clear example of this practice potentially going south.

One way this can cause problems is that it can obfuscate code. Because a singleton is now essentially “global” and can be called everywhere, certain methods can do things that are part of this singleton that the method itself might not even indicate that it does. An example that the author of the blog provides is this:

In this example, the method is named BuildSimpleOrder, however, this method also logs the order. This makes it so you can make no assumptions about what your methods do, as many of them may have hidden behaviors. This has lead to a phrase that I have seen around tech blogs saying “Singletons are liars.”

This also causes problems in unit testing for similar reasons. Because you can use these singletons essentially globally, it can make it a lot harder to track problems in individual classes. This leads to high coupling. This also breaks the single responsibility principle – something that has been repeated in class a few times.

Learning about the different design approaches that we can take, with implementations evolving as the requirements change has been a good learning experience. It is becoming pretty clear that there is no “one size fits all” design and there can be advantages and pitfalls of each. However, I did want to do this deep dive on singleton, because I had seen it garner almost nothing but flak.

From the blog CS@Worcester – Alan Birdgulch's Blog by cjsteinbrecher and used with permission of the author. All other rights reserved by the author.