• Home
  • >
  • Software Development
  • >
  • A Stricter, Bolder PHP That Died Before It Ever Was … But Still May Be – InApps Technology 2022

A Stricter, Bolder PHP That Died Before It Ever Was … But Still May Be – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn A Stricter, Bolder PHP That Died Before It Ever Was … But Still May Be – InApps Technology in today’s post !

Read more about A Stricter, Bolder PHP That Died Before It Ever Was … But Still May Be – InApps Technology at Wikipedia



You can find content about A Stricter, Bolder PHP That Died Before It Ever Was … But Still May Be – InApps Technology from the Wikipedia website

Now, before you go getting too excited, and before we even really name the topic at hand beyond the headline, know that the proposal is dead in the water, for the moment at least:

The idea, as it quickly came to be known, was that of P++, “a new dialect of PHP (code named P++) that will live alongside PHP, but won’t be bound by the historical philosophy behind the language,” as proposed by PHP co-architect Zeev Suraski. Citing “a growing sense of polarization” in his proposal, Suraski writes that “some folks just want to clear some legacy stuff” and see features of other languages as “sorely missing,” while the opposing camp consists of “folks who think that we should retain the strong bias for downwards compatibility we always had, that PHP isn’t in dire need of an overhauling repair and that as far as features go — less is more — and we don’t have to race to replicate features from other languages — but rather opt for keeping PHP simple.”

The solution, Suraski says, is to offer “a flavor where we’d, in fact, be able to introduce a wide range of changes overnight — a lot more rapidly than even folks in the former camp feel comfortable doing today” that would be “available in addition to the current one instead of replacing it.” The P++ moniker comes from the example of C++, a language that “evolved dramatically while doing exactly that – retaining downwards compatibility while introducing radical changes — including compatibility breaking ones — at the same time.” In short, P++ allow the team to “get rid of elements that have little going for them other than backwards compatibility” and “make much more radical changes a lot more quickly” — all alongside a rebranding, to move away from PHP’s “negative reputation among many developers.”

Read More:   Understanding Golang Packages – InApps 2022

While the initial proposal to the PHP internals list is a worthy read for passion alone, the P++ FAQ lays it all out clearly: P++ would live alongside PHP, be installed alongside PHP, and would share many of the features, all while allowing for changes to take place that would be too disruptive, after all, to the language that runs much of the internet.

Opposition to the idea, however, was rather swift, with many expressing their concerns — such as incompatibility in tooling, the non-trivial nature of converting PHP code to P++, and the one-way compatibility that would exist between a typed P++ and non-typed PHP. In the end, a non-binding straw poll vote on the feasibility of P++ unanimously decided to end P++ “before we end up spending this project’s time and energy to explore this idea further” and Suraski wrote that “it’s definitely too early to spend that level of energy on it at this stage.”

And so, for now, P++ is a non-starter — but an interesting idea nonetheless.

This Week in Programming

  • Get Yo’ GitHub Scholarship: First up, GitHub Universe is on the way this November, and the time is now if you happen to be a maintainer to apply for a GitHub Maintainer Scholarship, which offers free and subsidized tickets for active maintainers. The event takes place Nov. 13-14 in San Francisco and applications are due by 12 p.m. PT on Monday, Aug. 29. For you non-maintainers out there, there’s also the Inclusivity Scholarships, through which GitHub says it is “partnering with several local nonprofits and meetup groups to bring even more diversity to Universe.” Click through to apply and for details. Deadline on this one is 12 p.m. PT on Monday, Sept. 9.
  • GitHub Supports SSH Certificates in Place of Keys: While we’re on the topic of GitHub, one other bit of news — the company announced SSH certificate authentication for GitHub Enterprise Cloud, which the company says will give enterprises and organizations more control over how their members access their repositories. In essence, the company writes, “SSH certificates allow organizations to maintain sophisticated security policies, such as certificates that expire daily,” offering the example of “highly secure development workflows where, every morning, a developer fetches their daily certificate from a custom internal system or a readily available solution that is responsible for issuing them” meaning that “at the end of the day, the certificate automatically expires, and the developer is no longer be able to access any of that organization’s repositories.” For you security conscious GitHub users, they also note that SSH certificate authentication support for Enterprise Server is coming soon.
  • Gartner Says Low-Code Is On The Way: Low-code development tools, writes SDTimes, will be used for most application development by 2024, according to a report by Gartner. That’s quite the headline, right? The prediction comes from Gartner’s Magic Quadrant for Enterprise Low-Code Application Platforms which SDTimes quotes as saying that “by 2024, three-quarters of large enterprises will be using at least four low-code development tools for both IT application development and citizen development initiatives,” and that “low-code application development will be responsible for more than 65 percent of application development activity.”
  • A Perfect Example of Android Q: Android developers, pay attention — Google just released the source code for its Google I/O 2019 Android app, which notably uses Android Q, the soon-to-be-released version of Android that introduces a number of features. Of course, many of these new features can be found in the app and the source code, including gesture navigation, dark theme, and the Navigation component, along with a few others. So, if Android apps is your realm, this might offer a perfect example for some code by the code creators themselves.
  • npm Lays Out Its Roadmap: Javascript package manager npm has laid out its CLI roadmap for summer 2019, noting that npm v6 is down to bugfixes, for the most part, with v7 aiming at refactoring the installer, among other features, such as workspaces and playing nicer with Yarn. “Right now, teams that switch between npm and Yarn (or use both!) have a lot of strife,” they write. “npm reads and creates package-lock.json. Yarn reads and creates yarn.lock. These files easily get out of sync, and users get scolded by the tools that are supposed to be helping them. That’s not The npm Way.” There’s currently no release date set for v7, but the post ends looking ahead to v8.
  • On Deciding Against Microservices: If you’re a regular reader of InApps Technology, then you’ll already know that we are a bit gaga about microservices — but not against reason. Well, here’s a blog post that explores the opposite side, explaining why one company canceled its move to microservices. Why? Among the reasons listed were complications with third-party partners, an inability to sufficiently isolate microservices, and a company structure that didn’t support a microservices approach. The blog post is full of details and worth the full read, but this section sums it up nicely: “We were using monolith like a loaded term. As if saying ‘monolith’ implies something terrible, and ‘microservices’ implies something good. Once we looked past the stereotypes and branding, the development team had very few issues with our ‘monolith.’ It might have been one of the most pain-free parts of our entire system. It was straightforward to develop in and extend since it was mostly a passthrough to a third-party. We didn’t need to spend much time working on it. We had an excellent CI/CD setup, which made it easy to deploy and rollback. Our branching and testing strategies ensured that few issues that made it into production. Leadership set the direction of microservices without consideration for the challenges and state of our application. After evaluating it, we found that microservices weren’t a fit for us, and required significant compromises. The compromises robbed us of any of the benefits and meant that moving to microservices was a net loss. Microservices had been decided on without evaluating non-technical concerns like team structure and incoming work. After months of investigation and work, we abandoned the project and spent the remaining time performing some minor refactors to our ‘monolith’.”

Feature Image by TuendeBede from Pixabay.

Read More:   Introducing the GitHub CLI – InApps 2022




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...