Live data from Hacker News

Taking PHP Seriously [pdf]

raw.github.com

141–150 of 155 posts

Re: Taking PHP Seriously [pdf]

#141
post #139

dont see any PHP Seriously. Its just baby garden. Im sorry. PHP will be Seriously if will use major Erlang features: processes, pattern matching, atoms, lists, tuples

So what you're saying is... the language that's holding about 80% of the web together isn't worth taking seriously... because it isn't Erlang? Remind me how many sites are built in Erlang again? Why would lists and tuples be critical in generating html files?

sorry for my English I just mean about these pdf - saw but not see any seriously. I mean that PHP is very seriously but I want some features of Erlang. I love PHP and programming with it but I need pattern matching and long running processes.

Tuples need because they more simple for understand and matching then lists and strings. Tuples can simple converts to lists and back. Tuples more effective with memory.

Only one class can implement tuples now its SplFixedArray. But there bugg when you call createFromArray in own custom class derived from SplFixedArray. Also with small count uts slow.

Try test Erlang and see his power. I hope you think will too, that PHP needs with Erlang features.

Re: Taking PHP Seriously [pdf]

#142
post #115
post #92

Earlier quoted context omitted.

Speaking as someone who works on a 2 million user enterprise app with standard PHP, i would have to counter that: 1) the footguns are easy to sidestep once you know them and are gradually getting removed, 2) standard php has traits and strict typing, but the typing is not for primitive types (which is what Hack adds) and 3) in nearly a decade i have had a single feature where i could have really used a faster php, wh…

PHP(.net) doesnt have strict typing ,but type hinting, which is not the same.

It does have strict typing with objects, but not literals.

If I make a function meow(MyClass $meow) { } it will throw errors if anything other than a MyClass is given to it, including NULL.

Re: Taking PHP Seriously [pdf]

#143
post #139

Earlier quoted context omitted.

So what you're saying is... the language that's holding about 80% of the web together isn't worth taking seriously... because it isn't Erlang? Remind me how many sites are built in Erlang again? Why would lists and tuples be critical in generating html files?

sorry for my English I just mean about these pdf - saw but not see any seriously. I mean that PHP is very seriously but I want some features of Erlang. I love PHP and programming with it but I need pattern matching and long running processes. Tuples need because they more simple for understand and matching then lists and strings. Tuples can simple converts to lists and back. Tuples more effective with memory. Only on…

Alright, my mistake then.

I'll look at Erlang. I'm trying to wedge self-teaching Python into this semester.

Re: Taking PHP Seriously [pdf]

#144

Earlier quoted context omitted.

Well, I'd say it's never better to "try to parse as much as you can" and when encountering such an error simply silently give out a nonsense answer. It's the computer equivalent of a bozo worker who does something random everytime they don't know how to do their job, and then tries to hide any consequences while whistling innocently.

It's not equivalent at all. It is an expected, clearly-defined behaviour - automatic, silent type conversion, with clear rules on how that type conversion works.

I'd bet 1-to-10 that if someone uses '+' operator then that line of code is never expected to encounter "0x4zz5" there. And I'm pretty sure that this addition is not meant to return a number exactly 4 less if it encounters "0z4zz5" instead of "0x4zz5". There is some theoretical chance that it does, but really, it's a lottery-type chance.

The whole total function has something that it's expected to do, some value that it returns in the end - and if it can't do that then any returned value is useless and wrong anyway; and automatic, silent type conversion is the worst possible choice of action, since it not only doesn't work, returning a value that you didn't intend (as other options); but in addition makes the actual bug hard to find and potentially corrupts a lot of stored data before you find the bug.

Re: Taking PHP Seriously [pdf]

#145
post #143

Earlier quoted context omitted.

sorry for my English I just mean about these pdf - saw but not see any seriously. I mean that PHP is very seriously but I want some features of Erlang. I love PHP and programming with it but I need pattern matching and long running processes. Tuples need because they more simple for understand and matching then lists and strings. Tuples can simple converts to lists and back. Tuples more effective with memory. Only on…

Alright, my mistake then. I'll look at Erlang. I'm trying to wedge self-teaching Python into this semester.

If you need some help for any info about initial Erlang ask me.

For start:

http://www.maht0x0r.net/library/computing/erlang.pdf

http://www.erlang.org/erldoc

http://rosettacode.org/wiki/Category:Erlang

http://ruslanspivak.com/2007/09/09/erlang-for-python-program...

and you need emacs24+ for good ide and programming with erlang or just use interactive shell erl for initial start.

Re: Taking PHP Seriously [pdf]

#146
post #117

