Ok, PHP got package manager and MVC frameworks, but half of problems mentioned here http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-de... are still not fixed. It's shitty language and package manager and MVC will not help.
In many ways PHP is just now starting to come into its own
71–80 of 133 posts
Re: In many ways PHP is just now starting to come into its own
#72Earlier quoted context omitted.
Plus there is PHP's aesthetics. I can't help but see all PHP code visually unpleasing. Programming isn't just a technical task. It's also an art like writing novels. I'm not satisfied when the code I produce doesn't look pretty, independently from the algorithm. In the article here, the Ruby code looks much cleaner to me than the PHP version, even though it's technically the same. Aesthetics is the main reason why I…
That really depends on what you're writing and how you are doing it. How is this php[1] code uglier than this python[2] code? [1]: https://github.com/laravel/framework/blob/master/src/Illumin... [2]: https://github.com/reddit/reddit/blob/master/r2/r2/controlle...
It is uglier, very easy. How? The dollar signs, curly brackets and angle brackets.
Re: In many ways PHP is just now starting to come into its own
#73I'm as cutting edge in the PHP community as any is going to be (having used the latest betas & community-best-practices since 2004). I still have serious doubts about PHP, and always insist to new developers should learn a (ruby/python/... clojure/...) too. The main problem with PHP is the language itself. There is no paradigm it does well. If you're into class-ical OO, then the language's type system is a joke (esp.…
Plus there is PHP's aesthetics. I can't help but see all PHP code visually unpleasing. Programming isn't just a technical task. It's also an art like writing novels. I'm not satisfied when the code I produce doesn't look pretty, independently from the algorithm. In the article here, the Ruby code looks much cleaner to me than the PHP version, even though it's technically the same. Aesthetics is the main reason why I…
Purely about aesthetics, I find ruby to be ugly and inconsistent. Every time I hear about how beautiful ruby code, I can't help but laugh. You mention the code in the article, and I can't see how it can be beautiful. I mean, it prefers magic over being explixit. It doesn't try to be consistent. You can at least read the php code. With ruby, you have to infer meaning.
Simply put, ruby is ugly as sin. I much prefer php's syntax. Granted, I also much prefer other C style languages, even objective-c. I mean, that probably says it all. Objective-c is probably on the opposite end of the syntax tree compared to ruby.
Re: In many ways PHP is just now starting to come into its own
#74Earlier quoted context omitted.
I don't really want to stand up for php, but this just isn't true. "git push heroku master" comes at a steep price. PHP hosting is, in general, ubiquitous, cheap, and incredibly easy. You can get comparable pricing for ruby hosting, but you'll be doing some server setup yourself.
"git push heroku master" comes at a steep price. Um... what? 1 dyno is free on heroku. You host it for nothing. Am I missing something?
yeah you're missing something, unless you're just running something low priority like a personal blog:
Although an app may not require the resources of more than a single dyno, we recommend running at least 2 dynos for a production app. One reason for this is that dynos restart roughly every 24 hours, and dyno redundancy helps ensure that you don't experience excessive queueing or dropped requests while a single dyno restarts. Additionally, dynos and the processes running on them can occasionally crash, and having another dyno helps ensure that you don't have downtime while that dyno recovers. Finally, single web dynos sleep after an hour of inactivity, and having a second dyno means that all dynos will stay awake.[1]
[1] https://blog.heroku.com/archives/2013/4/26/introducing_produ...
Re: In many ways PHP is just now starting to come into its own
#75Earlier quoted context omitted.
Enough with the "JavaScript is a functional language" myth, please. Merely having first-class functions does not make a language a functional programming language. JavaScript does not promote the use of pure functions, referential transparency, and the minimization of state. JavaScript does not encourage the use of recursion. JavaScript has an atrociously broken type system, rather than a robust and theoretically sou…
What is the nature of functional programming? HoF.
Support for higher-order functions is obviously a minimal requirement of a "functional programming language". But functional programming extends far, far beyond that.
It also embodies a philosophy emphasizing the purity of such functions. It encourages the use of recursion for iteration. It encourages the use of robust type systems. It encourages the use of pattern matching. It discourages the use of many imperative approaches.
Although they may offer some form of higher-order functions these days, I don't consider languages like JavaScript, C#, C++, Ruby or PHP to be "functional programming languages". They're imperative languages that just happen to have added the most basic of functionality expected from functional programming languages. They don't truly encourage, and only partially enable, the writing of software using a functional approach.
Re: In many ways PHP is just now starting to come into its own
#76Earlier quoted context omitted.
That really depends on what you're writing and how you are doing it. How is this php[1] code uglier than this python[2] code? [1]: https://github.com/laravel/framework/blob/master/src/Illumin... [2]: https://github.com/reddit/reddit/blob/master/r2/r2/controlle...
Is that really a good comparison? The PHP code you linked to is basically a class with a bunch of getters and setters. The Python code, on the other hand, handles numerous real-world HTTP requests that do actual work. So it's not unexpected that the PHP code is lighter; it doesn't really do anything useful! Although it helps implement a wiki system, the Python code is still very readable and comprehensible with minim…
Well, wherever you look you'll find the same thing as the whole framework is written in the same way: specific classes with small methods. And you can't say that the framework as a whole does nothing.
I agree about the python code that it is reasonably readabale, but i still think it's ugly. Those two things are not the same.
Re: In many ways PHP is just now starting to come into its own
#77Earlier quoted context omitted.
I'm not saying it really matters, but the PHP just looks ugly to me. I think it's all the dollar signs and braces.
That's a mirror image of 'Lisp just looks ugly to me. I think it's all the parentheses.'. There is a lot more to a language than its syntax.
Syntax is highly important, however. A poor syntax can make an otherwise decent language quite unbearable. A nice syntax doesn't make an otherwise poor language good, either.
Re: In many ways PHP is just now starting to come into its own
#78Earlier quoted context omitted.
> PHP is still the only language that assumes HTML output by default. For me, that's not a feature, it's an oddity that I have to work around. I guess it's a feature if you're using PHP as the HTML template language it was designed to be, but I suspect that's a minority use case these days.
How is the default header of `Content-Type: text/html` Any different form a default header of `Content-Type: text/plain`? It takes you about 3-4 seconds to change it for your entire project.
That's not what I mean, and I don't think it's what the person I replied to meant either. I assume text/html is the default content type for all web frameworks.
I was referring to the fact that the first thing pretty much all PHP apps do is say "Wait! Don't output anything yet! I have code to run!". I believe modern PHP frameworks generally borrow the controller/template pattern from other languages, because it generally makes more sense than PHP's default of outputting HTML unless told otherwise.
Re: In many ways PHP is just now starting to come into its own
#79Earlier quoted context omitted.
Plus there is PHP's aesthetics. I can't help but see all PHP code visually unpleasing. Programming isn't just a technical task. It's also an art like writing novels. I'm not satisfied when the code I produce doesn't look pretty, independently from the algorithm. In the article here, the Ruby code looks much cleaner to me than the PHP version, even though it's technically the same. Aesthetics is the main reason why I…
Purely about aesthetics, I find ruby to be ugly and inconsistent. Every time I hear about how beautiful ruby code, I can't help but laugh. You mention the code in the article, and I can't see how it can be beautiful. I mean, it prefers magic over being explixit. It doesn't try to be consistent. You can at least read the php code. With ruby, you have to infer meaning. Simply put, ruby is ugly as sin. I much prefer php…
Simply put, ruby is ugly as sin. I much prefer php's
syntax. Granted, I also much prefer other C style
languages, even objective-c.
*I mean, that probably says it all.*
Re: In many ways PHP is just now starting to come into its own
#80"Jeff Atwood has stated publicly that one of his ulterior motives with the Discourse project is get people to stop using PHP and start using Ruby." This just won't ever happen. The people that wanted to drop PHP for something else (Ruby, etc) largely did so years ago. The hosting/running situation for PHP is just too basic and easy for people to get in to vs having to 'run a server' (Rails, etc). PHP is still the onl…
> PHP is still the only language that assumes HTML output by default. For me, that's not a feature, it's an oddity that I have to work around. I guess it's a feature if you're using PHP as the HTML template language it was designed to be, but I suspect that's a minority use case these days.
I would actually argue that using PHP as the templating language in a PHP MVC application has become the majority use case.
Why layer an additional templating language (Smarty, etc) on top of PHP - incurring extra processing and parsing - when PHP is a perfectly capable templating language itself?
There are cases where you may need to do this (if you can't "trust" the templates for example and you need to enforce some kind of validations or restrictions on them) but otherwise you just need to follow/enforce business rules about what can go in your views, and just use plain ol' PHP..