The semicolon wars or an engineering approach to communities?

Hayes, B. presents in his article: The Semicolon Wars (2006) [1] the forgotten relation between social and computer science's in such a relatable fashion that makes any developer, anthropologist, sociologist or philosopher take a laugh. But, how can these fields of study be linked? As you can assume from the title of this entry, the term community plays an important role in the understanding and interpretation of this article (not for nothing does the author explores this phenomenon the most throughout the lecture), and yet is discussed from a misconceived notion of the word. 

In order to create an objective critique, lets start with the basics. A community is defined as:

...the feeling and set of relationships among people. [2]

This implies that a community is not an idea, medium of interaction nor a programming language user base, but the homogeneous connection generated among species. Within the article, it is hinted that the identity feeling driven from using a specific technology is the main group-creation factor within the computational context, misunderstanding entirely the faction-oriented definition previously presented. Furthermore, it is explicitly stated that personal preferences among developers are enough justification to create, in addition to denounce, different programmable solutions. If these ideas were valid in a sociological scene, then there wouldn't be enough arguments to stop someone to intimidate and exterminate a contrasting civilization in order to establish an ideological superiority... this sounds historically familiar. Although these ideas may seem overemphasized, are the similarities in the technological with these ambitions that embrace this discussion. Programmers are not a sub-specie of a human being. As humans, our communities are created not because we embrace our immediate similarities, but because we joyfully criticize and judge our more intrinsic distinctions. [3] And it is in that hatred-driven evaluation where egocentric and individualist paradigms affect the development and prosperity of our industry. 

As a conclusion, it is kind of dangerous to approach programming languages as communities without explaining how should a community be understood. Personally, I think that a more unhuman-related approach was hinted in a clever way since it was stated that, in the technological context, a language is made not for its capacities but for the people that uses it. But that is not a community, is a group of people who supports and gives life to the programming paradigm using a specific terminology.  Sometimes, as programmers, we forget the impact of our opinions or we tend to justified based on the industry. Nevertheless, we are and will always be humans with the inhuman capacity to love each other as long as they work, think and feel as ourselves. 

Bibliography

1. Hayes, B. (2006). The Semicolon Wars. American Scientist the magazine of Sigma Xi, The Scientific Research Society, American Scientist, Volume 94, 299-303.

2.David M. Chavis & Kien Lee . (2015). What Is Community Anyway?. august 17, 2021, from Stanford University Web Site: https://ssir.org/articles/entry/what_is_community_anyway#

3. Community and Diversity. (1998). august 17, 2021, from The rural life center Web site: https://www2.kenyon.edu/projects/livingtogether/community.htm

Comentarios

Publicar un comentario

Entradas populares de este blog

Chat with Russ Olsen

Personally, it was a long ago since I had the pleasure to met the author of a book in person and I have never met the writer of any technical book. After this conversation with Russ Olsen, I must say that I'm very fortunate to be one of the persons who have had the chance to share the same, although digital, space as this programmer and for having Russ as the first of its kind.  Although we only shared with him an hour of the class, he had the chance to talked us about a bunch of things, technical and personal alike. I would love to summarize every one of them since I personally think that every word that was shared has a unique value. Nonetheless, as one of the focal pintos that he mentioned, simplicity is key and in order to keep it within this post, I will only highlight those aspects that I found more interesting in three sections: 1. About his life:  Hobbies are everything and, as he hinted, they somehow help us to achieve better opportunities as well as to prepare us for new
Leer más

Functional Programming: A present solution for future problems

If you read the past entry, you can be thinking by now that I will develop another sociological analysis. Nevertheless, Hinsen, K made such a concise and straight-forward article that the only thing I could add to its discussion is an objective opinion. The promises of functional programming, (2009) [1]   presents to the reader an easy-to-understand approach to one of the toughest, yet simple topics I've ever faced as a computer science student: Functional Programming. When I started to program back in 2018, I never imagined the different tastes of problem-solving strategies used in the technological industry. I was happy as ever solving problems with  Python's functions and thinking that my whole career would be about using these procedure differently to solve any kind of situations Nonetheless, I was brutally taught that I was wrong when I began to study the Object-Oriented programming paradigm... god those were really tough times. Classes, Objects, Inheritance, Relations. a
Leer más

Rich Hickey: "Clojure, I'm your father"

In the episode  Rich Hickey on Clojure we get to know the Clojure's creator, Rich Hickey. As an introduction as well as a personal statement, I would like to highlight the basic idea in which Clojure was formed: Frustration.  The discussion starts with a brief explanation of the author's decision to create a Lisp-like language in 2009, same year where well-established technologies, such as Java, C++ or even Python, were becoming  mainstream tools throughout the industry. As Hickey mentions, although these programmable utensils were popular, all of them lacked the power of adding macros or different processes to run under compilation time. Furthermore, they all share a relatively chunky syntax, making them suitable for lazy in addition to unprepared programmers for unhanded data manipulation.  After 30 minutes, he roasted the entire tool-set I've been trying to completely master during the last 3 years... but he's right. As an entry-level programmer I have not met nor us
Leer más