PHP As A Next-Generation Programming Language?

[Pajn]

You should try benchmarking those template engines against plain PHP, if performance matters you will end up not using a third party template engine. Even with some integrated cache mechanism third party template engines have to go thru some loops.

A template engine written in PHP will of course always be slower than PHP itself. However PHP is hardly the fastest template engine in the world.

Also if performance matter that much you should probably not use PHP or a similar level of language anyway.

[akincer]

There is a VERY PRECISE reason why this is so

I get it, I'm just saying there should be a way even if there's some new construct for inline SQL processing such that adding a second line isn't necessary.

[blackshard]

No, not being statically typed isn't a problem, it's a design decision which comes with both pros and cons like everything else. However using a good IDE radically reduces these cons (it's a very few cases PyCharm can't figure out the type and give you suggestions or warnings). But a good IDE is of much help in statically typed languages as well as you don't have to compile to see the errors.

I never said that being dynamically typed is a problem. Scripting languages usually are dynamically typed. But python is also strongly typed, and this requires a bit more attention during the development because the wrong type can cause an exception during run time

I haven't noticed any i Python 3, can you give an example?

I cited the threading module. Not a great issue though, at least it has both the conventions implemented.

This is true in PHP, Java, C# and a lot of other languages. They just provide different syntactic sugar for saying "This is internal, don't mess with it".
Python don't have syntactic sugar it have a convention that names starting with _ is internal and shouldn't be messed with.

