Let’s face it: we can let our programming language biases and fandom get in the way. We can hate on PHP the way a native Bostonite hates on the New York Yankees and blindly heap praise on Go like an Apple fanboy with an unopened iPhone in hand. We read the latest surveys and language rankings with baited breath, in hopes of justifying our prejudices and emboldening our biases.
This “programming language dogma,” as API evangelist Kin Lane puts it, is more than just fandom, however, and it can really get in the way of getting things done. In the world of API design, however, its absence has been a boon. “The absence of programming languages in the API design, management, and testing discussion is why they have been so successful,” Lane writes. “People in these disciplines have been focused on the language agnostic aspects of just doing business with APIs.”
Now surely, this is not to say that there aren’t advantages of one language over another. Of course, there are. Different languages are good for different things, but the idea of “language agnosticism” caught my eye. Lane continues, explaining how these dogmas can trap us as developers.
“It is hard for developers to transcend their primary programming language, and learn multiple languages, or think in a language agnostic way,” Lane writes. “It is not easy for us to think out of our boxes, and consider external views, and empathize with people who operate within other programming or platform dimensions.”
There is nothing more annoying than when people try to fit programming language X onto another language. Yes, your language of choice has some features that may be “better”. But, there’s a reason you’re trying to learn the new language. FP people are the worst about this.
— Dahs81 (@Dahs81) June 15, 2018
And with that, we can get on with the language-specific or agnostic business of taking a look at the latest developments the world of computer programming in the week past…
This Week in Programming
- Continuing the Conversation about Rust: Rust core team member Aaron Turon continues his insightful look into the growing pains the Rust community has been experiencing lately and the steps they’re taking to address them in part three of his listening and trust series. We looked at the first post, about the difficulties the Rust community faced in the RFC process, a few weeks back and now Turon turns his focus on “one of the most intense discussions the Rust community has had: the module system changes that were part of last year’s ergonomics initiative.” The best part of these posts, in my humble opinion, is that they don’t focus on the technical issues at hand, but rather the social and group dynamics that are present in any number of large, open-source projects. If these sorts of contemplative, navel-gazing blog posts from someone who plays a key role in developing an open source language are of interest to you, keep an eye out, as at least one more post is in the works.
The most important part of any computing stack. pic.twitter.com/1UsxwLwnWi
— Steven J. Vaughan-Nichols (@sjvn) June 21, 2018
- Google’s Flutter Release Preview Available: Moving on to some news, SDTimes reports that the Flutter release preview 1 is now available. Flutter is Google’s mobile SDK for creating native applications, and this release “signals our confidence in the stability and quality of what we have, and our focus on bug fixing and stabilization,” Google wrote in a post. First announced last month at Google I/O, SDTimes reports that Flutter “has seen a 50 percent increase in active users and has become one of the top 100 software repos on GitHub.”
- End of Life for NET Core 2.0: A quick heads up, as Microsoft announced this week that .NET Core 2.0 will reach End of Life on Sept. 1, 2018. According to their schedule, “as a non-LTS release, [NET Core 2.0] is supported for 3 months after the next release. .NET Core 2.1 was released on May 30, 2018. As a result, .NET Core 2.0 will be supported until Sept. 1, 2018.”
- GitLab Releases a Web IDE: The latest announcement by GitLab — the GitLab Web IDE — seems to be a head turner for many. While some seem to question the need for a web-based IDE from GitLab, others applaud the news as yet another player entering the field. Unlike many introductory blog posts, though, this one doesn’t summarily list features and leave you with a link. Instead, the post offers some insights into the internal debate that led to the birth of this Web IDE. “At some point, it dawned on us that the repository view might be the right vessel. Jacob set up a proof of concept where he made our file viewer work in the context of a file editor. It removed the page refresh when switching between files and it approached editing from a branch perspective instead of per file. The result was the beginning of the Web IDE, although it was called the ‘repo editor’ at that time.”
Feature image via Pixabay.