Join GitHub today
Rethinking Zephir #201
After several months working on Zephir, we are very happy with the progress so far, in a few months we will reach a beta version and then we'll enjoy all its potential. We have reached over 1000 commits and counting and there's a lot to do. This project has allowed us to do a little more CS research and it has been very interesting for us.
Moreover, we must admit that we're not sure what will happen with PHP in the future, despite this, we are creating a tool which allows to take advantage of one the less exploited PHP features by the community at large (C extensions) and for a long time it has been reserved to experienced C programmers or advanced users.
Also in Zephir, we have found the opportunity to implement features that we have always dreamed of PHP but for one or another reason they are not a reality today:
We believe they will help us to build a better framework and it can help you to build your own tools in a new interesting way. Not everyone needs these features and not all may agree with them. However, we hope that one day these features will considered in the official PHP so we all can enjoy them. No matter what happens, we are sure that PHP will continue evolving regardless of the path taken.
Zephir was initially conceived as a high-level language that abstracts low-level details and allows you to compile your code. Currently based on a high-level representation it generates C code that can be compiled by leading compilers such as gcc/clang/vc with all the advantages that this brings to the table.
Nevertheless, we know that Zephir, being a high-level language, it could also function as a meta-language rather than just a DSL (domain specific language).
After thinking a bit on this I'm creating this thread to discuss an idea with you guys.
If we could restructure Zephir so that it can generate code in both PHP and C, this could make Zephir a much more powerful tool than ever before.
zephir generate c
zephir generate php
Using PHP libraries:
With regard to this we can:
a) Implement this now
Looking forward to your comments,
If time permits, I vote a), do it. This would allow Phalcon to exist on shared hosts that have a PHP version that's modern enough, enhancing reach greatly. It would also let people use Phalcon on GAE, and then simply keep their code intact when GAE finally does adopt Phalcon as a proper extension (at least in theory, right?).
How much would this implementation slow down Zephir's development? If by a lot, I vote b).
Regarding not being able to export C blocks and integrations with low level C libs, not sure how to approach that other than devs declaring their project for export to C, PHP or both.
This idea looks great. For instance, when I develop a library I want it to be available to all the PHP community and not only to those who can install extensions. As you said, extensions are not so widely adopted. So it would be cool if a PHP library can be used, and replaced with C-library in production. If that's possible to keep the complete compatibility that would be awesome. If a library can be distributed in both ways... Yeah, cool
Also I think PHP comes to era where it will get some metalanguages, as there was CoffeeScript for JS. If you can't deal with all the old dirty stuff with PHP and you need better structure, better syntax, etc, you can choose this metalanguage and not wait for PHP 5.XXX to have static typing, or short function calls. There are already few coffee-script-like projects for PHP but they are not so widely popular, just because they do not provide any benefits nor build tools for smooth development.
So I think that is really good direction to move on. I can't insist, I'm not sure that as a library developer I will use Zephir in nearest future. But I really like the ideas!
Right now - I'm against.
I love the idea.
In the near term, I think it's more important to become a DSL than a new scripting language.
The likelihood of adoption for a better programming language that runs in existing environments is much higher than a completely new language. Languages have been solved. Competing in that realm would be difficult.
Tool support will already be a long task to complete, adding another layer of compilation (including existing libraries in PHP) will only slow down potential adoption.
I vote B.
I am thinking about short-, middle- and long-term scenarios.
Our ambition decides its future. But so far, Zephir is still at its infancy. It's hard to decide to what or how it will grow.
In the short term, Zephir is definitely the coolest tool available in the PHP world. Now the threshold to create a C-extension is lowered dramatically. It's where it started.
In the middle and long terms, I cannot envision how it will evolve.
But in terms of "parents' hopes", maybe it can replace PHP as a new platform, with the PHP compatible syntax but as fast as C. Who knows (BTW, wasn't this HipHop supposed to do ? :) Or a PHP with steroids, like Scala, Groovy on JVM ? A new PHP with all the language beauties borrowed from Python or Ruby ?
I suggest we focus on the short term and near future, to make Zephir the coolest tool for PHP ever. Keep our brainstorming here and let's see how it will grow. Then we will know how to restructure our code base.
As for now, I vote B.
Delivering working stuff earlier is better then polishing stuff to the finest and releasing it later. So I think that main concern should be releasing stable Zephir & Phalcon 2.0. Don't see any use for generating PHP code for shared hosting. Cool feature as a bonus but not obligatory in my opinion.
My vote for C (or later on B if this kind of features are desired by others).
ps.: option A is a worst case scenario - Zephir & Phalcon 2.0 should be released as soon as possible
@DavertMik the PHP avg. level is really low, almost like JS community. I think that It is not a good idea to allow such developers to code extensions on C. Besides of that, try to code normal JS after the CoffeeScript. And if you know it very well I'm pretty sure you know that a more complex application looks ugly.
You are absolutely right about a library distribution. ZF3, Sf and other frameworks can be "packed" to native extensions. Great!
@phalcon, the community is huge. The idea is perfect. Voting for B, because I think you have to have a clear picture about your solution and the future of it. And it is all about ideas/help and proposals you can gather after release.
p.s. @ovr tabs are less important than spaces and print is faster than echo. or what do you think?
Thank you all for your comments, suggestions, time and votes!
It is clear that the majority of votes are for B and C. Of course, implementing this now would delay the development and this is not desirable. I personally vote for B, however, it's important to know that Zephir will probably offer this feature at some point in the future. Adding a second backend (PHP) would change the current identity of the project and it's for that reason that I wanted to discuss this with all of you.
Complete the generation and creation of extensions is obviously our priority. Both achieve a stable version of Zephir as Phalcon 2 are also priorities, however, with an open mind and for multiple reasons, it would be good to have the ability to use PHP as backend sooner or later.
For those who contribute to Zephir: Keep in mind that this could be implemented later and it would be interesting (if possible) prepare the future changes for this.
Do not know if the choice is made already but I vote c;
What I want for the future of Zephir is more tooling for a PHP to Zephir rewrite: that's how we can help the community: allowing fast extension creation for PHP librairies and frameworks.
Also B (I think).
I am loving zephir so far. Already released a php hal library (https://github.com/brandonlamb/hal-1) and am now working on converting Spot ORM to zephir.
I really like the idea of just having this sort-of like php meta language, I am finding it pretty easy and trivial to write in. I would love to see more features added like returning references, static::method() and overall stabilization.
A CoffeeScript for PHP project seems like (to me) it should be its own project, keep zephir a metalanguage to build c code and optimize the hell out of it.
@phalcon for now I changed my opinion. I think we should split Zephir into parser, AST-builder and code-printer. If we do it, we can easily implement any compiler: Zephir -> extension, Zephir -> PHP, PHP -> extension, PHP -> Zephir(very helpful for big projects), PHP -> PHP (5.4 to 5.3), Zephir -> hhvm extension, etc.
@nkt I like this idea. Breaking Zephir into loosely coupled components that do one thing well will make it more flexible and trivial to implement additional features later.
Once we proceed with that mindset, we can then concentrate on bringing out a stable version knowing that our effort will pay off later on when we decide to add other features, including those that we would not have conceptualised now.
Zephir is an awesome project and a dream language come true.
Then, if you decided to go in that direction, why not thinking in implementing a new cleaner & consistent version of the language itself? & producing a spec of what the language should be?
I mean for example get rid of array() and use  only, native utf-8, allow dot instead of this wierd "" for namespaces. Remove the use directive. And the nice features of Hack.
And remove all of the useless features or weird syntax of PHP that makes it inconsistent.