Mostly Harmless – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn Mostly Harmless – InApps Technology in today’s post !

Read more about Mostly Harmless – InApps Technology at Wikipedia



You can find content about Mostly Harmless – InApps Technology from the Wikipedia website

Perhaps the funniest part of looking at the trend of “considered harmful” essays throughout the history of computer science is their tendency to fall into meta loops of considering “considered harmful” essays harmful. As Jeff Atwood pointed out long ago on his blog post, titled “I’d consider that harmful, too,” the first, landmark “considered harmful” essay came in Edsger Dijkstra’s 1968 paper “GOTO Considered Harmful,” which was met decades later with “‘GOTO Considered Harmful’ Considered Harmful” and then further down the rabbit hole, with “‘ “GOTO Considered Harmful” Considered Harmful’ Considered Harmful?”

Only programmers (or perhaps philosophers) could reach this level of nesting without having their heads explode. Even writing that last sentence (I think I closed all of the quotation marks properly) would be difficult for most editors.

If only those getting lost in the nested loop of “considered harmful” arguments would avoid else and return early, as developer Tim Oxley argues in a blog post (authored four years ago now) that has been making the rounds this week. Is Oxley’s post simply another “considered harmful” essay, in the long tradition of cantankerous and plaintive programmers? Do we discard any argument simply based on the idea that they rail against dogmatic practices, themselves leading to dogmatic practices of a different variety?

For my money, the meat of this argument is in the argument around it. While there are classically, college-educated coders aplenty, there are also many of us self-taught types out here too, and I find, at least, that these Internet discussions are where I learn the most.

Back to the topic at hand, in the essay Oxley offers a four-point tl/dr; –

  • Return as soon as you know your method cannot do any more meaningful work
  • Reduce indentation by using if/return instead of a top-level if/else
  • Try keep the “meat” of your method at the lowest indentation level.
  • Error handling is noise.
Read More:   RFI stands for what? How to write software RFI

Now, is it that simple? Should you discard your traditional method of if-then-else statements? Is this just else considered harmful? Should you move to fail-fast and return early? Have your years of if-then-else-exit been leading you astray?

As one Reddit commenter points out, “early returns are a bad thing if you are using a language which needs to clean up thing before returning,” noting the need to “release memory, sockets, file handles and other resources.” And yet another reply regards that this is necessary in C++ while not needed in Javascript, as used by the author. In another discussion, one commenter offers that this might just be a case of “guard clauses”, which has been formalized in Swift.

Whatever the case, perhaps back in the day of long-winded, scholarly retorts and eternally nested loops of “considered harmful” loops, we could just discard this argument as yet another example, but it’s right here where I feel like I learn the most. Heck, without it, I may have continued on unaware of this wonderful “considered harmful” phenomenon.

All that’s to say, thanks again anonymous Internet commenters and potentially unaware “considered harmful” authors for teaching me new things about the world. Here are some other new things I’ve learned about the world of programming this week.

