"To pair or not to pair"

Pair programming is not a new concept; it's very often talked about and throughout our classes, we've been told that we need to learn to work as teams because that's how it works in the industry. However, I don't think we've ever been taught actual pair programming. As the reading suggests, there's a very big difference between the practice and just programming together, and in school, we've mostly done the latter. 

The article talks a lot about how pair programming should be done, and it lists and explains its many advantages. It also mentions that it shouldn't be applied in every scenario, but proposes fixes for the most common "excuses" as to why teams don't do pair programming. Most of those excuses have to do with lack of compatibility between the two team members, which sounds as if you should have no problems with it as long as both parties are comfortable with each other. 

While I do believe pair programming can be very useful when done right, I also believe that it can be harmful to the participants if it's overdone. For one, if a knowledge difference exists, even if both parties are aware of it and are trying to balance it out, it can be very hard not to overstep when you know more, and just as hard to not step back when you know the other person could do it more easily. I think that if it's overdone, it can stunt the growth of both developers, and they would be better off working on different projects. 

However, when done properly, I do believe it can have all the benefits mentioned in the article, and I don't think we've learned about all pair programming has to offer, because as the article says, many businesses are afraid to implement these practices due to concerns of cost or efficiency. In my, albeit short, programming career, I've practiced pair programming a number of times, and although I think it did help me grow as a developer, I don't think I got the most out of it, and that could be due to the fact that I didn't know what the best practices were. That being said, I think properly learning these techniques, and knowing when to use them, can be very useful for both programmers and organizations as a whole. 

Garbage Collectors

Garbage collection is a concept that, although it is fundamental for every programming language, is not taught as such. It’s also  very simple (and maybe obvious): if you’re not using a resource, don’t hog it and let someone else use it. But at least in my experience, although I’ve heard the term since I first began studying computer science, I never really understood or paid much attention to it. Even today, even though I know what a garbage collector is and why it’s needed, I still don’t fully understand how they work, and I haven’t seen any more than the basics in my classes. 

That being said, I think Alexander Yakushev did a great job explaining how different algorithms go about collecting garbage, and I think more importantly, he made me realize that garbage collectors are more than simply processes that run behind the scenes to make my life easier while coding. In his case, working at Grammarly, it’s very important that memory is freed efficiently, since their plugin has to be working non-stop while a user is typing. That being said, improving garbage collection algorithms can greatly improve performance in any device, and is something every future (and current) computer scientist should be familiar with. 

Yakushev also hit on a very important point that I’ve heard across all areas of computer science I’ve explored: when it comes to software engineering, there is no silver bullet. It is not enough to know what your programs do; you need to know how they work, how they’re made, as well as their limitations, in order to make an informed decision and choose (or create) the right garbage collector for your program, and this applies (or should apply) to everything else that goes into your program, as it’s details like these that really separate a computer scientist from someone who just learned to program online. 

The Roots of Lisp

In the last two weeks, we listened to two different podcasts: one by Dick Gabriel and the other by Rick Hickey, both talking about the wonders of Lisp and Clojure, respectively. Both of those podcasts mentioned that one of the main draws of Lisp and other functional languages could interpret themselves, but I honestly hadn’t quite grasped the concept of how that was done. I haven’t read John McCarty’s original paper, so I don’t know how much of the praise should go to him, but I think Paul Graham did a fantastic job explaining how the seven primitive operators can form the basis for such a complete language.

Graham also mentioned that he saw Lisp and similar languages becoming the main model used by programmers in “the future”. And this was written in 2002, which is a very long time ago looking into how old computers are. And at least today, functional languages have found a home in many different applications, and with JavaScript being as popular as it is, more people are bound to discover functional programming and keep using it, at least once in a while. I think all of this speaks to the possibility of Lisp building on the popularity it has gotten recently, and becoming as mainstream as other languages we know today. 

I don’t know whether this is exclusive to Lisp or not, but I think its ability to be as powerful as it is while having such simple axioms will prove very useful for its longevity, as it means that “legacy code” won’t really be a problem, and it could make the code easier to understand, which is important in order to keep newcomers interested in using Lisp in one of their projects. I think that with all of their features, functional languages stand a real chance of being used alongside procedural languages for big projects and applications, but I don’t see them overtaking the languages most people work with in the near future. 

The Rise of Clojure