Well no... this is not exactly the same thing. In Java, PHP, C++ (dunno C#) you can declare an attribute or a method as private, public or protected. You can't do the same in Python. In Python you have a convention (use the _), but nothing prevents the access to an attribute or a method that is not supposed to be accessed outside the scope of a class. That's the peculiarity of duck typing.

What is hard with that? and how does it differ from other languages?
Nested situations is always hard and should be avoided. A maximum of one level nesting is okay.

Nothing is hard, but the python duck typing approach is to prefer the try/except instead of test for an attribute.
You got a variable named mypet and you don't know if it is a reference an instance of the class Dog, an instance of the class Cat or None.
You could use isinstance operator, but this is not pythonesque. You end up with something like this instead:

try:
 try:
  mypet.bark() # See if mypet is a Dog
 except:
  mypet.meow() # See if mypet is a Cat
except:
 print ("You don't have a pet") #mypet is not either a Dog or a Cat

Which is also much faster in python than the straight approach with isinstance.

As Python is garbage collected you can't know when (or if) an object is destructed. Personally I would never use __del__ or anything similar in a garbage collected language because of that. Also there is no need for a destructor in a garbage collected language as an objects referenced objects will be cleared automatically too.

Well, maybe I used the wrong word talking about destructors. I would mean a "deinitializer", as the opposite of __init__ method. Someone correctly told me about with statement (does exactly that, but someone also discourages the use of with...). What I don't understand is why such a deinitializer can't be implemented automatically as a class feature exactly as __init__ is.

By saying that I have to wounder how much you have programmed for the web the last ten years?
Python, PHP, Ruby, Javascript and others all makes huge use of template engines. Yes even PHP with is a template language of itself is usually used with a separate template engine as it gives better View logic and View render separation by having a more limited feature set of the template engine.

[/QUOTE]

I'm a stable worker for a web company for two years actually, and before I always had jobs involving websites and portals.
Much probably you misunderstood what I wrote above.
BTW, I wrote my own template engine for the company I work for, and I assure you that View logic is perfectly separated from the Controller logic. The templates are HTML/XML/TXT files with short inline PHP code like this:

<html>
<head>
<meta title="<?php echo $page_title ?>">
</head>
<body></body>
</html>

and I don't see what's wrong with this, since PHP is made exactly for this purpose: http://stackoverflow.com/questions/4...emplate-engine

You can easily create a class which gets the variables assigned, and then calls the template execution in a isolated environment sorrounded by ob_start and ob_get_clean to obtain your populated template in a nice string you can finally cache or fetch to the sink you like.

This is *much* faster than using any template engine and it is also neat because you don't have to learn another pseudo-language to do the same thing the native language is already good at. The key to success is to avoid the obvious bad practices (do complex math, manipulations and queries inside the template).

[blackshard]

The point of the article is that someone whats PHP to be where Ruby, Python and probably few other scripting languages are now - as a much more multipurpose language. They have desktop UI toolkit bindings, many system oriented libraries, many specialized ones (scientific, electronics/internet of things, mobile OS bindings/basic solutions) - and community that develops, use and maintain them. On the other hand they aren't as specialized on web as PHP, so if PHP wants to be really multipurpose it will have to take into account that it will loose some of its strong web orientation (and backward compatibility to some extent).

Mmmh, I don't share the same conclusion. The article never talks about a general purpose PHP, and actually I share many of the ideas that guy talks about. Killing ancient concepts, tidying up the language, static typing (there already is type hinting when calling functions and methods, and I always use it when I can), making things a bit more consistent and PHP would be a shining programming language for the web.

Python instead is already a general purpose language and it is nice as it is. Well, should be somehow multi-core friendlier (just don't tell me to use the multiprocessing module to spawn a new process each time I have things to do in parallel, we're not in '70s anymore...) and then it would be perfectly fine for general purpose apps.

[caligula]

Oh, no. Kill it with fire!
And learn Haskell and Yesod.

Why would you waste your PhD talents on stupid web programming when there are millions of idiots who are perfectly happy with PHP coding onerous tasks generated by retarded business cretins?

[JoeTennies]

Mmmh, I don't share the same conclusion. The article never talks about a general purpose PHP, and actually I share many of the ideas that guy talks about. Killing ancient concepts, tidying up the language, static typing (there already is type hinting when calling functions and methods, and I always use it when I can), making things a bit more consistent and PHP would be a shining programming language for the web.

Python instead is already a general purpose language and it is nice as it is. Well, should be somehow multi-core friendlier (just don't tell me to use the multiprocessing module to spawn a new process each time I have things to do in parallel, we're not in '70s anymore...) and then it would be perfectly fine for general purpose apps.

I'm actually a little intrigued as to the disdain for multiprocessing. I'll admit I work in a different world than most in safety critical embedded systems (so no actual Python in most of my "real code"). The issue I have with threading is that I don't want access to everything else the other side is doing. In fact, I want to minimize that so I don't have to worry as much about resource contention, race conditions, etc. multiprocessing has Pipe and Queue to set up explicit data sharing points. Resources still must be shared via Lock calls (or just message the other side to do it). If you want to share a value not through a Pipe or Queue, there's Value and Array or Managers for more complicated scenarios. It even has a built-in Pool object.

I think green threads w/ no global state (a la Erlang, gunicorn, Twisted, or Tulip) solve the I/O limited case for threading quite well. This is the situation where you may have thousands of threads of processing open.

I also think either multiprocessing properly handles the CPU limited case, while being safe about not affecting the global state. (ZeroMQ handles going to multiple computers fairly easily though.) In this case, you shouldn't have more than a few threads of processing opened at a single time anyways. Anything over #CPUs simultaneously isn't helping anyone. They are a bit heavier than threads, but forking isn't anywhere near a 2x memory use increase. In fact, it's copy on write for the pages, so much of it should remain the same.

[Pajn]

I never said that being dynamically typed is a problem. Scripting languages usually are dynamically typed. But python is also strongly typed, and this requires a bit more attention during the development because the wrong type can cause an exception during run time

And in a loosely typed language the wrong type can cause the wrong behavior. Both need the same amount of attention to types.

I cited the threading module. Not a great issue though, at least it has both the conventions implemented.

I don't see why they are there, but it isn't something you need to care about as good ones exist as well.

Well no... this is not exactly the same thing. In Java, PHP, C++ (dunno C#) you can declare an attribute or a method as private, public or protected. You can't do the same in Python. In Python you have a convention (use the _), but nothing prevents the access to an attribute or a method that is not supposed to be accessed outside the scope of a class. That's the peculiarity of duck typing.

Even in Java, PHP and C# (I don't know about C++ ) a private field isn't privet. There is nothing stopping me from messing with a private member. It's just syntactic sugaring.

Well, maybe I used the wrong word talking about destructors. I would mean a "deinitializer", as the opposite of __init__ method. Someone correctly told me about with statement (does exactly that, but someone also discourages the use of with...). What I don't understand is why such a deinitializer can't be implemented automatically as a class feature exactly as __init__ is.

Because you can never know when that deinitializer will be called.

and I don't see what's wrong with this, since PHP is made exactly for this purpose: http://stackoverflow.com/questions/4...emplate-engine

You can easily create a class which gets the variables assigned, and then calls the template execution in a isolated environment sorrounded by ob_start and ob_get_clean to obtain your populated template in a nice string you can finally cache or fetch to the sink you like.

There is nothing wrong with that if you are very strict with what you do in the templates. However very few are.

This is *much* faster than using any template engine and it is also neat because you don't have to learn another pseudo-language to do the same thing the native language is already good at.

Any template engine written in PHP that is.

[nanonyme]

FWIW the problem above is solvable by using behavior-driven API's rather than API's ones that people pass arbitrary values and you have to guess what it is. The right way is not to check at all but just allow Python to raise exception when attribute is missing

[TheOne]

Any template engine written in PHP that is.

Could you give an example of such template engine which is faster than PHP templating feature and not written in C/C++
Benchmarks a plus!....

[blackshard]

And in a loosely typed language the wrong type can cause the wrong behavior. Both need the same amount of attention to types.

Not necessarily. PHP, for example, prevents wrong behavior having different operators for sum (+) and string concatenation (.). You can sum two strings and you will obtain the sum of the numbers, because the plus operator automatically casts the strings. These are little and apparently useless details that at last makes a lot of sense.

Even in Java, PHP and C# (I don't know about C++ ) a private field isn't privet. There is nothing stopping me from messing with a private member. It's just syntactic sugaring.

Absolutely it is not syntactic sugar, it is a proper implementation of data abstraction and OOP. You may access a private member of a class in PHP, Java or C# and C++, but it is not an easy task, it is discouraged and a bad practice just because you are not supposed to access a private attribute, since it denotes an internal state of the class instance and must be modified only by the instance itself.

Because you can never know when that deinitializer will be called.

Maybe when the instance gets destroyed? I mean, __init__ gets called each time an instance is created, no matter the reference counter. __del__ instead is called when all the instances of a class gets destroyed (or the reference counter reaches 0, if you prefer this way), but there any hook is called when the reference counter of a class is decreased.

There is nothing wrong with that if you are very strict with what you do in the templates. However very few are.

So it is a problem of unskilled programmers messing with templates, not PHP one. PHP is, by design, made to do that.

Any template engine written in PHP that is.

I absolutely not think so. I extensively used, benchmarked and profiled Smarty in PHP and just the instantiation of the template engine took more than half of the time to fulfill the whole request.