This Week in Programming

  • TypeScript 2.8 Arrives With Conditional Types: Microsoft announced TypeScript 2.8, which it says “brings a few features that we think you’ll love unconditionally!” Italic emphasis intentional on their part, as one of the big parts of this announcement, is the inclusion of conditional types, which are a new construct in TypeScript that allow you to choose types based on other types. Of course, a defining feature of TypeScript is that it adds optional static types to JavaScript, which “help make guarantees about your code to avoid typos and other silly errors.” ITWorld summarizes this new feature as helping “with modeling of simple choices based on types at runtime while allowing more expressive design-time constructs. The construct takes the following form: A extends B ? C : D. It should be read as ‘If the type A is assignable to B, then the type boils down to C and otherwise becomes D’” Conditional types also offer a new way to infer new types from types compared against the new infer keyword, which introduces a new type variable.”
  • Google’s Cloud-Based Text-to-Speech: Google introduced Cloud Text-to-Speech as part of its Google Cloud Platform, which lets you choose from 32 different voices from 12 languages and variants. The company claims that “Cloud Text-to-Speech correctly pronounces complex text such as names, dates, times and addresses for authentic-sounding speech right out of the gate,” though if it’s anything like Google Maps’ attempts at pronouncing street names and the like, well… The Cloud Text-to-Speech feature is powered by WaveNet and allows you to customize pitch, speaking rate, and volume gain, and supports a variety of audio formats, including MP3 and WAV. Cloud Text-to-Speech is now available in public beta
  • Rust 1.25’s Bunch of Stuff: As we march onward toward Rust’s “Epoch Release”, we get another incremental release with Rust 1.25, which the blog post says “contains a bunch of stuff!” Rust 1.25 has upgraded to LLVM 6 from LLVM 4, and now allows for nested import groups, which allow for imports in a single line (or otherwise), depending on your preference. Also, in the language’s continuing effort to make learning Rust easier, Rust By Example is now included on doc.rust-lang.org. Those are a few of the highlights, but be sure to check the release notes and the blog post for full details.
  • Wear OS Developer Preview: Google’s rebranded Wear OS (previously Android Wear) was released in a developer preview this week, bringing Android P to wearables. The preview includes updated system images on the official Android Emulator and a downloadable system image for the Huawei Watch 2 Bluetooth or Huawei Watch 2 Classic Bluetooth. As Google is doing with Android apps in general, it has enforced a restriction related to non-SDK methods and fields in this version of Wear OS. In addition, the preview offers a dark UI system theme and works to improve power usage by limiting background activity, turning off radios when off the body, and turning off WiFi when Bluetooth is disconnected.
  • An Official TensorFlow YouTube Channel: Google also announced the TensorFlow YouTube Channel, which was used to livestream the TensorFlow Dev Summit being livestreamed on March 30. Shows include Coding TensorFlow, TensorFlow Meets, and #AskTensorFlow.
  • Android Studio 3.1: And joining the long list of dot releases this week is Android Studio 3.1, which SDTimes summarizes as including “a C++ performance profiler, Kotlin link checks, database code editing, IntelliJ platform update, new build output window, quick boot, and C++ CPU profiling.” Android Studio 3.1 is now available to download today.
  • Compatibility Without Complexity: JAXEnter offers a look at the recently proposed Go package versioning proposal, which it says offers compatibility without complexity. According to the article, Go has always had difficulty dealing with version information, but a new proposal goes beyond ad hoc tools to “provide backwards capability without increasing complexity.” Explaining that “Go 1’s big feature wasn’t actually any kind of language change or special function,” but rather “a simple promise: Go’s insistence on backwards compatibility,” the article highlights how this reliability for production use propelled Go’s growth. Unfortunately, this “leads to problems if there is any gradual code repair or partial code upgrades.” The solution? A new proposal from Russ Cox called vgo that “suggests that import compatibility and semantic versioning together require semantic import versioning.”
  • Containers? How About Serverless Instead? Finally this week, an argument by Matt Asay over at Infoworld suggesting that developers go ahead and skip containers and do serverless computing instead. While we have talked about Embracing That Thing Everyone Else Is Talking About in relation to containers, Assay contends that “as great as they are, containers have a built-in deficiency: They’re not nearly easy enough.” Describing serverless as offering developers a way to focus on writing application logic rather than server infrastructure, Assay also marks the need for developers to “trust that AWS, Microsoft, or Google get that infrastructure right, but the upside to embracing these cloud back ends is huge.” What do you think — containers or serverless, FTW?
Read More:   How to Automate and Scale Your REST API Tests – InApps Technology 2022

Google and Microsoft are sponsors of InApps Technology.




Source: InApps.net

Rate this post
As a Senior Tech Enthusiast, I bring a decade of experience to the realm of tech writing, blending deep industry knowledge with a passion for storytelling. With expertise in software development to emerging tech trends like AI and IoT—my articles not only inform but also inspire. My journey in tech writing has been marked by a commitment to accuracy, clarity, and engaging storytelling, making me a trusted voice in the tech community.

Let’s create the next big thing together!

Coming together is a beginning. Keeping together is progress. Working together is success.

Let’s talk

Get a custom Proposal

Please fill in your information and your need to get a suitable solution.

    You need to enter your email to download

      [cf7sr-simple-recaptcha]

      Success. Downloading...