This podcast answered many of the doubts I had after listening to last week’s podcast on Lisp. First of all, although I haven’t done much in Clojure, so far it hasn’t been a hard language to get a good grasp on, contrary to what Dick Gabriel said on the previous podcast. Perhaps its because I’ve only been programming for a few years, and I haven’t yet found a language that I consider better than the rest, so the process of adapting and changing my mindset wasn’t as hard as he had made it out to be. I think Rich Hickey is much more on the nose as to why Lisp hadn’t taken off in popularity: it wasn’t easy to use with everything else. 

With Clojure, since it runs on the Java Virtual Machine, it’s way easier for someone to just try it for a small part of what they’re working on, and they’re more likely to fall in love with how it works, or simply understand that functional programming has its uses and keep it in mind for future projects. I think Hickey did a very good job identifying the reasons Lisp wasn’t as successful as some people believed it would be, and he did a really great job fixing it and making it more accessible. 

Clojure was scary to get started on, because its lack of “structure” makes it difficult to read to someone who has never seen it. At least that’s how I felt when I started this course, and I don’t imagine I would’ve ever tried it out for a project on my own, since it’s usually easier to stick to what you’re familiar with. However, after having learned its basics, I will definitely consider functional programming in my future endeavors, and I think the same applies to most people who have given any Lisp languages a try, a number that will only get bigger as languages like Clojure keep popping up and make this way of thinking more mainstream. 

A Short History of Lisp

I normally listen to podcasts while I’m driving to and from work, so when we mentioned podcasts in class, I thought my routine would stay the same. However, since I haven’t left my house for a few weeks, this was the first podcast I’ve listened to while doing absolutely nothing else, which I think ended up being a good choice, even if the podcast was never too technical. 

I really like how Gabriel relates programming to art, as I feel that it’s commonly (and mistakenly) said that computer science and creativity are on different ends of a spectrum. In my very short career as a programmer, I’ve seen code that I would easily consider works of art (and others, not so much). 

Since the course started and I started listening to all the things Lisp could be used for, I have been wondering why it only recently started picking up steam, but Gabriel mentions a very important point: it’s not an easy language to learn. He mentions that it’s not too popular with companies, and that makes sense as it’s relatively difficult to read, which makes it inefficient when multiple people and teams are working on the same projects. 

However, I do see the use of functional programming, as it facilitates a lot of things that are too complicated to implement using different paradigms. So even though I find it hard to believe that a language like this will ever become as widespread as some of the languages we see today, other variations such as Clojure, that work with the Java Virtual Machine, could be used alongside these other languages to create better results. 

The only part of the podcast that I’m not sure I completely understand is when he mentions the meta-circular interpreter. I fully understand that it means that the interpreter is written in the same language that it is interpreting, but it’s not quite clear to me how the program is initially interpreted. 

Everyone Can Code

This reading left me with a very sour taste, even if I’m a little bit hopeful for the future. The fact that the only reason women were once prominent in coding is because it was seen as easy and “secretarial” is mind-boggling to me. The only reason I say I’m hopeful is because I can’t think of any fields today in which the same happens to the same degree, which must mean that there’s finally been some real change. 

That being said, despite all attempts to get women into STEM fields, and specifically programming, I think that we still haven’t resolved the issue with the culture around computer science. It’s true that for a lot of people, their first approach or peek into programming is video games. At least for me, that’s why I started using a computer. And talking to my peers, that’s the reason most of them did as well. And that led me to start programming, and it got me interested in the field. 

This by itself causes the percentage to skew towards men by a lot, since culturally, it’s still more normal for boys to get into video games and the like. I’ve noticed that the women I study with don’t feel part of the community, or at least not as much as some of us men. I’m aware that this is mostly due to different personalities, but I can’t help but feel that sexism might have a part in it. 

As for the future, as I mentioned above, I am hopeful. Since I’ve entered college, I’ve learned and seen through younger family members that the fight to get girls interested from an early age is working, and as more and more women go into the workforce and gain positions of power, I believe the workplace culture won’t be as toxic towards them, and once that happens, they’ll be able to regain the equal footing they once had in this industry. 


Source:
Thompson, C. (2019) The Secret History of Women in Coding. The New York Times Magazine, URL: https://www.nytimes.com/2019/02/13/magazine/women-coding-computer-programming.html 

A New Paradigm

