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
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:
In light of the surprise vote @derickr pulled (https://t.co/ToUheXtyQ1), and since P++ is getting all the flak for promoting a split that it isn’t the cause of (it’s designed to manage it, rather than create it) – I’m not going to spend any additional cycles on it at this time.
— Zeev Suraski (@zeevs) August 14, 2019
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.”
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.”
Which, to be honest, I wasn’t planning to anyway – as I’m going on vacation starting tomorrow
It was, either way, too early for this idea. It’ll make sense to discuss it if & when the fact we’d be splitting PHP anyway would be well understood.
— Zeev Suraski (@zeevs) August 14, 2019
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.
Today I spent most of the day tracking down a bug where checkboxes were getting squished on mobile.
Turns out it’s a weird bug with how flex handles checkboxes in child components.
After all day, the solution was one fucking line of code. pic.twitter.com/hb6uDzDltj
— Cecy Correa (@cecycorrea) August 14, 2019
- 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’.”
Me: coding is easy
Me, 5 minutes later: coding is hard
— Kelly Vaughn (@kvlly) August 15, 2019
Feature Image by TuendeBede from Pixabay.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.