> Facebook’s PHP Codebase > x * 105 files > y*107 LoC > 10 releases per week > Anecdotally, good engineers are astonishingly productive in PHP Erm... are you kidding me? LoC != productivity, not even close. And it goes downhill from there :( I really, really don't want to rail on PHP (people do that enough, it gets old, yada yada), but you're kinda asking for it here. The only useful point made is about state, althou…

That's a very unfavorable reading of that slide. Who are you to say they are wrong when they talk about their own anecdotal experience? Speaking anecdotally, I got exposed to PHP before I did to Python. I tried Python after hearing how much more amazing than PHP it was. I understand why people say that now, because Python has a "flavor" that I suspect most programmers find more pleasing. I also learned another thing:…

Sorry. I got bitter there at the end, it was uncalled for. I spent 3+ years as a PHP programmer, there's certainly nothing wrong with being a PHP programmer, but it's hard to argue that in 2013 it is still a good and productive platform to learn. It pains me to see newcomers starting out by learning PHP, they are essentially shooting themselves in the foot for at least a year of their life (if they are going to be a professional web dev). I was pretty productive at PHP, but only because I cut my teeth for years writing shitty cgi-style PHP scripts, learning the abortion they call their stdlib, then using PHP's OOP crap and finally using frameworks like CI. Imagine if I had spent that time writing ruby. By the time you get the whole way through, you realize that your "high-level language" should do work for you, not the other way around. I think what it comes down to is that PHP does not mandate good design patterns because it cannot even decide on one itself. Once I understood this, the language was forever tainted.

I think the only reason PHP is still relevant is because it's so damn accessible (kinda like w3schools), every shared hosting provider under the sun gives you apache+php, and when you're starting learning web programming shared providing is the way to go.

Why do you say php and Javascript suffer from the same ailments? They suffer from a few of the same ailments, like a crappy/confusing stdlib (although you don't see mysql_real_escape_string in javascript's API) and funky invisible type coercions. Lack of true OOP in javascript, though confusing to beginners, is a design feature as far as I'm concerned, prototyping gives you the tools to implement OOP however you like. But javascript has had a known design pattern from the beginning, which is very powerful and useful once you learn it. I strongly doubt a (another?) phplint at this point would change anything.

As for the "anecdotally" slide, I read the last statement as a conclusion of the previous stats, which didn't make any sense to me. Either I am completely misreading it or you are taking the phrase "anecdotally" far too literally.

Re: Taking PHP Seriously [pdf]

#147
post #138
post #129

Earlier quoted context omitted.

This is my biggest gripe. PHP just does one thing. You can't really use it for much more then building web pages. Yes, you can use it for scripting but Ruby and Python are much better at this. You have things like Rubymotion(to build iOS and Mac apps), which I'm really liking. Opal which translates Ruby to Javascript. You can build Android apps with Ruboto. You can run Ruby the JVM and call Java libraries. You can ru…

PHP is only meant to do that one thing. It's not really fair to gripe about it not serving a purpose it was never meant to serve.

Same could be said about Ruby. PHP and Ruby are both "General purpose programming languages". I'm not sure Matz saw creating iOS apps when he created Ruby in 1995. Sure it's not fair to gripe about the language. It's not the languages fault, you can only do one thing with it, it's the communities.

Re: Taking PHP Seriously [pdf]

#148
post #129

Earlier quoted context omitted.

This is my biggest gripe. PHP just does one thing. You can't really use it for much more then building web pages. Yes, you can use it for scripting but Ruby and Python are much better at this. You have things like Rubymotion(to build iOS and Mac apps), which I'm really liking. Opal which translates Ruby to Javascript. You can build Android apps with Ruboto. You can run Ruby the JVM and call Java libraries. You can ru…

> Most other PHP frameworks just copy Rails, so why not just use the source. I can't speak for anyone else but for myself regarding this but here we go. I have 12 years experience with PHP, it's my primary language, I know it's got pros and cons, I accept it for what it is and work around it. I know Python is better in terms of standards in languages. I know PHP started out as just a few tools and morphed into a lang…

I think PHP is good for some stuff definitely, and if you know it then by all means use it.

> Yes I can learn a new language basics pretty easily, but am I gonna be able to write a complete app in say RoR with very few google searches or even looking at the manual as fast as I can in PHP

That's debatable. I saw someone finish and sell a property management web app in Rails, without knowing Ruby and next to no knowledge of Rails. I wouldn't recommend it. Rails just gives you a lot of things for free. This is getting to much into a framework vs language thing, which I don't like.

I was just making a case for Ruby as opposed to PHP, especially if your job involves more then just web stuff.

As far as PHP frameworks copying Rails, I'm pretty sure that's just accepted as fact. If you don't use frameworks then that's cool.

Re: Taking PHP Seriously [pdf]

#149

Earlier quoted context omitted.

I've done more projects in PHP than I would care to admit. I ported the University of Chicago's "Uncommon Application" from Cold Fusion to PHP using an OO data access model, MVC, and explicit templates. (This was a long time ago before people realized that MVC was a bad idea.) I've also hacked up a bunch of open source projects (wordpress, joomla). No tests, so you never know what you've fucked up, and you spend more…

You say MVC is a bad idea and yet you complain that php encourages mixing of things? I follow MVC and just ported a fairly large django app to php. Using smarty, I barely had to touch the Django templates. They worked almost out of the box. So if you think Django templates and structure is fine, let me tell you you can get a very similar set up using codeigniter and php.

MVP is a better idea than MVC. I'm not suggesting moving towards mixing code.

Re: Taking PHP Seriously [pdf]

#150
post #105
post #83

Earlier quoted context omitted.

Any programmer in almost any language who mixes types like that without understanding the implicit type conversion semantics is asking for trouble. Implicit type conversion is evil, and I don't see how PHP's sin of favouring string -> number over number -> string is any worse than, say: // Javascript console.log(+(+!![]+(+[]+[]))); // outputs the number 10 Or: // C, Java float celsius, fahrenheit1, fahrenheit2; celsi…

Javascript, C and Java suck, yes. Show me something as bad as the OP in python3 and then maybe you'll have a point.

Even if Python 3's type conversion semantics has no dark corners, I still have a point.

harshreality argued that, because PHP's implicit type conversion leads to weird behaviour, "PHP doesn't work. End of story."

In that case, nearly every widely used language (with the possible exception of Python 3) "doesn't work. End of story." That's not a very interesting or useful story to tell.

Post reply on HN