As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I was reading the article "PHP Sucks, But It Doesn't Matter" by Jeff Atwood.
In the comments he writes:
That said, I absolutely think it's important for PHP devs to be aware of the architectural limitations of PHP, and understand the alternatives.
What are those limitations and how do they compare with other scripting / weakly typed languages?
Also, what are the alternatives in those conditions where limitations need to be avoided?
There are basically two real limitations I see:
PHP is a fully synchronous language. This has impact on which things you can easily implement in PHP and which not. For example implementing a Long Polling driven chat application isn't trivial, because PHP would need block one process per chatter. I'm not saying it's impossible, you can hack around this limitation using some PHP Daemon library. I'm just saying that this is one of the cases where other languages, like JavaScript, are more appropriate (NodeJS).
PHP is slow. Please don't understand this an an offense. It's a fact that PHP - as implemented by Zend - is slow compared to other scripting languages. This typically is no problem when building websites, but you obviously can't do certain things: Implementing a ray tracer in PHP is definitely a bad idea - whereas in JavaScript you could do this.
But apart from that, I think that PHP is pretty multi-purpose. You can use it for nearly anything - and I do ;)
Take a look at the date. The article was written in 2008.
It means, that if you'll see the PHP5.3 advantages, you'll find there many things, like closures and namespaces, which were in other languages before. Some of them is already affected the architecture of famous frameworks, like Symfony.
And that list will never be complete.
Meanwhile, I meet a lot of people who think that "weak typing" language is an architectural problem itself.
Then, some people think that inline regex syntax is good thing in, for example, JavaScript, but others think, that "different language" must be written down in string constants there, as in PHP. Etc.
I'll take a stab at this without getting too into the nitty gritty:
The initial design of PHP as a collection of functions still shows through.
Object-oriented patterns that have been implemented in the latest PHP 5 releases are still half-baked and lack multiple inheritance (or "mixins"), proper module support, and are designed to be backwards compatible with the CoF (collection of functions) design.
Method overriding and callbacks are not supportive natively.
Closures. They are there, but they are very weak.
Errors vs Exceptions — methods are inconsistent in which they use (thanks again to CoF design), and error-handling is half-baked.
I'm sure I'm stepping on someone's toes here and I'll get any angry mob, but I'm also sure that I still didn't hit everything. It's largely subjective, but it's easy to see what is to dislike when you stack PHP up next to Ruby or Python.
I don't find it odd anymore that all of "PHP SUCKS" articles are coming from developers accustomed to established Microsoft technologies.
What I do find odd are statements that indicate that PHP is a spaghetti code. It's completely up to the author of the code whether the code will be spaghetti or if it'll use certain design rules when approaching the problem.
The reason a lot of PHP code out there is spaghetti code is because examples and tutorials are such that they don't teach beginners the good coding practices. Also, people are quick to grasp examples like hello world or connecting to MySQL, doing a query and looping over the result - but that's it, that's where ALL tutorials stop. I still haven't found a tutorial that covers the following:
what is a framework and what it helps with
what are data structures and data types (explained in a way a normal human can understand)
what is an array, what are array dimensions, how do arrays work, what are arrays useful for
what is object oriented code, why object oriented code, how does PHP do it, what is considered good, why are there patterns out there and so on
As you can see, a beginner programmer won't be bothered to learn all of those points outlined above, I know that because I was a beginner too and did all the mistakes beginners do. However, even if someone doesn't know how to program, they can still create useful applications.
Many popular scripts were written by people who knew WHAT they want to achieve, however they did not know HOW to properly design the environment (framework) in which they'll deploy their php code.
That's why we see scripts that become incredibly popular due to the ease of their use as a regular user which are hard to extend looking at it as a developer, using weird function names, odd coding conventions and no commenting.
Also, what's ridiculous is saying PHP is slow which is absolute nonsense. When I come across such statement, I want to shoot myself in the head for reading such a blog entry.
One has to know several things before making such a statement:
PHP is a scripting language, that means the interpreter is invoked every time someone requests a PHP page which takes A LOT of CPU power. That has been addressed by using bytecode caching mechanisms such as APC which stores the copy of pre-interpreted piece of the script in memory. The results are impressive, and I kid you not - execution for some of my scripts goes from 20 milliseconds to 1 microsecond, where some benefit "only" 5 times. That's on a system that serves 1 thousand concurrent users. Now, if someone wants to tell me that 1 microsecond is slow (or 5 milliseconds) - I'll take that as bullshit.
PHP is not the only thing involved in serving a web page. There's also underlying server (Apache) which has its own issues, there's MySQL which runs queries - and who says all queries are optimal? There's the network, there's the hard disk, there's the CPU, there are tons of other processes. Configure Apache with PHP-FPM, optimize MySQL to perform good on 8 core machine with 16 gigs of ram, use APC, use Memcache - and voila, you're getting an incredibly fast, scalable system capable of serving an incredible amount of traffic.
Languages that PHP is being compared to are often "compiled" into the bytecode and then executed by
You can extend PHP yourself. Assuming a PHP function is slow, NOTHING prevents anyone from creating a .so in C that is able to do the job faster and then hooking everything up trough extension in PHP. Not that I know what would such job be that would require that, but such a thing IS possible.
Sadly, and I say sadly because I respect certain programmers and admire their work (and I'm by no means a PHP fanboy) but it hurts me when I see uneducated, inexperienced and subjective comments about a tool which spreads misinformation.
As for why big websites use PHP - because it's fast. Because they laid proper foundations before starting the projects. Because it's free, extensible and scalable. Because it follows C syntax. Because you can extend it when you need it to be faster. Because it runs on a free operating system. Because it's easy to use.
PHP is improving everyday. It is open source and used all around the world. That said, when you have a problem, it is most probable that you will find your solution or get help faster than any other language.
The very reason of this article, I believe it is simple. If you (or in that matter any other programmer) used to code in C++, Java etc.. they had a lot of possibilities such as OOP coding and PHP was limited in the beginning.
It is a good thing that PHP has many built-in functions / methods / classes so you don't have to spend hours to code some function / class / method which PHP already has.
You don't have to (and you shouldn't) try to memorize all these functions. It is useless to memorize all of them (which one is doing what, how to use it etc). Imagine you are working on some project which took you 4-5 months to finish (yeah big one (: ) You are not going to use all these functions in all the projects and eventually you will forget what they were doing since you don't use them often.
The point is, you should know the syntax of PHP. When you need to do something, check first if PHP already has what you want to do in its library. Check the manual to see how to use it. This way, you will also LEARN (NOT MEMORIEZE) the ones you use often and this information will be hard to forget.
PHP or any other programming language is just like a normal language which we humans use daily to communicate with each other. If you don't use it, you will forget.
PHP 5.3 and above brought many features. Static feature is one of the biggest feature for me. It made my life so much easier that I can't even begin to describe.
Since PHP is that famous and open source web scripting language, Facebook developer team created HipHop.
What HipHop does is, takes the data from PHP and sends it to C++. C++ does all the process and sends back results to PHP for outputting.
The whole idea of HipHop was to make Facebook use less servers & improve the page display times.
Now you tell me if this seems limited and / or slow to you?
i dont think there is anything like 'architectural limitation' for php. developer knowledge limitation might be the reason. read this http://www.quora.com/What-is-Facebooks-architecture . most of the time, non-world-class developer does not know how they could use php to its full capabilities.
I would assume he is referring to the fact the the OOP portions of PHP are not the greatest compared to languages that are purely object oriented.
Architecture Limitations in Addition to nikic's answer
Writing extensions for PHP is a PITA. Not as bad as with Perl or Java, but not as easy as it could be. The ease of extensibility champion is still TCL which hails from the early 90's. Nearly any C function taking char* can be made into a TCL extension.
Embedding PHP in other systems. mod_php, gtk.php.net shows it can be done, but Guile and TCL are much easier to embed.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
A few years ago I started working on a few ideas about a programming language and as I was so excited about them I just wanted to see how they would works, so I decide to write a very simple compiler for that. As I'm more comfortable and more experienced in PHP, I just took a look at to see if it's possible to write a compiler in PHP and very soon after that I found that yes, it's possible. So I start making that and fortunately everything was okay and now it's working fine.
Those days I just wanted a place to start working on my ideas, and as PHP was fast in development (no need to compile), I had MySQL on my hands also, and debugging was really easy, etc.
Now I want to extend this simple compiler, and that's where I need your advise. My main question is "Is PHP a right tool for a compiler project?". Just suppose that I'm not gonna release it publicly, so just think about the PHP abilities to handle the task, not further problems like distribution.
I believe that it has some advantages. It's fast in development, I just edit the code and press the F5 on browser and I had my binary output right after that. I also made a text box there where I could write my simple codes, press the submit and then I had my binary output again. It was also fast to keeping and working on the parsed data in MySQL. But now I'm more worried about the script timeout for example. If it's gonna compile 10,000 lines of source code, it would timeout I guess. I know I can increase the timeout, but still worried about that. Also I know that PHP as a scripting language is (as I heard) 10 times slower rather a compiled-application.
So, do you think I have to switch-off to the C? (which I'm also okay with that also) ... or do you have any ideas if I could continue with my PHP back-end, but to handle more serious things and without facing critical mistakes?
Update:
Yes! the project is personal and for fun. You may consider that also!
Regarding application for a PHP-based compiler, yes, it's not a real-world compiler, but imagine if you want to share your ideas with others, it would be great if you gave them a web form to write their code, press the button and download the binary code. It's not my goal, however, I just wondering about that.
Regarding Lex/Yacc, my ideas was more about optimizing the final binary code, so I needed something more than just generating a binary code via Lex/Yacc.
PHP is not the ideal environment for writing compilers. Is it doable? Sure. Should you do it? I am vehemently opposed to writing a compiler in a high-level language like PHP. I'm also opposed to unnecessarily reinventing the wheel.
If it's for fun, I say go for it, but I don't see any practical uses for a PHP-driven compiler at this time.
It is possible to write a compiler in any language (even some non-Turing-complete languages can be used). But in order to make life easier you'll need certain language features which are missing from PHP, and since it is a pretty low-level language, it is not quite possible to add such features to the language.
A decent language for implementing compilers must contain:
Some form of algebraic data types, it is relevant even for a fully dynamic languages (like Lisp)
Pattern matching, the more powerful and expressive - the better. Writing AST transformations without pattern matching is a pain.
This is a bare minimum. Having some decent native support for graphs is an advantage. Having an embedded support for parsing is quite useful (but parsing is not that important in general). Having an access to Prolog or Datalog in runtime is extremely useful (but it should be easy to implement your own Prolog in PHP).
Webjawns say: but I don't see any practical uses for a PHP-driven compiler at this time.
So????
Smarty - is a compiller!!!
If your compiller is just for fun, or specific, php-related use - it is good idea took the php as environment.
But if your compiller has a performance requirements or memory restrictions - it is very bad idea to use PHP for it.
There's a computer programmers gag that sounds something like:
Rookie: Why is C considered to "run faster"/"use less memory"/"insert other optimization comparison here" than Java?
Mentor: Because the Java compiler is written in C while the C compiler is written in C (with traces of assembly for optimization).
Almost all compilers are written in C. The same thing goes for operating systems which are also almost all written in C. Almost all of the main prepacked libraries that any high level language uses are written in C. Almost all high-load servers (Apache & MySQL included) are written in C. Basically almost every mission critical piece of software is written in C.
With that in mind id's say:
I'd write a Tokenizer -> Parser -> Transcoder chain in PHP for fun - maybe even one with database storage what the heck; but i would be outputting text (source code for another language).
I wouldn't write a Compiler in PHP because i wouldn't want to be outputting binary files from PHP - not because it can't but because I don't like using strings for binary arithmetics.
The Compiler I'd write in C.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
The community reviewed whether to reopen this question 11 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am setting out to do a side project that has the goal of translating code from one programming language to another. The languages I am starting with are PHP and Python (Python to PHP should be easier to start with), but ideally I would be able to add other languages with (relative) ease. The plan is:
This is geared towards web development. The original and target code will be be sitting on top of frameworks (which I will also have to write). These frameworks will embrace an MVC design pattern and follow strict coding conventions. This should make translation somewhat easier.
I am also looking at IOC and dependency injection, as they might make the translation process easier and less error prone.
I'll make use of Python's parser module, which lets me fiddle with the Abstract Syntax Tree. Apparently the closest I can get with PHP is token_get_all(), which is a start.
From then on I can build the AST, symbol tables and control flow.
Then I believe I can start outputting code. I don't need a perfect translation. I'll still have to review the generated code and fix problems. Ideally the translator should flag problematic translations.
Before you ask "What the hell is the point of this?" The answer is... It'll be an interesting learning experience. If you have any insights on how to make this less daunting, please let me know.
EDIT:
I am more interested in knowing what kinds of patterns I could enforce on the code to make it easier to translate (ie: IoC, SOA ?) the code than how to do the translation.
I've been building tools (DMS Software Reengineering Toolkit) to do general purpose program manipulation (with language translation being a special case) since 1995, supported by a strong team of computer scientists. DMS provides generic parsing, AST building, symbol tables, control and data flow analysis, application of translation rules, regeneration of source text with comments, etc., all parameterized by explicit definitions of computer languages.
The amount of machinery you need to do this well is vast (especially if you want to be able to do this for multiple languages in a general way), and then you need reliable parsers for languages with unreliable definitions (PHP is perfect example of this).
There's nothing wrong with you thinking about building a language-to-language translator or attempting it, but I think you'll find this a much bigger task for real languages than you expect. We have some 100 man-years invested in just DMS, and another 6-12 months in each "reliable" language definition (including the one we painfully built for PHP), much more for nasty languages such as C++. It will be a "hell of a learning experience"; it has been for us. (You might find the technical Papers section at the above website interesting to jump start that learning).
People often attempt to build some kind of generalized machinery by starting with some piece of technology with which they are familiar, that does a part of the job. (Python ASTs are great example). The good news, is that part of the job is done. The bad news is that machinery has a zillion assumptions built into it, most of which you won't discover until you try to wrestle it into doing something else. At that point you find out the machinery is wired to do what it originally does, and will really, really resist your attempt to make it do something else. (I suspect trying to get the Python AST to model PHP is going to be a lot of fun).
The reason I started to build DMS originally was to build foundations that had very few such assumptions built in. It has some that give us headaches. So far, no black holes. (The hardest part of my job over the last 15 years is to try to prevent such assumptions from creeping in).
Lots of folks also make the mistake of assuming that if they can parse (and perhaps get an AST), they are well on the way to doing something complicated. One of the hard lessons is that you need symbol tables and flow analysis to do good program analysis or transformation. ASTs are necessary but not sufficient. This is the reason that Aho&Ullman's compiler book doesn't stop at chapter 2. (The OP has this right in that he is planning to build additional machinery beyond the AST). For more on this topic, see Life After Parsing.
The remark about "I don't need a perfect translation" is troublesome. What weak translators do is convert the "easy" 80% of the code, leaving the hard 20% to do by hand. If the application you intend to convert are pretty small, and you only intend to convert it once well, then that 20% is OK. If you want to convert many applications (or even the same one with minor changes over time), this is not nice. If you attempt to convert 100K SLOC then 20% is 20,000 original lines of code that are hard to translate, understand and modify in the context of another 80,000 lines of translated program you already don't understand. That takes a huge amount of effort. At the million line level, this is simply impossible in practice. (Amazingly there are people that distrust automated tools and insist on translating million line systems by hand; that's even harder and they normally find out painfully with long time delays, high costs and often outright failure.)
What you have to shoot for to translate large-scale systems is high nineties percentage conversion rates, or it is likely that you can't complete the manual part of the translation activity.
Another key consideration is size of code to be translated. It takes a lot of energy to build a working, robust translator, even with good tools. While it seems sexy and cool to build a translator instead of simply doing a manual conversion, for small code bases (e.g., up to about 100K SLOC in our experience) the economics simply don't justify it. Nobody likes this answer, but if you really have to translate just 10K SLOC of code, you are probably better off just biting the bullet and doing it. And yes, that's painful.
I consider our tools to be extremely good (but then, I'm pretty biased). And it is still very hard to build a good translator; it takes us about 1.5-2 man-years and we know how to use our tools. The difference is that with this much machinery, we succeed considerably more often than we fail.
My answer will address the specific task of parsing Python in order to translate it to another language, and not the higher-level aspects which Ira addressed well in his answer.
In short: do not use the parser module, there's an easier way.
The ast module, available since Python 2.6 is much more suitable for your needs, since it gives you a ready-made AST to work with. I've written an article on this last year, but in short, use the parse method of ast to parse Python source code into an AST. The parser module will give you a parse tree, not an AST. Be wary of the difference.
Now, since Python's ASTs are quite detailed, given an AST the front-end job isn't terribly hard. I suppose you can have a simple prototype for some parts of the functionality ready quite quickly. However, getting to a complete solution will take more time, mainly because the semantics of the languages are different. A simple subset of the language (functions, basic types and so on) can be readily translated, but once you get into the more complex layers, you'll need heavy machinery to emulate one language's core in another. For example consider Python's generators and list comprehensions which don't exist in PHP (to my best knowledge, which is admittedly poor when PHP is involved).
To give you one final tip, consider the 2to3 tool created by the Python devs to translate Python 2 code to Python 3 code. Front-end-wise, it has most of the elements you need to translate Python to something. However, since the cores of Python 2 and 3 are similar, no emulation machinery is required there.
Writing a translator isn't impossible, especially considering that Joel's Intern did it over a summer.
If you want to do one language, it's easy. If you want to do more, it's a little more difficult, but not too much. The hardest part is that, while any turing complete language can do what another turing complete language does, built-in data types can change what a language does phenomenally.
For instance:
word = 'This is not a word'
print word[::-2]
takes a lot of C++ code to duplicate (ok, well you can do it fairly short with some looping constructs, but still).
That's a bit of an aside, I guess.
Have you ever written a tokenizer/parser based on a language grammar? You'll probably want to learn how to do that if you haven't, because that's the main part of this project. What I would do is come up with a basic Turing complete syntax - something fairly similar to Python bytecode. Then you create a lexer/parser that takes a language grammar (perhaps using BNF), and based on the grammar, compiles the language into your intermediate language. Then what you'll want to do is do the reverse - create a parser from your language into target languages based on the grammar.
The most obvious problem I see is that at first you'll probably create horribly inefficient code, especially in more powerful* languages like Python.
But if you do it this way then you'll probably be able to figure out ways to optimize the output as you go along. To summarize:
read provided grammar
compile program into intermediate (but also Turing complete) syntax
compile intermediate program into final language (based on provided grammar)
...?
Profit!(?)
*by powerful I mean that this takes 4 lines:
myinput = raw_input("Enter something: ")
print myinput.replace('a', 'A')
print sum(ord(c) for c in myinput)
print myinput[::-1]
Show me another language that can do something like that in 4 lines, and I'll show you a language that's as powerful as Python.
There are a couple answers telling you not to bother. Well, how helpful is that? You want to learn? You can learn. This is compilation. It just so happens that your target language isn't machine code, but another high-level language. This is done all the time.
There's a relatively easy way to get started. First, go get http://sourceforge.net/projects/lime-php/ (if you want to work in PHP) or some such and go through the example code. Next, you can write a lexical analyzer using a sequence of regular expressions and feed tokens to the parser you generate. Your semantic actions can either output code directly in another language or build up some data structure (think objects, man) that you can massage and traverse to generate output code.
You're lucky with PHP and Python because in many respects they are the same language as each other, but with different syntax. The hard part is getting over the semantic differences between the grammar forms and data structures. For example, Python has lists and dictionaries, while PHP only has assoc arrays.
The "learner" approach is to build something that works OK for a restricted subset of the language (such as only print statements, simple math, and variable assignment), and then progressively remove limitations. That's basically what the "big" guys in the field all did.
Oh, and since you don't have static types in Python, it might be best to write and rely on PHP functions like "python_add" which adds numbers, strings, or objects according to the way Python does it.
Obviously, this can get much bigger if you let it.
I will second #EliBendersky point of view regarding using ast.parse instead of parser (which I did not know about before). I also warmly recommend you to review his blog. I used ast.parse to do Python->JavaScript translator (#https://bitbucket.org/amirouche/pythonium). I've come up with Pythonium design by somewhat reviewing other implementations and trying them on my own. I forked Pythonium from https://github.com/PythonJS/PythonJS which I also started, It's actually a complete rewrite . The overall design is inspired from PyPy and http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-89-1.pdf paper.
Everything I tried, from beginning to the best solution, even if it looks like Pythonium marketing it really isn't (don't hesitate to tell me if something doesn't seem correct to the netiquette):
Implement Python semantic in Plain Old JavaScript using prototype inheritance: AFAIK it's impossible to implement Python multiple inheritance using JS prototype object system. I did try to do it using other tricks later (cf. getattribute). As far as I know there is no implementation of Python multiple inheritance in JavaScript, the best that exists is Single inhertance + mixins and I'm not sure they handle diamond inheritance. Kind of similar to Skulpt but without google clojure.
I tried with Google clojure, just like Skulpt (compiler) instead of actually reading Skulpt code #fail. Anyway because of JS prototype based object system still impossible. Creating binding was very very difficult, you need to write JavaScript and a lot of boilerplate code (cf. https://github.com/skulpt/skulpt/issues/50 where I am the ghost). At that time there was no clear way to integrate the binding in the build system. I think that Skulpt is a library and you just have to include your .py files in the html to be executed, no compilation phase required to be done by the developer.
Tried pyjaco (compiler) but creating bindings (calling Javascript code from Python code) was very difficult, there was too much boilerplate code to create every time. Now I think pyjaco is the one that more near Pythonium. pyjaco is written in Python (ast.parse too) but a lot is written in JavaScript and it use prototype inheritance.
I never actually succeed at running Pyjamas #fail and never tried to read the code #fail again. But in my mind PyJamas was doing API->API tranlation (or framework to framework) and not Python to JavaScript translation. The JavaScript framework consume data that is already in the page or data from the server. Python code is only "plumbing". After that I discovered that pyjamas was actually a real python->js translator.
Still I think it's possible to do API->API (or framework->framework) translation and that's basicly what I do in Pythonium but at lower level. Probably Pyjamas use the same algorithm as Pythonium...
Then I discovered brython fully written in Javascript like Skulpt, no need for compilation and lot of fluff... but written in JavaScript.
Since the initial line written in the course of this project, I knew about PyPy, even the JavaScript backend for PyPy. Yep, you can, if you find it, directly generate a Python interpreter in JavaScript from PyPy. People say, it was a disaster. I read no where why. But I think the reason is that the intermediate language they use to implement the interpreter, RPython, is a subset of Python tailored to be translated to C (and maybe asm). Ira Baxter says you always make assumptions when you build something and probably you fine tune it to be the best at what it's meant to do in the case of PyPy: Python->C translation. Those assumptions might not be relevant in another context worse they can infere overhead otherwise said direct translation will most likely always be better.
Having the interpreter written in Python sounded like a (very) good idea. But I was more interested in a compiler for performance reasons also it's actually more easy to compile Python to JavaScript than interpret it.
I started PythonJS with the idea of putting together a subset of Python that I could easily translate to JavaScript. At first I didn't even bother to implement OO system because of past experience. The subset of Python that I achieved to translate to JavaScript are:
function with full parameters semantic both in definition and calling. This is the part I am most proud of.
while/if/elif/else
Python types were converted to JavaScript types (there is no python types of any kind)
for could iterate over Javascript arrays only (for a in array)
Transparent access to JavaScript: if you write Array in the Python code it will be translated to Array in javascript. This is the biggest achievement in terms of usability over its competitors.
You can pass function defined in Python source to javascript functions. Default arguments will be taken into account.
It add has special function called new which is translated to JavaScript new e.g: new(Python)(1, 2, spam, "egg") is translated to "new Python(1, 2, spam, "egg").
"var" are automatically handled by the translator. (very nice finding from Brett (PythonJS contributor).
global keyword
closures
lambdas
list comprehensions
imports are supported via requirejs
single class inheritance + mixin via classyjs
This seems like a lot but actually very narrow compared to full blown semantic of Python. It's really JavaScript with a Python syntax.
The generated JS is perfect ie. there is no overhead, it can not be improved in terms of performance by further editing it. If you can improve the generated code, you can do it from the Python source file too. Also, the compiler did not rely on any JS tricks that you can find in .js written by http://superherojs.com/, so it's very readable.
The direct descendant of this part of PythonJS is the Pythonium Veloce mode. The full implementation can be found # https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/veloce/veloce.py?at=master 793 SLOC + around 100 SLOC of shared code with the other translator.
An adapted version of pystones.py can be translated in Veloce mode cf. https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pystone/?at=master
After having setup basic Python->JavaScript translation I choosed another path to translate full Python to JavaScript. The way of glib doing object oriented class based code except the target language is JS so you have access to arrays, map-like objects and many other tricks and all that part was written in Python. IIRC there is no javascript code written by in Pythonium translator. Getting single inheritance is not difficult here are the difficult parts making Pythonium fully compliant with Python:
spam.egg in Python is always translated to getattribute(spam, "egg") I did not profile this in particular but I think that where it loose a lot of time and I'm not sure I can improve upon it with asm.js or anything else.
method resolution order: even with the algorithm written in Python, translating it to Python Veloce compatible code was a big endeavour.
getattributre: the actual getattribute resolution algorithm is kind of tricky and it still doesn't support data descriptors
metaclass class based: I know where to plug the code, but still...
last bu not least: some_callable(...) is always transalted to "call(some_callable)". AFAIK the translator doesn't use inference at all, so every time you do a call you need to check which kind of object it is to call it they way it's meant to be called.
This part is factored in https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/compliant/runtime.py?at=master It's written in Python compatible with Python Veloce.
The actual compliant translator https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/compliant/compliant.py?at=master doesn't generate JavaScript code directly and most importantly doesn't do ast->ast transformation. I tried the ast->ast thing and ast even if nicer than cst is not nice to work with even with ast.NodeTransformer and more importantly I don't need to do ast->ast.
Doing python ast to python ast in my case at least would maybe be a performance improvement since I sometime inspect the content of a block before generating the code associated with it, for instance:
var/global: to be able to var something I must know what I need to and not to var. Instead of generating a block tracking which variable are created in a given block and inserting it on top of the generated function block I just look for revelant variable assignation when I enter the block before actually visiting the child node to generate the associated code.
yield, generators have, as of yet, a special syntax in JS, so I need to know which Python function is a generator when I want to write the "var my_generator = function"
So I don't really visit each node once for each phase of the translation.
The overall process can be described as:
Python source code -> Python ast -> Python source code compatible with Veloce mode -> Python ast -> JavaScript source code
Python builtins are written in Python code (!), IIRC there is a few restrictions related to bootstraping types, but you have access to everything that can translate Pythonium in compliant mode. Have a look at https://bitbucket.org/amirouche/pythonium/src/33898da731ee2d768ced392f1c369afd746c25d7/pythonium/compliant/builtins/?at=master
Reading JS code generated from pythonium compliant can be understood but source maps will greatly help.
The valuable advice I can give you in the light of this experience are kind old farts:
extensively review the subject both in literature and existing projects closed source or free. When I reviewed the different existing projects I should have given it way more time and motivation.
ask questions! If I knew beforehand that PyPy backend was useless because of the overhead due to C/Javascript semantic mismatch. I would maybe had Pythonium idea way before 6 month ago maybe 3 years ago.
know what you want to do, have a target. For this project I had different objectives: pratice a bit a javascript, learn more of Python and be able to write Python code that would run in the browser (more and that below).
failure is experience
a small step is a step
start small
dream big
do demos
iterate
With Python Veloce mode only, I'm very happy! But along the way I discovered that what I was really looking for was liberating me and others from Javascript but more importantly being able to create in a comfortable way. This lead me to Scheme, DSL, Models and eventually domain specific models (cf. http://dsmforum.org/).
About what Ira Baxter response:
The estimations are not helpful at all. I took me more or less 6 month of free time for both PythonJS and Pythonium. So I can expect more from full time 6 month. I think we all know what 100 man-year in an enterprise context can mean and not mean at all...
When someone says something is hard or more often impossible, I answer that "it only takes time to find a solution for a problem that is impossible" otherwise said nothing is impossible except if it's proven impossible in this case a math proof...
If it's not proven impossible then it leaves room for imagination:
finding a proof proving it's impossible
and
If it is impossible there may be an "inferior" problem that can have a solution.
or
if it's not impossible, finding a solution
It's not just optimistic thinking. When I started Python->Javascript everybody was saying it was impossible. PyPy impossible. Metaclasses too hard. etc... I think that the only revolution that brings PyPy over Scheme->C paper (which is 25 years old) is some automatic JIT generation (based hints written in the RPython interpreter I think).
Most people that say that a thing is "hard" or "impossible" don't provide the reasons. C++ is hard to parse? I know that, still they are (free) C++ parser. Evil is in the detail? I know that. Saying it's impossible alone is not helpful, It's even worse than "not helpful" it's discouraging, and some people mean to discourage others. I heard about this question via https://stackoverflow.com/questions/22621164/how-to-automatically-generate-a-parser-code-to-code-translator-from-a-corpus.
What would be perfection for you? That's how you define next goal and maybe reach the overall goal.
I am more interested in knowing what kinds of patterns I could enforce
on the code to make it easier to translate (ie: IoC, SOA ?) the code
than how to do the translation.
I see no patterns that can not be translated from one language to another language at least in a less than perfect way. Since language to language translation is possible, you'd better aim for this first. Since, I think according to http://en.wikipedia.org/wiki/Graph_isomorphism_problem, translation between two computer languages is a tree or DAG isomorphism. Even if we already know that they are both turing complete, so...
Framework->Framework which I better visualize as API->API translation might still be something that you might keep in mind as a way to improve the generated code. E.g: Prolog as very specific syntax but still you can do Prolog like computation by describing the same graph in Python... If I was to implement a Prolog to Python translator I wouldn't implement unification in Python but in a C library and come up with a "Python syntax" that is very readable for a Pythonist. In the end, syntax is only "painting" for which we give a meaning (that's why I started scheme). Evil is in the detail of the language and I'm not talking about the syntax. The concepts that are used in the language getattribute hook (you can live without it) but required VM features like tail-recursion optimisation can be difficult to deal with. You don't care if the initial program doesn't use tail recursion and even if there is no tail recursion in the target language you can emulate it using greenlets/event loop.
For target and source languages, look for:
Big and specific ideas
Tiny and common shared ideas
From this will emerge:
Things that are easy to translate
Things that are difficult to translate
You will also probably be able to know what will be translated to fast and slow code.
There is also the question of the stdlib or any library but there is no clear answer, it depends of your goals.
Idiomatic code or readable generated code have also solutions...
Targeting a platform like PHP is much more easy than targeting browsers since you can provide C-implementation of slow and/or critical path.
Given you first project is translating Python to PHP, at least for the PHP3 subset I know of, customising veloce.py is your best bet. If you can implement veloce.py for PHP then probably you will be able to run the compliant mode... Also if you can translate PHP to the subset of PHP you can generate with php_veloce.py it means that you can translate PHP to the subset of Python that veloce.py can consume which would mean that you can translate PHP to Javascript. Just saying...
You can also have a look at those libraries:
https://bitbucket.org/logilab/astroid
https://bitbucket.org/logilab/pylint-brain
Also you might be interested by this blog post (and comments): https://www.rfk.id.au/blog/entry/pypy-js-poc-jit/
This Google Tech Talk from Ira Baxter is interesting https://www.youtube.com/watch?v=C-_dw9iEzhA
You could take a look at the Vala compiler, which translates Vala (a C#-like language) into C.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
Recently a teacher said "PHP isn't a real programming language", but only gave, in my opinion, weak justification:
It's not compiled.
It's scripted.
It doesn't run on every platform.
Is PHP not considered a "real" programming language? What is a "real" programming language? Must a language be compiled to be taken seriously?
Background
I did an induction lesson into my A-Level Computing Class in school two days ago – we're using Java for the first year of the course. I'm unfamiliar with Java but have a pretty good grasp on general programming fundamentals (variables, functions, object-orientation, loops, etc.).
Our first task the teacher ran through ridiculously fast. She didn't bother to explain any of the concepts, how they work, or what you would realistically use them for, and seemed to take great pleasure in watching most of the students (who were, on the whole, new to programming) squirm in their seats at not having the vaguest idea what she was on about. In hindsight, I reckon she went through it incredibly quickly to see who could really "handle" taking Computing A-Level, since students still have a chance to change their subjects before September begins.
The first and only task was to write a Java command-line application to convert binary to denary (decimal). We had a two-hour taster session to do this, and after explanation how the binary system works we had to begin, despite, on the whole, nobody really having the foggiest idea where to begin. After an hour some were further than others, but nobody had really achieved anything significant. The teacher herself became so confused she called in another teacher from next door. He came round to help people and see where to go next.
Without bragging, I probably did have the most experience in the class and had gotten the furthest in the exercise. He asked me if I'd had any previous experience; I said yes, particularly in PHP, and jokingly commented that I could write something to convert binary to denary in just a few lines of PHP, whilst the Java application was rapidly growing into several screens of code.
He replied, "PHP isn't a real programming language!"...! After some discussion, he gave the three reasons above. However, I pointed out you can run PHP on any platform that runs Apache, but I don't think he really knows what Apache is and was having none of that!
First we need to know what a programming language is. At its minimum, a programming language is something that is read by the computer and instructs it to perform certain operations. Many people would also expect a general purpose programming language to be Turing complete. However there could be situations where a domain-specific language isn't Turing complete but is still a useful programming language for that specific domain. Programming languages can be compiled or interpreted, and they could run on many platforms or just one specific one. Different needs require different programming languages. Clearly PHP is a programming language.
My definition of "real" programming language would be any programming language that has at least one practical usage in the real world. This is opposed to an esoteric programming language which typically has no practical usage. Since PHP is used widely to solve real problems it easily meets this requirement for being a real programming language, although it is arguably not a particularly beautiful language.
PHP is a pragmatic language. It was created out of a specific need to be able to quickly make web pages (the name originally stood for Personal Home Pages) and the language was extended as required. Since there was no theoretical background or strong design principles driving its creation (there isn't even a formal specification of the language) it is less clean than many other more modern languages. Features like correct handling of foreign characters / unicode characters are obviously added on afterwards and not cleanly integrated with the rest of the language. This untidiness and lack of theoretical rigour causes many people (especially academics) to dislike the language and this may be part of the reason why your teacher doesn't regard PHP as "real" language.
However PHP is good at what it was designed for and many sites use it, even very large sites like Facebook, Yahoo! and Wikipedia.
It's not compiled
PHP can be compiled (e.g. through HHVM).
It's scripted
That's just another way of saying that PHP is not compiled.
It doesn't run on every platform
Neither does Java.
Sounds like you have a really bad teacher there.
Of course PHP is a programming language. He probably meant it isn't a "real" programming language in the same sense that "real" men don't eat quiche.
define:programming language
It seems, according to this, that PHP is a programming language. Whether it's a real programming language is entirely subjective. Whether it's a good language is also subjective. Certainly, it is most commonly not used as an application programming language, but it can be used to develop shell applications via CLI. I have never done this, so my understanding of it is sketchy, but it's possible.
Now, is PHP "scripted" (I take this to mean a scripting language), and does it run on every platform? You judge:
PHP: Hypertext Preprocessor is a widely used, general-purpose scripting language that was originally designed for web development to produce dynamic web pages. For this purpose, PHP code is embedded into the HTML source document and interpreted by a web server with a PHP processor module, which generates the web page document. As a general-purpose programming language, PHP code is processed by an interpreter application in command-line mode performing desired operating system operations and producing program output on its standard output channel. It may also function as a graphical application. PHP is available as a processor for most modern web servers and as standalone interpreter on most operating systems and computing platforms.
Source: http://en.wikipedia.org/wiki/PHP
Does Java even run on every platform? No. Only those for which there exists a JVM.
Finally, does a language need to be compiled? Many aren't. Even Java isn't compiled in the same way C or C++ is. And then you'd also need to take a look at Perl, Python, etc.
Personally, I think PHP is a real programming language. I started there and easily moved on to C/C++ and Java. I wouldn't use it for the same purpose as Java, and its design is different from Java, but that doesn't mean much. It was easier to learn than Java for me.
First of all, not being compiled and being interpreted (what he surely meant by scripted, which is somewhat vague and used for different purposes anyway) are different sides of the same coin, and thus really the same reason.
The last reason, that it doesn't run on every platform, is just confusing. It sounds like he's trying to tout Java's portability and PHP simply isn't Java. However, Java runs on one very specific platform: the JVM. That platform in turn runs on many other platforms, and thus gives Java its portability, but it's not quite the same as the traditional use of "portable". For example, C is portable and runs on everything from a PDP-11 to the latest embedded devices.
However, C does that by specifying rules of its own abstract platform, and compilers transform C code into assembly according to those rules. This is how Java's portability is similar to C's: they both define rules which are translated into instructions for a specific, concrete machine (processor); the difference is when that occurs.
All problems in computer science can be solved with another level of indirection.
— David Wheeler
In reality, even assembly or "machine code" is interpreted by the processor into its native actions. (I don't have a good source at hand for this, but I recall that it's lightly covered by A Crash Course in Modern Hardware, which is a good presentation anyway.) As processor speeds get faster, we hardly notice on our underused boxes whether a given program is in asm or run through an interpreter, but this is where the definition of "real programming language" comes into play.
The only sensible way to define a "real programming language" is as "a language to get real work done", but that really punts on the definition of "real", too. (It does, however, establish a distinction with esoteric programming languages, because nobody does real work, for example, in Malbolge, for any definition of "real" you could get ten people to agree upon.) And, compared to today, your choices of a programming language were much more limited by their implementation strategy and overhead (e.g. a runtime interpreter) in the past. However, even today, some languages are more "real" than others for certain applications and expected loads, it all depends on your requirements.
It sounds like your teacher has only experienced PHP through toy web applications (and maybe using 'application' is a stretch for what he's seen). Toy programs aren't real work. PHP definitely has a lot of problems, but I could not say it isn't a real programming language, except in jest.
Debugging is anticipated with distaste, performed with reluctance, and bragged about forever.
— Dan Kaminsky
There is a certain association of "real" with "hard to do" (related to "real work") and your teacher may have been expressing this sentiment. This has always appeared to me as a form of bikeshedding (there's a better term for this exactly, but I can't remember it), where one's estimation of the value of a thing is related to the effort one had to put into it (e.g. a bikeshed is more important when I provided input on the color of the roof and whether it should have a sign). We intrinsically value our own effort more than that of others – just because we're familiar with it, if for no other reason – even when it doesn't make sense to do so. PHP, despite its faults, does make some things easy, and it and programs written in it can consequently be perceived as worth less.
Facebook, Digg, Wikipedia, Yahoo. I guess those aren't real websites.
Back when I was learning PHP, I too didn't believe PHP to be a programming language.
I'm not sure where I picked the idea up, but I learned somewhere that a scripting language is not a programming language. So I applied this thinking to other languages, such as JavaScript and SQL.
Since then I have changed my mind and understand now that there is a spectrum of languages that goes from high level (e.g. PHP, Javascript) to low level (e.g. c, assembler) with things like C# and Java somewhere in between.
You are right. These reasons are too weak. Actually you don't even need Apache to run PHP.
And first two reasons are just repeat themselves as it's only one reason actually. So, one can say 'PHP is not compiled language' but that doesn't mean it's 'not real programming language'. Java programs doesn't compile into machine codes too - well, it's not a real language as well. q.e.d.
Sorry for the OT, but there are so, so many things wrong with this picture! I just hope that you will bail out of that class, that department, and that school just as quickly as you can. I promise that you'll have nothing near to a semester's worth of knowledge when February comes. And, if you're like me, you'll spend your classroom hours in frustration, resentment, and rage at the time your teacher is wasting for you.
That woman is no teacher! Decimal to binary as an intro to coding? Gruesome!
Is it the University (ha!) of Phoenix?
UPDATE: read carefully before you vote, this is not my approach to PHP/Java, I'm trying to see how his teacher sees the PHP/Java thing. Thanks.
What I think your teacher thought: PHP is a language which is locked inside a webserver, mostly used to generate web pages.
Java, on the other hand, is a general-purpose language used for web pages too but used in other industries like microwaves & cars, you can write desktop application in Java etc.
With this in mind it's understandable why your teached said "PHP isn't a real programming language!"
I'm not biased, I don't like both, Java & PHP :) ...but have to use them both
There is no such thing as a real programming language, real man, or real world. You are a programmer if you can program in PHP.
Certainly, PHP is a programming language. It is even Turing-complete language, which basically means that its "power" is equal to "power" of other programming languages. It is "real" both in strict (it really exists) and metaphorical sense (there are people making their living using PHP). So it seems that your teacher is somehow biased.
However, I see some point in your teacher attitude. PHP and Java come from radically different backgrounds. Despite being useful, PHP is very chaotic. Compare standard class library in Java with standard library of PHP functions - the latter looks just like huge set of unrelated tools. Moreover, there are a lot of PHP tutorials on the Web that are of, politely speaking, mediocre quality. Because you are learning how to program, it's best to learn using good tools, and Java is much better tool to learn programming than PHP.
PS. Google for "PHP sucks" to get tons of information why PHP isn't the best tool in the world.
"So, in the 'definition of a programming language', what makes PHP not a 'proper' one?"
The real reason is the fact that most people do not use it as a general purpose application programming language.
It is because there have been always languages which are better suited (with one exception: what PHP was created for, web programming). PHP is "yet another language not even with better design features over existing ones". Some examples of issues when comparing to different other languages include: lack of stable and portable GUI toolkits (at least on Windows/MacOS), lack of threading, lack of speed, and so on.
Ultimately, people who are going to write general applications in PHP, are mostly people who only know well PHP as a programming language. Because there is no reason to write a new application from scratch in PHP: you'll find that most experimented or talented programmers would never consider doing this.
Its just one of those stupid things people repeat to make themselves sound smarter and shut you ups, its cargo cult smugness. If you ask him to explain, he'll either pretend it was a joke(tell him "nice try"), or try pathetically to defend his position (tell him "oh i see", and back away slowly)
Just to put an argument in the other direction to everyone else...
I feel slightly uncomfortable thinking of PHP as a programming language because I'm not convinced you end up with a program. You don't leave your PHP app running, rather a PHP page is requested and is loaded and processed in order to generate an output page, with side-effects like DB changes, etc.
None of this means PHP can't technically be described as a programming language but I think it's reasonable to separate it somehow from Java/C++ where a program can be left running with some concept of state. Each PHP file is surely its own 'program' since you can request any PHP page... there's no entrypoint to a PHP web-application except the convention of calling the right pages.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Friends,
I've got some exp in c++ and now kind of starting my way to J2EE (to survive:))). Meanwhile, I've got a plan to venture in to a web portal my own. But with very little experience in web technology, I'd need to start from scratch. I'm little confused on which way to go and I'm here.
PHP, Python or JSP, considering the fact that, anyway I've got to learn J2EE at my work.
Would that be worth to learn PHP or Python to develop a portal which I expect to get 80-100K
hits per day "IF" everything goes well OR jsp would be sufficient?
Many thanks
Before learning either of these, spend some real time and learn HTML and CSS in depth. Also learn Javascript and JQuery (or your favorite client side library). The O'Reilly books on the topic are pretty much all good IMO.
I say that because I think that you'll find that for most modern web sites, a lot of richness is moving to the client side, and away from the server side. Under this model, your code in PHP or JSP is probably going to look pretty similar (ie, fetch data from the database and serve it to your view or into JSON for the client to consume).
Considering you're used to c++, should look at aspx and c# - probably closer to your current experience.
That said, PHP is a doddle, so it shouldn't present any challenges. Bear in mind that if you want to get the most from the language, you absolutely have to learn a little bit about configuring apache, and frameworks (cake, codeigniter, zend etc).
All the server-side technologies you list are "sufficient" for the volume of traffic you expect, if you design the site well from a performance and scaling viewpoint -- and so do many others you haven't mentioned, such as other Java-based approaches, C# ones, and (last but not least) Ruby (probably with Rails, though, like the other languages, it has several frameworks for you to choose from).
As most everybody said, the client-side considerations are sharper -- unless you want to try a "server-side generator of client-side code" like gwt (I'm told the latter works well, but personally I'm always wary of code generators, esp. using a code generator w/o understanding of the "code" it makes for you, which in this case is HTML, CSS, and Javascript with its own framework). Except for GWT and similar approaches (if that's your chosen poison), really learning HTML, CSS and Javascript is really a must -- and then you get to choose among many, many frameworks again (jQuery, Dojo, closure, etc, etc).
For performance issues, you really want to study Steve Souders' site (and books, etc) -- Steve was a server-side guru until measurement showed him the bottleneck was really client-side, and then he turned himself into the client-side performance wizard;-). But to get the most out of the books you'll need understanding of HTTP, HTML, etc, etc, to start with;-).
Hit's per day isn't a really useful metric for estimating performance. You really need to be concerned with the peak load and the acceptable response time.
80-100k hits per day is an average of about 1 hit per second. The hits are not going to be evenly spread out, so for normal traffic you might expect a peak load of 10 hits per second.
If you are going to promote the site with newsletters or commercials, expect to peack at 100's of hits per second.
If you selling $1 air tickets, expect to peak at 1000's of hits per second.
Now the language you choose for the site isn't nearly as important as your choice of database (not necessarily relational) and the way you store the data in the database.
Scaling up frontends is relatively easy, so having really fast efficient HTML generation shouldn't be a primary concern. Pick a platform that is going to be efficient for development time.
I expect this question to be closed as being subjective. But, I'll put in my 2 cents.
JSP would likely dovetail well with J2EE. (I've heard that it can be a bit rigid, but I have no experience to provide any insight on the matter.)
PHP is a good candidate, because it's popular. You can find a lot of info on the web.
Python isn't as popular for webdev, so finding examples won't be as easy.
I also second Dave Markle's opinion. If you want to learn webdev, HTML, CSS and JavaScript will be crucial as well. You may never want to be a front-end developer, but you can't get away from dealing with those technologies at some point.
There are many options.
Since you already know (and is learning about) Java, one option is to use GWT for both server and client. This can help you in that you do not need to learn another language (JS/HTML/Python/PHP etc). If your portal is going to be big, using Java can help you organise the application better - usually JS/HTML based applications are not very suitable for proper organisation, even if you use good JS Libraries like jQuery or YUI. Having a good organisation can help a lot - during updation and modification later.
If your planned venture is a single/two person venture or if it is time bound - where time to market is everything - then I would not suggest the earlier approach - especially if your server side part is expected to be big.
Java is a slow language to write code in. A project which you will take say 6 months to write in Python will take you close to 1 year + in Java. In such a scneario, I would prefer Python - it is a proper language - unlike PHP, and you create code with good organisation there too - albeit a little less organised than using Java.
Please note that if your client side code is much more complex than your server side code, then going with GWT will do you no harm. But if your server side code is very complex compared to the client side, then I would suggest Python.
Another point is to use existing Web Frameworks to ease your work. For Python, Django is an excellent choice. This itself will decrease your work time by 50% or more, while making your code much more secure and scalable.
It really isn't that similar to C++, but I would recommend PHP. You really can't expect a server-side scripting language to be similar to a compiled language like C++. Personally, I find PHP to be an ugly, messy looking language, but once you get into it, it's very rewarding. Other languages have too many drawbacks. ASP.Net is too Microsoft-centric, Python and Ruby on Rails are too obscure, and are also non-curly bracket languages, meaning it will require a lot of adjustment to change to them. Hope this helps.
I'm working with a PHP developer who is, shall we say, unhappy with .NET. His complaints include having to rebuild the web application solution for every test (though I pointed out that this is usually only necessary if a .cs file has been changed, not interface .aspx files), having to include every file in the solution that is required to be deployed, etc.
I've pointed out a number of advantages of the compiled model including RTTI (reflection), source code integrity (source isn't deployed to the server, keeping meddlesome IT people from modifying it on-the-fly), performance differences (though he insists that this isn't valid since PHP is now "compiled"), etc. What are some other advantages of .NET over PHP? This may incite a religious debate - please God, no - but I'm such a fan of .NET that some of these questions which I asked years ago seem so silly that I can't articulate a valid response.
There also seem to be significant differences in the way in which he goes about developing a page. For instance, declaring a class which represents part of a page - say, a particular column in a 3-column layout - rather than breaking up the code in a more logical fashion and relying on the .aspx to handle layout. It strikes me as odd that page layout would, in any way, be tied to class structure beyond that of the code-behind for a aspx page.
Comments?
UPDATE BTW, this is an old question, but I felt it necessary to update with a few points:
Optimization This is a big one. Compilation provides the opportunity to perform some optimizations that aren't practical to perform during the JIT.
The article that o.k.w referred to is so obviously biased and created by someone that hasn't worked a significant time in .NET that it's hardly worth reading, (though I did). It also makes points that are entirely incorrect.
It's damn near impossible to make Mac people realize that Windows has its place. On the other hand, most Windows guys I know think that Macs are great for a lot of things. Most even own one. We don't use them for developing websites or embedded systems for a reason. (And, yes, our business involves both, intimately.)
First loves gone bad... excellent analogy. This will probably come out of my mouth in a meeting sometime soon.
This debate is useless. I may as well try and convince the UK to drive on the correct side of the road. And Australia. And Hong Kong. And... you see where this is going.
Cheers.
I work with both languages daily, and both are great for development. It's hard to get into the "compiled vs. interpreted" debate without getting all flamey and zealous, so I don't think I'll say anything about that. However, here are some of things I prefer about .Net:
Visual Studio vs. Eclipse.
No #includes, and real namespaces. I want to know about my types all the time, and not rely on weird hacky autoloading routines.
API discoverability. PHP has horrible, inconsistent API naming.
Compile time checking and code analysis
Superior debuggers and profilers
This isn't really anything to do with the models they use though, it's just attributes of the tools themselves. I wouldn't suggest trying to change his mind or even arguing with him about it - he'll either see the advantages himself or he won't, but pushing them on him will probably just make it take longer ;)
From what I understand (not having worked much in PHP myself) PHP is both powerful and easy to use, and really shines on smaller, simpler projects, particularly where the business logic consists mostly of moving content between a database and a web page. ASP.NET lends itself better to larger, more business-logic-intensive applications, where the compile-time checks allow you to catch errors sooner. Catching an error at compile time versus run time can make an order of magnitude of difference in how much time it takes to fix.
Where I work, we use PHP to build mockups to show customers and get them to sign off on our ideas, and then we write the actual product in a compiled language like .NET or Java, since that's the code we'll need to maintain for the next decade or more.
The primary issue is that, almost any advantages you can come up with for .Net can be achieved with PHP if a framework exists for it. I believe there are PHP MVC frameworks.
However, I will say this about the compilation model for ASP.Net, it's extremely helpful to know that there are no syntactical errors in all your code behind code. PHP and ASP Classic didn't have this. In a site of 400+ pages it was difficult to know which ones were and weren't functional with a degree of certainty.