Konrad Hinsen’s The Promises of Functional Programming reinforces some of the concepts of functional programming we have been seeing in class, but it also reinforces some other ones. For example, from class I understood that a function always produces the same output when given a certain input. However, I failed to understand why that didn’t happen with imperative programming languages, as I was only thinking of functions in the mathematical sense. Now it’s clear to me that some of the things we call functions in the languages I’m comfortable with are everything but. 

I also found it interesting that although the reading’s sample codes are done in Clojure, it’s not mentioned as a popular language, and it’s mentioned how most functional languages are only used in investigation settings. Ten years ago may not seem like a lot of time, but it’s clear from this article that a lot can happen in that time; at least enough for Clojure to become such a popular programming language, not only when it comes to science, but also in application and data management situations. 

I don’t feel like I know enough yet to make an informed opinion on the advantages of functional programming, everything I have read so far points to it being better than imperative languages when it comes to parallelism. Assuming this is still the case, I’m excited to be learning a new paradigm and I’m looking forward to what possibilities this new way of thinking can open up. This is especially interesting to me because when I started programming, I found that changing my way of thinking in order to program correctly made me think differently in other areas of life, and helped me out a lot when it comes to problem-solving, and I’m hoping that functional programming can have a similar effect on me. 

Sources:

Hinsen, K. (2009) The Promises of Functional Programming

The One True King Language

The Semicolon Wars by Brian Hayes talks about the surge of programming languages since the first one was invented, and how the community is constantly evolving and trying to find the be-all and end-all programming language. While I understand the notion of how having a standardized programming language would be useful, I think the system we have now is better, and I don’t see a single language making a difference in how we understand programming.

For one, we currently have multiple programming paradigms, which are each more useful than others depending on what we’re trying to achieve. If we only used one programming language, it would have to encompass each and every one of these paradigms, and it would get very complex, very fast. This would make it very difficult to know everything about the language, and most people would focus on only some parts of it, which isn’t too different to having multiple languages to choose from.

Secondly, the article makes a very good point comparing programming and human languages, and it mentions that humans think differently depending on what language they speak. As mentioned in the article, this also applies to paradigms, and I would assume that it applies to programming languages as well to some extent.

By having so many choices, it’s also easier for people with different mindsets to get into programming easily. Having only one language would limit the amount of people that go into the field, and I think that would overall cause more harm than the good a single language could give us.

On a more personal note, I enjoy learning new languages and tinkering with the quirks of each one. I know that as time passes and more languages are created, we will probably get closer to one that will be able to do anything we tell it to. And if that day comes, I will most likely use it. However, in the meantime, I will continue to experiment with anything I can get my hands on, and I will be very happy while I do it.

Source:
Hayes, Brian. The Semicolon Wars (2006)

Getting Started

Hello, my name is Joaquin and I'm currently on my sixth semester of my Computer Science undergraduate degree as ITESM.

When I signed up for Programming Languages, I did not know what I was getting into, although I had heard some comments about it being a difficult course. While it's too early for me to confirm or deny that claim, I feel confident that with enough time, I'll be able to grasp the concepts and should be able to do well. So far, I really enjoyed yesterday's class and Clojure seems like a breath of fresh air, especially considering I haven't learned a new language in some time, so I'm excited to be doing it again.

During my free time, I enjoy playing tennis and playing video games, especially those with a competitive nature. My go-to game for a long time (around 7 years) was League of Legends, but I've been having trouble finding time for it since matches take too long. Recently, I've gotten into Hearthstone which is much easier to play in short bursts and fit into my schedule. I also enjoy watching movies and I like reading quite a lot, and have recently gotten into audiobooks as well due to my long work commute.

The last series I've watched to completion is Mr. Robot, and I highly recommend it to anyone who hasn't watched it (it's also a good idea to rewatch it once you've seen how it ends, as you pick up on a lot of things that are easy to miss the first time through).
Also recently, besides rushing to watch most Oscar-nominated movies before last Sunday, I also took some time to rewatch some older classics, such as Monty Python and the Holy Grail and the original Blade Runner. 
As for reading, I've recently started re-reading through one of my all-time favorite series: His Dark Materials by Philip Pullman. I am currently on the third and final book, The Amber Spyglass, and after finishing it, I plan to start watching HBO's new adaptation of the series, which recently finished airing its first season.