Re: Why is PHP not a "real" language?

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
+ (text/plain)
Delete this message
Reply to this message
Author: James Dugger via PLUG-discuss
Date:  
To: techlists
CC: James Dugger, Main PLUG discussion list
Subject: Re: Why is PHP not a "real" language?
Hi Keith.

Nothing wrong with PHP development. A lot of Drupal developers were not
happy with the changes from v5 to v8 which required more OOP knowledge.
They felt left behind.

Laravel is probably the most popular PHP framework. Due to its
straightforward implementation. Laravel is still a choice of even
enterprise level firms that want a PHP custom web solution.

And there is no reason why PHP has to be implemented using OOP. It is
certainly easy to write it functionally and stay in the procedural lane. If
you have heard of “the zen of python” I believe this should apply to all
programming and languages.

https://peps.python.org/pep-0020/

Happy programming


On Wed, Oct 5, 2022 at 7:16 PM <> wrote:

>
> Hi James,
>
> Thank you so much for your time and effort.
>
> I get lost in all of this because I am not an engineer nor do I work at
> the enterprise level.
>
> Lately I have been thinking a lot about the 4 events/or people for 1986
> or 1987. During this time frame I :
>
> 1) Went into a business that was being run on a Commodore 64.
> 2) Had a classmate that was programming the Commodore 64 for daycare
> operations.
> 3) Talked with a business owner that created a Basic program to run his
> business.
> 4) I began programming using dBase III on a garage clone. An 8088 CPU,
> 64k of RAM, 2 - 360k floppies, and no hard drive.
>
> These folks have been left behind.
>
> Doesn't this seem to indicate that this was really all we need.
>
> This was before the Internet. And the Internet has added a layer of
> complexity that if used correctly has it's benefits.
>
> When I go to CostCo I see text based screens circa 1980's - 1990's. I
> wonder if these screens were built using Ncurses. Maybe they are thin
> clients or run off some central main frame or mini.
>
> I'm a PHP developer. I am not an engineer. I've been a LAMP dev since
> 2006. I am about to learn NGINX - LEMP.
>
> Most of the world is small businesses that cannot afford a contractor
> for a short term project. I wonder what tools they have that they can
> use to automate their businesses. In the 80's and 90's there was a ton
> of tools for the DIY business owner.
>
> Between them and the enterprise is the layer I live in.
>
> I stick by my statement that the top level or enterprise engineers are
> driving PHP.
>
> I attended an AZPHP meeting about 3 years ago and was treated like I was
> some kind of align because of my thoughts and experience.
>
> Since I am an old guy and will never again work in the cube, I can
> afford to go against the grain.
>
> In my opinion the PHP bus has left a bunch of folks behind.
>
> I'm not knocking what you do. I can see there is a niche for such
> things, and I can see by breaking a project into multiple microsystems
> there is just a simple base and some APIs to define before the project
> begins.
>
> I am a simple LAMP dev and there is a huge demand for what I can do.
> AND I think that demand will continue for years... maybe 10 plus years.
>
> If the economy crashes like they say I think businesses will try to
> automate more which will create more demand.
>
> Keith
>
> On 2022-10-04 20:39, James Dugger via PLUG-discuss wrote:
> > Hi Steve,
> >
> > Perhaps the example I used of comparing microservices to breaking up a
> > framework is too simplistic and a bit contrived. There is no direct
> > comparison. You're not going to gain anything by breaking up a
> > framework into its basic parts. That said, what do you do when you
> > have a large company that needs to share data across multiple
> > services. It is also a bit simplistic to assume that you're just going
> > to use WordPress for one service and Drupal for another and then tie
> > them together in some way (which I have done) so that you can minimize
> > the code you write and stay with the OOP design of each. In both
> > cases most likely you will be using about 1 percent of the capability
> > of each framework but because of the way both products' event looping
> > works you will be wasting 90 percent of each server's resources to
> > complete each request, costing the company thousands if not hundreds
> > of thousands of dollars per month in extra compute time usage (the
> > real gross part).
> >
> > So software engineers build small single purpose services with
> > lightweight libraries allowing the interpreter to parse a thousand
> > lines of code rather than a million while making 1 tenth the number of
> > requests - thereby operating on tiny containerized instances of Linux.
> > And then someone packages these lightweight services as a SaaS based
> > control plane product and then sells compute services online and now
> > anyone can connect services together that can both rival the most used
> > WordPresses plugin system but with a service that can scale to 2 to 3
> > orders of magnitude more any traditional CMS framework model, without
> > spinning up any new services.
> >
> > Netflix is not just one website framework but hundreds of dashboards
> > (Views) that consume thousands of endpoints each controlled by a
> > microservice. It is estimated that one third of the internet usage
> > during any given week night after 7pm is requests to Netflix streaming
> > services - which are all handled by thousands of microservices.
> >
> > On Tue, Oct 4, 2022 at 5:20 AM Steve Litt via PLUG-discuss
> > <> wrote:
> >
> >> On Tue, 2022-10-04 at 00:26 -0700, James Dugger via PLUG-discuss
> >> wrote:
> >>
> >>> Microservices are nothing more than a way to break apart each
> >> piece of a
> >>> bigger framework that is tightly coupled (dependent on each
> >> other), create
> >>> an agreed to interface between the services freeing you up to
> >> write each
> >>> piece however you need to and in whatever language works for the
> >> needed
> >>> scale of that piece.
> >>>
> >>>
> >>>
> >>> Again, not unlearnable. Many ivory tower approaches with OOP have
> >> made
> >>> things difficult. And some engineers excel at taking a technical
> >> idea and
> >>> making it still more complex.
> >>
> >> So person 1 makes an entangled software suite, and person 2 adds a
> >> layer of
> >> abstraction to detangle? Am I the only one who thinks that's gross?
> >>
> >> SteveT
> >> ---------------------------------------------------
> >> PLUG-discuss mailing list:
> >> To subscribe, unsubscribe, or to change your mail settings:
> >> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
> >
> > --
> >
> > James
> >
> > Linkedin [1]
> >
> >
> > Links:
> > ------
> > [1] http://www.linkedin.com/pub/james-h-dugger/15/64b/74a/
> > ---------------------------------------------------
> > PLUG-discuss mailing list:
> > To subscribe, unsubscribe, or to change your mail settings:
> > https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>

--
James

*Linkedin <http://www.linkedin.com/pub/james-h-dugger/15/64b/74a/>*
---------------------------------------------------
PLUG-discuss mailing list:
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss