On Writing Elegant Code – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn On Writing Elegant Code – InApps Technology in today’s post !
Read more about On Writing Elegant Code – InApps Technology at Wikipedia
You can find content about On Writing Elegant Code – InApps Technology from the Wikipedia website
There’s code, and then there’s beautiful code, amirite?
But what makes code beautiful? Is it being elegant and simple, or is it achieving the goals set before it? Is it being “profitable”?
Kent Beck, programmer and creator of extreme programming, offered an imaginary (though very real) scenario on Twitter that posed the idea of beautiful versus functional code this week that got some folks talking about the topic.
P1: Aren’t you ashamed of writing code like this?
P2: What do you mean by “this”?
P1: Sky-high cyclomatic complexity, inconsistent naming, & duplication.
P2: Oh, I thought you meant “profitable”, and the answer is no I’m not ashamed.
— Kent Beck (@KentBeck) October 31, 2019
The idea here, of course, is that code that gets the job done is nothing to be ashamed of, but several take issue, objecting that this sort of code introduces a technical debt that can reduce profit over time. “Paying off the technical debt later could become more costly than the profit — especially if the original dev has moved on and a new dev has to maintain it,” one person observed. Someone else, however, noted the creation of “code rot” sets the stage for long-term maintenance contracts.
Depends on what the code is for. There are applications that haven’t been modified in a decade that are still making people money
— Alex von Brandenfels (@bi_linguist) November 1, 2019
It doesn’t even matter if they get the follow-up contract or their competitor. They’re all the same. It’s just like a game of musical chairs. Without removing a chair.
— Christian Hujer ⌨ ♂️☮♻️ ☠️ ️ (@christianhujer) November 1, 2019
Others, however, still find that the idea of “profitability” is one that’s not directly tied to the developer’s realm of responsibility, although the entire idea of agile might tend to disagree.
Let’s talk to P2 like this:
Profitability is not your responsibility, or not your first responsibility at least; You don’t know if your code would be profitable when you write it. As I know, it is not even a known software quality factor. So, change the priorities in your mind.
— Mahdy Merry (@MahdyMerry) November 1, 2019
Beck, however, takes issue with another aspect of whether or not your code is beautiful, formatted correctly, elegant, what have you — the idea of shame.
You are correct, sir.
About 10 years ago someone came to us aghast that JUnit had circular dependencies. We shrugged and went on with our business.
What’s passed is passed. Does the next PR make things better or worse?
— Kent Beck (@KentBeck) November 1, 2019
Should you, the developer, be ashamed of writing code that gets the job done? Beck, for his money, seems to think that the end justifies the means. Meanwhile, another thread over on Hacker News crossed our feeds this week that instead looks to celebrate the most beautiful piece of code you’ve ever read — “an elegant snippet rather than an entire (well-engineered) codebase” that is. In the thread, we get a selection of code that does so much more with so little — something we might all aspire to but is, in fact, entirely unnecessary to get the job done.
One example is a program consisting of a single line of BASIC that’s said to create a maze (although even that is up for disagreement).
Or how about the single line read-eval-print loop in Lisp that’s as simple as “(loop(print(eval(read)))”? Then there’s the complete Lisp interpreter, written in just… 13 lines of Lisp.
Anyways, perhaps our purpose here this morning is to celebrate simplicity and elegance in code, all while not being ashamed when all we can do is write the not-so-beautiful code that simply gets the job done. Now, for the real issue with this conversation…
– “What do you mean by “this”?”
— João Farias (@JFThatsABug) November 1, 2019
This Week in Programming
- Rust Wants Your Blogs: That is, the Rust team has put out a call for blogs specifically about what you’d like Rust development to be like in 2020 in order to crowdsource ideas for an upcoming roadmap. Basically, you write blogs, the core team reads them, and then they write a “Roadmap RFC,” which is reviewed, commented, changed, and finally accepted, guiding them in the year ahead on where to focus their attention in the development of the Rust language. The deadline is Dec. 1, so if you have an opinion about where Rust is headed, or should head, write it up and stick it on the internet. They write that they’re looking for ideas about “almost anything having to do with Rust: language features, tooling needs, community programs, ecosystem needs… if it’s related to Rust, we want to hear about it.” Last year, the Rust team took the same approach and saw 73 blog posts, resulting in the 2019 roadmap RFC, so if you’re looking for inspiration, there you have it.
Technical debt is like doing to dishes. You can ignore it for a while, but eventually you’ll find you need to wash every dish you own before you can make a meal.
— Dave Cheney (@davecheney) October 30, 2019
- This Week in… Telemetry? Seems that telemetry has been on the ol’ collective groupthink noggin this past week, as the Linux Foundation hopped on the topic and penned a policy around data collection, storage and use. Makes sense, of course, what with the GDPR and whatnot. Gitlab, meanwhile, was thinking about telemetry also, but instead about implementing opt-out telemetry across a few of its products — an idea introduced earlier this month, met with much resistance, and then canceled this week in an email to all its users. In the email, they write their “main mistake was that we did not live up to our own core value of collaboration by including our users, contributors, and customers in the strategy discussion” and that “it shouldn’t have surprised us that you have strong feelings about opt-in/opt-out decisions, first versus third-party tracking, data protection, security, deployment flexibility and many other topics, and we should have listened first.” You think?
- Microsoft Wants to Give Back to OpenJDK: Last week, it was Amazon pledging to join the Java Community Process (JCP). This week, JAXEnter writes that Microsoft is ready to contribute to OpenJDK, citing a message from Bruno Borges, a principal developer advocate for Java at Microsoft, to the OpenJDK community at large. In it, he writes that “Microsoft and its subsidiaries are heavily dependent on Java in many aspects” and that the company “recognizes the immense value that Oracle’s successful and effective stewardship of the OpenJDK project has bought Java and the wider software ecosystem and we look forward to playing our part in contributing back.” How? Mostly bug fixes and backports to start, until the team better learns “how to be good citizens within OpenJDK.”
reverse engineer? buddy I can barely forward engineer
— brianloveswords (@brianloveswords) October 28, 2019
- Wanna Pay for TensorFlow? In the headline that wins the week for me, DEVClass mockingly asks if you’re itching to hurl cash at machine learning — because if you are, then Google’s newly introduced TensorFlow Enterprise is for you, with “support, better performance, and managed services to those willing to pay.” Of course, Google instead describes its service as providing enterprise-grade support, cloud-scale performance, and managed services, selling the enterprise offering with the reasoning that “because Google created and open-sourced TensorFlow, Google Cloud is uniquely positioned to offer support and insights directly from the TensorFlow team itself.” So there you have it — TensorFlow, at a cost, but with all those goodies you might want as a big business dabbling in AI. That should help sell it up the ladder, right?
- The Feeling Is Mutual: The debate has been ongoing for several years now, but the division between Perl 5 and Perl 6 finally reached a conclusion a few weeks back with the decision to rename Perl 6 to Raku. Well, that distinction has reached another corner of the internet, as one Perl blogger writes that the decision to separate Raku into its own subreddit, apart from /r/Perl, is “a sensible step forward for both languages.” Moving forward, the moderators write, /r/Perl will be for “the discussion of Perl 5 (and, I guess, earlier versions)” and not Raku, which will be considered off-topic.
- Atlassian for VS Code 2.0: One final bit of productivity feature news for you Atlassian Bitbucket and Jira users out there, the latest version of Atlassian for VS Code now lets you preview your pull requests and more. The extension was released earlier this year, allowing users to view and create issues, pull requests and pipelines from within VS Code, but it was missing one big thing – the ability to preview pull request diffs before you create them so you can catch any last-minute fixes. Well, now you can do just that! Atlassian for VS Code 2.0 also adds support for Server and Data Center deployments of Bitbucket and Jira, as well as a single view for all of your issues. If this all sounds exciting, go ahead and install the extension now!
junior developer position:
You must know:
Ruby on Rails
Computer Science degree required
Expect a 10 round interview process
And if you’re still alive after that,
— Donna Amos ☕ (@donnacamos88) October 28, 2019
Feature image by Samuel F. Johanns from Pixabay.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.