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.
Improve this question
This is part observation, part question.
First the observation:
While everyone talks of modular programming, OOP, procedural done right, aspect oriented, design patterns, etc., several popular opensource PHP apps are plain script files with the structure being controlled by includes and requires.
This looked stupid to me till I faced a recent issue with my shared web host - they don't support MySQL stored procedures on shared hosting. I checked out many competing shared hosting packages - same story.
Then I rewrote the code using SQL queries and some static functions in DB-handling class.
That was when I realised that the said PHP projects actually take into account the whole spectrum of web hosting packages and so decide to keep the code as dumb as possible, so as to reach a wider user base.
The other thing is the reach of the script to newbies without a formal Software Engg background: Scripts are easier to hack for newbies.
Those two were the good reasons I saw to explain the phenomenon.
Make no mistake, the guys maintaining these projects are pretty good at software development, so it is not incompetence.
Sometimes they have spare cash too.
Now the question: What other sensible reasons can you think of?
EDIT: I personally feel that it's not about OOP alone, as pointed out by others, good code structure is not dependent on OOP/Procedural style. I've seen and coded a few functions-based PHP projects myself.
The thing that bothers me most is that the folder/filesystem layout is good, the file/folder naming is great, documentation is plenty, standards are followed, but, when you open the file to read the code, there's a hundred if-then-else conditions, version-checking, odd use of output buffering here and there, cookie manipulation code, some constants, includes, and no clear structure in many files.
At least I seem to be lost every time I try reading the code. But if I read code from Java or C# code bases, or even some other sidelined PHP apps - there is proper separation of code inside functions, templating is used for display and so on. Looks organised. Looks easily understandable.
Backward compatibility could be the issue for maintainers, but they would be open to making the next version in a more structured way. But that too does not happen!
Obviously, I'm missing something because those maintainers always work hard, after all.
Provider compatibility is an issue in many areas when building applications with PHP, it's not the reason why OOP is not used in certain projects.
Several Object Oriented Programming characteristics like interfaces, the public/private/protected keywords and more can be only found in PHP 5. Some applications still support PHP 4, mainly for the reason that there are still providers out there who won't upgrade (out of the justified fear that their clients' PHP 4 apps will crash by the dozen). Therefore, there is still a lot of "primitive" PHP 4 OOP code around. But there is no living PHP version that does not support at least basic OOP.
include and require are used to import code snippets into the current script. You will find them in object oriented applications as well.
There are several software products that make almost no use of OOP at all, and that's fine as long as the overall code quality is in order. While it is regarded by many (myself included) as a important method to write better, more reusable software, OOP is no requirement to write good software.
i see 3 main reasons:
compatibility: PHP did not include OOP from start on. to be down-compatible with older PHP environments and to reach a wider audience, you're keeping the status quo.
effort-switch: switching/refactoring a codebase fron non-OOP to OOP is a lot(!!) of work, transformation script in my view aren't a solution, because they tend to generate code for machines and not for humans. this is OK from runtime aspect but horrible for maintenance.
team-culture: i talked to some PHP developers, some just don't want to make the switch, because they say everything is good and working...
One of the biggest barriers to going all OOP with PHP is that everything has to be reloaded, initialized and executed on every page hit. If you designed a PHP system that was truly object oriented, across the board, performance would probably be abysmal. There would just be a lot of files and objects to load and configure to get things going. Everything has to be loaded and ready to go within a second (ideally much less).
Compare that to say a Java based system where it doesn't really matter if it takes 10 minutes to get the system started. Once it's started, everything is loaded and ready to go.
WordPress is probably a good example of how slow things can get when creating a modular system with lots of files. Much less a modular OOP system. Load testing a straight WordPress install will get you about 10-15 pages/sec with a simple "Hello World" page. Compare that to being able to get well over a hundred pages/sec with a straight "Hello World" php script.
You can work around these issues with caching, which WordPress, Symfony and other systems do.
Unless you use an MVC framework with PHP, Such object oriented approach (like ASP .NET has) would take too much time of yours. Actually you will need to design your own framework first.
I cannot say using a true object oriented approach in php is not possible. You can take objects whereever you want and serialize to strore them in session etc...
When it comes to MVC frameworks in PHP, you can see a true object oriented approach.
Check here for Zend Framework example
Zend Framework is not the only one.
But the words "object oriented" are new for PHP. Only PHP5 is considered as having true OOP. So you have to wait 1-2 years more for having good scripts with true object oriented approach.
Related
I'm currently trying to find the best solution/technology to build our ERP.
Our line of work is very specific, no ERP on the market would fit our needs (or 50% of them), so we decided to go for an in-house solution.
We were advised to choose a client/server solution (.net + WPF), but the result of the first delivery is below our expectations.
We are currently thinking about starting over in php (with the same SQL Server Database), and wondering :
Would a php framework (Symfony, Laravel) be a good pick ? We need to have freedom, to ensure maintainability over time
Would a front-end framework (Bootstrap, Foundation, Materialze) be a good idea
Or should we do everything from scratch
Our main concerns are :
Those framework (and the web itself) will evolve, meaning we have a high maintenability risk (although we can prevent our employees to not use our recommanded browser)
Those frameworks are already well organised, meaning it might be difficult to do whatever we want with them
If we use addons (like UI Kits, JQuery scripts), we will multiply compatiblity risks over time
Considering the investment, our solution should have a 10-year lifetime (with maintenance and improvement over time, of course)
While this question is based on advise and not really suitable for this website. I will do my best to answer your questions.
Would a php framework (Symfony, Laravel) be a good pick ? We need to
have freedom, to ensure maintainability over time
It would, Laravel is based on Symfony and has more out-of-the-box solutions. With Symfony you have more freedom.
Would a front-end framework (Bootstrap, Foundation, Materialze) be a good idea Or should we do everything from scratch
You could use any of those font-end frameworks, however they update reguarly, keeping up with trends. Updating a font-end framework means updating every view you have. You could choose not to update however.
If we use addons (like UI Kits, JQuery scripts), we will multiply compatiblity risks over time
jQUERY has been around since 2006 and is not likely to go anywhere anytime soon. It would advise it is safe to use.
I'm currently working in a company that made a from scratch ERP 8 years ago. They had a similar line of work and no ERP fits the needs.
So 8 years later (today), the erp is still used every day, but it's like impossible to maintain. Php (and tech in general) evolves so fast that you can't waste time (and money) evolving it.
Server version
Security failures
...
I recommend to use a "safe" framework with :
long term support
Easy migration system between versions (which means you can evolve your erp easily)
So yes, using a framework is the solution imo. And symfony seems to be the safest. You'll first need to learn how to use it properly but after that you'll be free to do whatever you want with it. Moreover, you can find help everywhere on this framework. It has a strong community which is an important strength.
In the front office, Bootstrap and JQuery are safe too. Bootstrap has a strong community too, and jQuery is not moving on versions.
I'm working on ERP solution and all I can is tell you about how we do it:
PHP framework should be used for your project because it gives you a
good base on what to work on and speeds you up. I'm working in
Laravel and it has all I need.
We are using Bootstrap 3. I'd recommend using some sort of front-end
framework because if your html will be written in easy-to-read manner
then upgrading to newer versions of framework shouldn't be hard.
We use JS + jQuery + vue.js. All I can say is: you shouldn't rely on
JS, php is what your project is based on. JS should be used for
simple stuff that make page feel more dynamic. As JS libraries are
written in JS they will barely lose any functionality over time.
I really should vote to close this - it's both too broad and primarily opinion based.
If you want to develop a web based application using Java, C or C# then a framework is pretty much essential. But with PHP it's a very different story - you are starting with a language specifically designed for the purpose which comes with a rich library of tools from a single vendor. Further if you develop on a Linux platform then the development tools and the platform all come under one provider for patch management. As soon as you start adding in third party components, the problem becomes much more complicated.
For seem reason, Open Source projects seem to thrive and do well when they are making frequent releases. For commercial software regular releases are important for generating revenue streams. When a product is finished in development it seems it is finished in the market. Consider pound vs haproxy.
IME the quality of code you can download from the internet varies greatly. Sadly popularity does not always equate to quality (but price has little relationship either). Frequently programmers are too focussed on delivering functionality to consider security, performance and scalability. Indeed there seems to be a belief that adding more functionality into a framework gives it some advantage over other products (more functionality = more complexity = more bugs = less security + harder to fix).
A problem specific to PHP frameworks is most seek to be all things to all people (more complexity) - providing session abstraction, templating, database abstraction, templating, routing... There are some exceptions of highly focussed tools (e.g. smarty for templating, metabase or AdoDB for database abstraction, jQuery for interacting with the DOM) which focus on doing one thing and doing it well.
Once you start adding third party code into your system, you need to ensure methods for ensuring that code is up to date - but the cost is up front - adding the second, third, fourth... package has a lot less impact than adding the first one (assuming that you do put proper process in place around the management of sourcing and deployment). Using composer helps (but falls a long way short of fixing) the base problem.
Yes, you will be encountering problems that other people have written solutions for. Using a (good) framework or library will probably save costs early on in the project (once you have dealt with the bump of getting your development team up to speed).
Those frameworks are already well organised, meaning it might be difficult to do whatever we want with them
I suggest that if they are well organised it should make it easier for you to do whatever you want with them!
But have a look around SO - frequently people are posting questions asking how do I do xyz with CakePHP / Falcon / CodeIgniter / Laravel. In most cases, what they are asking would be easier to do without the framework rather than via the framework.
I could go on, but this reply is already too long.
There is no answer to your question. If there was it would depend on a lot of other factors like available skills, risk appetite, budget....
If you decide to use a framework (or frameworks) then do consider building the system around micro-services and (if practical) avoid using the frameworks front controller. This will reduce your dependence on the framework if you ever need to re-engineer it out.
I'm deciding on a web framework for an upcoming project, and I'd appreciate any advice. We've decided to use jQuery for the JavaScript, and are heavily leaning toward Python or PHP (more Python) for our server-side logic. I'm especially interested in web2py because of its jQuery integration.
About our project
Our project is to develop a security console for a complex
cybersecurity system operating within an organization's internal
network.
This console will be largely server-driven, as messages come in from the network and must be pushed by the server to the user.
The user will also be able to initiate security actions, the implementation for which will likely be in C++.
The interface we've planned will be relatively rich, and I want to leverage jQuery's power as much as possible.
We have some control over the browser environment we'll be running in (e.g., we don't have to worry about clients with JavaScript disabled).
Our site is likely to have only a few, long-lived client connections.
We are looking for software components with permissive licenses, though we're using some copyleft components (I see that web2py is LGPL while Django is BSD, so +1 to Django)
We have about a month to create a functional demo of our system, of which this interface is a small (but visible) part.
About us
We are two developers with about 5 years of programming experience, but little web development experience. I have several years of Python experience and a summers' worth of experience messing around with PHP. My coworker has some Python experience and has never touched PHP.
I used Django once back in 2008, and was frustrated by the file and code structure, which I found highly unintuitive. Perhaps this structure is inherent to the MVC model (I've had similar experiences with Django and CakePHP since), and I just need to bite the bullet and memorize it.
My Question
Given the information above, what are the relative advantages of the various Python/PHP web frameworks for our project? As mentioned above, I'm especially interested in web2py because of its jQuery integration, though Django's dominance is (once again) hard to ignore.
Thank you very much for your time!
Before deciding on a framework, you should first decide if you want to commit to a language you are unfamiliar with.
You said you've both got minimal PHP experience, so you have to weigh up the advantages here; Will the pros for going PHP (if any) out weigh the amount of time the developers will need to spend to retrain?
(Although depending on your background experience, PHP should be very easy to pick up.)
If you frame it like that, PHP would have to have a pretty convincing offering to give you. From what I'm seeing, specifically Django vs web2py, they both seem very close in functionality - which is good, but doesn't provide the "you must use x!" scenario you may be after.
However, If you will be bringing more people in later and feel finding people to work with web2py will be difficult, it may tip it to PHP. You said your self, Django's popularity (and BSD license) is hard to ignore, and it should make it easier to find people for later expansion.
If it were me, in your shoes, I would go with web2py. Assuming the development team will continue to be Python focused for the foreseeable future.
Python vs PHP: Python
With python, you can always write wrappers for C code so you won't have to mess with starting other processes and passing args to them. That might be useful for your security functions.
Web2py will allow you to easily write a webservice for this too, to more easily integrate the C portions with the web-site infrastructure.
If you already prefer python, I would go with that. If you need to bring on web-developers later that are trained in PHP, teach them Python. It won't take long, and I'm sure they'll appreciate it in the long run. Plus, moving from a PHP MVC framework to web2py or even django would make things easier. I've used CodeIgniter for PHP and find that web2py was so much simpler and easy to understand.
Also as for the directory structure, django is not actually true MVC -- it's MTV (model, template, view).
I find web2py's organization a little more straight-forward. But yes, either way it can seem strange at first. I would say YES, you should bite the bullet and use MVC.
In web2py, the "view" is html markup with the ability to write raw python code. The controller extracts data from the model (database), attaches any needed files (css/js etc) and the model of course simply defines the structure of the data and allows you to access it in an OO way.
Lastly, I wouldn't tip my hat in favor of web2py just because of jQuery integration. It does use it, and a some of the built-in framework stuff (like response.flash/session.flash, the LOAD function that loads a page or data from another controller) rely on jQuery, but using it in another framework only means you have to write an include statement (e.g. ).
But, the way it allows/forces you to focus on development is what takes the cake for me.
I've been using Django as part of my work for a couple years now and truly enjoy it when I can make it work. Unfortunately, and maybe it's just me, but I end up spending hours working on configuration every time I start a new server, or try to make it work in a development IDE.
It's relatively simple to start a new project and start coding. But there are all sorts of little catches that keep things from working if you deviate from the norm. Things like if you want your django project to serve from a subdirectory like example.com/django. The information is out there to make it work. But it's hard to find.
I can't tell you if web2py has those same problems or not. I only just learned about it from your question. It does look slick and simple though. I can tell you that after the hassles of getting the applications to serve properly from whatever server configuration I'm using, django is way more fun to program with than plain php. PHP frameworks may differ.
From my understanding the project not usual web application, you must need event driven program, web server in python.
Django won't help you here.You should look into Flask, Flask has inbuilt console too.http://werkzeug.pocoo.org/, you might need to use twisted, gevent,Flask jquery.
I would recommend asking about web2py on its mailing list -- you'll get lots of help and advice there. Regarding the LGPL license, note that it only applies to the framework, not your application -- you can license your application however you like, including closed source/commercial.
It sounds like you'll need some server push functionality, but if you'll really only need a few long-lived connections at a time, you might not need to bother with solutions like Twisted or gevent. If necessary, though, web2py does include this (requires Tornado, and works using WebSockets, though can be adapted to use other methods).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm planning on moving to Python and I have a couple of additional questions along with the title:
did you have more fun with python?
are you as productive as when you're using PHP?
what made you change to python?
Would you do a project again in PHP? If so, why?
Your answers would really be useful for us PHP devs wanting something more I guess :)
Thanks in advance!
I was a PHP dev for about 5 years before switching to Python almost exclusively a year ago. The experience has been a mostly positive one; I'll answer your questions but also list a few gotchas I ran into.
Definitely. I continually find surprisingly powerful features/expressions in Python that do a great deal in a small amount of code (yet still being more readable than Perl).
Far more productive. It might just be my style, but Python's functional programming tools, generator expressions, list comprehensions, etc. allow me to accomplish tasks correctly with less code and less time invested than PHP.
I had an analytics project that needed a powerful stats package, so I went with Python+numpy. Then I found Turbogears and loved the syntax. Eventually I discovered coroutines and cooperative multitasking, and there's no going back. I use bottle, gevent, and gunicorn to crank out lean, fast, scalable web apps in record time.
Not if I could help it. PHP's verbose "everything is a long-named function call" syntax is just hard on my eyes at this point. I find it tedious to optimize as well (every page load reinterprets the source code in a default configuration).
Here are a few of the gotchas to be aware of:
For cheap, low-traffic sites, it's much harder to find a web host with a good python environment.
Apache isn't really a typical setup for Python in my experience. Python webapps are usually daemons that are exposed to the public with a reverse proxy webserver in front (nginx is very common). A number of corporate environments balk at new-fangled technology like nginx. It also takes some adjustment to think about your webapps as daemons, and it can take some effort at first to get your daemonizing correct and consistent.
If you use mysql, you will have some pain switching for a while. There just isn't a Python mysql library that is highly compatible with PHP-style mysql queries. For example, most of them don't use the simple "?" syntax for parameterized queries, so you can't just paste your queries over (you have to use printf-style "%s", etc.). Also, just the fact that you actually have to choose and install a mysql library is an extra step over PHP. This no longer bothers me, since I don't use mysql anymore anyway.
This is a broad topic with much, much more to say, but I hope this was helpful.
I'll try my best to answer your questions as best I can:
Did you have more fun with python?
I really enjoy how minimalist python is, having modules with non-redundant naming conventions is really nice. I found this to be especially convenient when reading/debugging other peoples code.
I also love all of the python tricks to do some very elegant things in a single line of code such as list comprehensions and the itertools library.
I tend to develop my applications using mod_wsgi and it took some time to wrap my head around writing thread-safe web applications, but it was really worth it.
I also find unicode to be much less frustrating with python especially with python 3k.
are you as productive as when you're using PHP?
For simple websites python can be less fun to setup and use. One nice feature of PHP that I miss with python is mixing PHP and HTML in the same file. Python has a lot of nice template languages that make this easy as well, but they have to be installed.
what made you change to python?
I became frustrated with a lot of the little nuances of PHP such as strange integer and string conversions and so forth. I also started to feel that PHP was getting very bloated with a lot of methods with inconsistent naming schemes. I was referring to the PHP documentation quite frequently despite having a large portion of the php library memorized.
Would you do a project again in PHP? If so, why?
I would develop a PHP project again, it has a lot of nice features and a great community. Plus I have a lot of experience with PHP. I'd prefer to use python, but if the client wants PHP I'm not going to force something they don't want.
Well, I started with PHP, and have delved into Python recently. I wouldn't say that I've "moved to", but I do use both (still PHP more, but a fair bit of Python as well).
I wouldn't say that I have more "fun" with Python. There are a lot of really cool and easy things that I really wish I could take to PHP. So I guess it could be considered "fun". But I still enjoy PHP, so...
I'm more productive with PHP. I know PHP inside and out. I know most of the little nuances involved in writing effective PHP code. I don't know Python that well (I've maybe written 5k lines of Python)... I know enough to do what I need to, but not nearly as in-depth as PHP.
I wanted to try something new. I never liked Python, but then one day I decided to learn the basics, and that changed my views on it. Now I really like some parts (and can see how it influences what PHP I write)...
I am still doing PHP projects. It's my best language. And IMHO it's better than Python at some web tasks (like high traffic sites). PHP has a built in multi-threaded FastCGI listener. Python you need to find one (there are a bunch out there). But in my benchmarks, Python was never able to get anywhere near as as fast as PHP with FastCGI (The best Py performed it was 25% slower than PHP. The worst was several hundered times, depending on the FCGI library). But that's based on my experience (which admittedly isn't much). I know PHP, so I feel more comfortable committing a large site to it than I would PY...
I run a self-developed private social site for 100+ users. Python was absolutely fantastic for making and running this.
did you have more fun with python?
Most definitely.
are you as productive as when you're using PHP?
Mostly yes. Python coding style, at least for me is so much quicker and easier. But python does sometimes lack in included libraries and documentation over PHP. (But PHP seems second to none in that reguard). Also requires a tad more to get running under apache.
what made you change to python?
Easier to manage code, and quicker development (A good IDE helps there, I use WingIDE for python), as well as improving my python skills for when I switch to non-web based projects.
Would you do a project again in PHP? If so, why?
Perhaps if I were working on a large scale professional project. PHP is so ubiquitous on the web A company would have a much easier time finding a replacement PHP programmer.
Last year I switched job to get away from PHP and work in Python. I'm very much satisfied with the decision I made :)
To answer the individual questions:
did you have more fun with python?
Yes!
are you as productive as when you're using PHP?
More productive I'd say. But the overall increased experience in programming also had something to with that.
what made you change to python?
You are not expected to be a jack of all trades in non-PHP jobs. (Photoshop/Web Design/Flash is required for many PHP jobs, and I hate Flash). And I liked Python/Django a lot.
4. Would you do a project again in PHP? If so, why?
If it's small stuff that's better done without any framework, then yes.
I've never really worked with PHP (nothing major) and come from the .NET world. The project I am currently on requires a lot of Python work and I must say I love it. Very easy and "cool" language, ie. FUN!
.NET will always be my wife but Python is my mistress ;)
yes
yes
curiosity, search for better languages, etc. (actually, I learned them somewhat in parallel many years ago)
yes, if a project requires it explicitly
disclaimer: I never really moved from php.
did you have more fun with python?
Yes. Lot more.
are you as productive as when you're using PHP?
No. I think more.
what made you change to python?
Django.
Would you do a project again in PHP? If so, why?
Only if it is required.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm about to begin my next web development project and wanted to hear about the merits of Lua within the web-development space.
How does Lua compare to PHP/Python/JSP/etc.. for web development?
Any reason why Lua would be a poor choice for a web application language vs the others?
In brief:
Lua gives you a smaller, simpler system that you can understand in its entirety, but it is in a much smaller ecosystem; Kepler is all you get, and you will probably have to build some of your own stuff. I find this easy and fun (I make heavy use of the Lua bindings to the Expat parser and the Lua Object Model, which are part of Kepler), but others may prefer to use what everyone else is using.
PHP started out as more of a macro processor than a language, and although it has improved over the years, when people say "X has really gotten a lot better", I tend to be wary of X. I find PHP offputting, but there is a huge ecosystem for web development.
Python is a nice language but much bigger than Lua, and in the throes of a major revision (transition from 2.5 to 3.x). Again you get a big ecosystem; the problem I have with Python is that the language and system are too big for any one person to understand all of. I don't like to be in this situation if I don't have to.
Ruby is a bit of a cleaner language design, and the large Rails ecosystem is a winner. Ruby is less complex than Python but more complex than Lua. Rails is a bit of a beast.
It comes down to this question:
Would you rather understand all the software in your system, even if you have to build a lot of things yourself?
Or would you rather have a lot of things already built for you, even if you wind up not understanding exactly how every piece works?
If you want to understand everything, Lua is your game. If you want a lot of stuff already built for you, I can't advise you how to pick among PHP/Python/JSP/Rails and so on.
More on Lua and Python at Which language is better to use, Lua or Python?
Using Lua for web development is pretty rare...you could do it, but it will be a lot more time consuming than using a language that has matured as a web developing language (PHP) or has good web related libraries (python/ruby/etc.) If you do go with Lua, this means you may end up "recreating the wheel" a lot for what may be easily available in mature web languages.
The better question is, what does Lua offer that you need which is not offered in the other languages you listed? Or do you want to help Lua become a better web development platform by creating a Lua MVC framework like Rails did for Ruby?
The Kepler project is probably the best known starting point for web application development in Lua. They have a mailing list whose archives will have a lot of discussion of the merits of various approaches.
The Kepler site is itself built in a CMS framework called Sputnik written almost entirely in Lua, and based on the Kepler project.
The typical approach with Lua is to use a language suited to interfacing to various system components to implement those interfaces, and to use Lua for business logic and glue. Kepler provides libraries written largely in C that provide access to file systems, databases, and the network to Lua code. It also provides a defined API layer to interface with the web server, with implementations for Apache, any CGI capable server, and Xavante which is a complete web server implemented mostly in Lua.
I'm coming a little late ... but i wanted to throw in another language: Haxe
why?
Haxe is an open source language, driven by a quite small, but active community
Haxe is a platform indepented language ... targets are:
flash player 6-8 and 9-10 bytecode or ActionScript 3 source code
JavaScript source code
PHP source code
NekoVM bytecode or Neko source code (NekoVM is a lightweight and extensible VM, suitable for both server developement, and desktop apps)
C++ source code
Android Java source code is currently being worked on
this means, that as a web developer, you can write both rich clients as well as servers in the same language ... the same code can be later reused for desktop/mobile apps
Haxe is a very expressive and powerful language, featuring:
first class functions (anonymous functions and methods, which are the same in Haxe) and closures as well as Enums with parameters (much like algebraic types) that allow the use of functional approaches
good type system, including generics, structural subtyping etc. ... to simplify its use, the compiler has a very helpful type inference, that ensures code is strictly typed, but saves you a lot of redundancy (variable type is determined by initialization, function return type by type of returned expressions) ...
cross-platform API, including everything from dynamic arrays, to reflection/introspection and a remoting package, that alows you to send whole objects from client to server, from one platform to another ...
consistent and radical language design ... of course it has a few flaws, but these mostly come from the fact, that it targets extremely different platforms ...
girls love it and it'll make you real rich ... :D
the biggest flaw about Haxe is, that it allows untyped coding, at the cost of platform specific execution of untyped code ... when well typed (which is not a lot of work with Haxe in fact), code will be executed the same way on all platforms ... if not, result vary depending on runtime handling of the platform itself ...
to put it in a few words: it's a great language, that allows you to target many platforms ... it's young, it's growing, and you can participate ...
If it's only the language, then I agree with Norman. If the web development framework is important to you, then you have to consider Ruby because RoR is a very mature framework. I love Python, but there seems to be quite a few frameworks to choose from, none of them is dominant. CherryPy, Django, Pylons, web2py, Zope 2, Zope 3, etc. One important indicator to me is that there are more RoR jobs on the market than any other (language, framework).
As far as Lua web frameworks, there is also LuCI. It is mostly used for small embedded systems. We're just starting a project using it, so I can't comment on it too much right now. We're just doing some simple configuration screens similar to what is already provided as examples, so I'm sure it will be sufficient for our needs.
At my workplace we're planning a major refactor on our core product, a web application with several 'modules'. I quoted that because that's one of our main concerns: modules are not really modules, the whole thing is monolithic. The application is written in PHP with smarty templating and using Pear for accessing a MySQL database. We're not really concerned with database independence, although it would be nice if that wouldn't take months to implement.
Our main concerns are that development time/cost is increasing exponentially because of bugs popping up in unrelated places and not having a sound common architecture to rely on to get the most common functionality (each module is basically copy/paste from the previous one, then adapt).
I've got some experience with the web MVC principle, mainly in ASP.NET MVC. I like the clean separation it offers and the testability. However, when trying this on a local machine the app is simply a lot slower than it should be.
Alright, enough introduction, off to the questions:
- Should I rely on caching modules? Does this remove most of the overhead using a good architecture provide? Something like APC.
The application is mainly read. Writing is mainly single values (change a single field on a record). Any OR/M for PHP that are good at this?
Also looking for a flexible MVC framework. I know Zend, CakePHP, maybe Symfony?
The tricky part is that we don't have the luxury of being able to do a full rewrite. We'll have to incrementally improve a currently very messy codebase. This has to be done while writing new code, or fixing bugs. One thing I'd really, REALLY like to be able to do is write a regression test for a new bug before fixing it, to prevent it from popping up again later (this happens, occasionally).
The stack I'm currently considering contains:
MVC framework of choice
Logging (log4php?)
an OR/M of choice (doesn't have to be dynamic, code generation is fine too)
IoC container of choice
Smarty Templating, perhaps abstracted so we can switch it out if we need to.
Opcode cache of choice (we're using one now, forgot which one, have to ask sysadmin)
The main point that worries me is the performance implications of creating clean code in PHP. Seeing it's a parsed language opposed to something like the .NET/Java web stack, creating abstractions for otherwise in-line code (with obligatory separation in different files) might create new problems on another level.
Note: Retag if you come up with more appropriate tags, I'm not sure on the current ones.
Having a clean setup isn't a performance issue, usually. Most performance is spent with databases or other external systems you're talking to.
Except for these there are usually one or two hotspots which might be worth optimizing but for that you should start with a clean design, then use a profiler (like XDebug or ZendDebugger) to identify the bottlenecks.
A clean software design is way more important than the 0.01% performance gain by a "optimized" design. Usuallyit's even cheaper to buy and run more hardware than worry about an "optimized" codebase which is unmaintainable.
I'd stress budgeting time to build tests, with the following arguments to management:
When developers fix a bug, allow them to write a test for the bug. Bugs reoccur much more often than they probably should, and this is a cheap and effective way to stop that completely.
When developers are building new functionality, allow them to write tests under it. Since they're completely familiar with the functionality at that point, this is the least expensive time to build the "safety net" of automated testing.
Don't candy coat how long testing will take you; whether it's 1% of your time or 50%, give that to the manager straight, but stress that building automated testing as a safety net will stop users from hitting as many bugs, and will save developer time for new development instead of bugfixing.
As far as managing an MVC component with a spaghetti code component, we had a similar issue with a large project. What worked well was just taking a directory and making that the new docroot for MVC app (Zend Framework in our case) such that:
old part:
http://site.com/data.php
http://site.com/other.php
new part:
http://site.com/app/controller/action/...
Re authentication, you have a couple of choices. Probably the most logical is to redirect your login.php script to the MVC login and then pass it back to the original page that you want to go with necessary info passed as a GET parameter. This will allow legacy and new systems to exist simultaneously and transparently.
Re slowness, before I would pull out XDebug, I would try to isolate a problematic part and just output times it takes. Faster IMHO.
There isn't any good reason that well structured object oriented code should perform significantly worse than sapghetti php code in a database driven web application. You need to do some profiling to find where your bottlenecks are and optimize accordingly.
You do have a tough (but not uncommon) situation.
As far as organizing the code to minimize bugs, all I can give is a tip of the cap to DRY.
For performance issues, those are easy to find, because their very slowness shows them to you, by this technique.