Google programming languages

[bernie1227]

I was talking to some guys who work at google the other day, and it turns out, most google employees hate php. Turns out, google is actually programmed in python, java and c++, just thought I might share that with everyone.

[djr33]

PHP is good for small scale development, especially for newer coders. Personally, as a fairly serious coder, I think it's perfect for me, perhaps because I already know it. I rarely find myself needing anything PHP can't do, but I also don't stress it too much. The only time I find PHP to be too limited is when I want to work with images (beyond the basics), but that's not too frequently, at least not at the moment.

I think it's traq who has posted a few links here about trouble with PHP on larger-scale projects. I can't remember the details, but one of them was about facebook being run on PHP and having trouble because of scale.

PHP isn't perfect, but I don't get why people would "hate" it. If you want to move on, go for it :)

[bernie1227]

the reason they hate it, (and they were quite specfic with the term hate), seems to be because it's basically easier to write new code then to maintain old code, the crux of their argument is that php is terrible to maintain, I just thought this was interesting as prior to this, I had thought google was done in php.

[djr33]

That's a very interesting point. I don't know any other languages well enough to compare them, but I do agree that maintaining with PHP can be difficult.
It's easy to maintain your own code, and I also recommend/try to always comment my code in a very detailed way (sometimes each line).
But there's nothing worse than trying to take apart badly written code and make it work again.

[bernie1227]

I assume the problem comes when many people are working on the same code.

[djr33]

Yeah, I can see that. I wouldn't be surprised at all. In that case, they may be right. But I still think "hate" is an exaggeration-- they just have different needs.

[traq]

maybe it has more to do with how fast php is still evolving. php has never been *overly* concerned with backwards-compatibility - it is "for the most part", but every major release brings at least a few (usually obscure) changes that can "break" older code.

Additionally, new releases often bring new functionality that, while not being "incompatible" in the strictest sense, makes aspects older coding completely obsolete by comparison. The object model between php4 and php5, for example. I recently upgraded from 5.3 to to 5.4 - and WOW, big additions. traits, anonymous functions (similar to javascript's), lots more. Even the little things (such as the new array syntax) is amazing in terms of convenience. I'm never going to write array( ) again.

There is also the simple fact that php is viewed as a "kiddie" language by many simply because of its origins as a web language. A huge portion of php programmers are amateurs or beginners, there's a lot of blind cut-and-pasting going on in the community, and that leads to a big collection of "not-quite-bad-enough-to-fix" code. It's interpreted rather than compiled, so there's the general (not always accurate) expectation that it is slow and inefficient. There is also a good number of php coders, who are generally recognized as "experts" by the amateur community, but (to put it mildly) really aren't very good at programming at all.

As far as documenting php code, or working on large projects collaboratively, it's certainly as possible with PHP as any other mainstream language. PHPdoc is a sort of de facto standard for documenting code (and it works very well), and version control systems (e.g., git) are language-agnostic anyway.


--- edit ---
I'm learning python too, though, and I do like it quite a bit.

[djr33]

Weird. I didn't know about the short array syntax. I suppose I can try that :)
I don't really mind array(), though. It seems logical to me, and it's not excessive to type. I'd like to see some shorter ways to write the annoying ones, like mysql_real_escape_string().

[bernie1227]

The reason is more to do with maintaining it, and how they believe the sacred languages (java, c++ and python) are easier to maintain, and thusly, better for a long term, large scale site such as google.

[traq]

C++ is the "sacred" language (if you want to call it that). Java used to have almost as many haters as PHP does. and Python is still a fairly "new".

Daniel: I didn't think I'd really care about array( ) vs. [ ] , either. But then I tried it. :)

[bernie1227]

C++ is the "sacred" language (if you want to call it that). Java used to have almost as many haters as PHP does. and Python is still a fairly "new".

well they Definately see those three as the holy trinity when it comes to programming languages.

[traq]

whatevs. people can like the languages they like, don't make no difference t' me. :)

If I had the time, I would be focusing a lot more on learning Python, and I definitely plan to dive into C++ as well... but at this point, I kinda have to stay where I'm more productive, and that means the LAMP stack +javascript. We'll see what happens when I can afford to goof around a bit.

[keyboard]

whatevs. people can like the languages they like, don't make no difference t' me. :)


Whatevs? What are you, like 14? ;)

[bernie1227]

Whatevs? What are you, like 14? ;)

Sounds like it :P

Back on topic, they seem to think that JavaScript is pretty good.

[traq]

What are you, like 14? ;)
post corrected; phrase affected.

re:javascript, yes, javascript is cool.

[djr33]

Hm? What? I think Javascript is significantly worse than PHP.
Perhaps that's partly due to browser variation, but to me JS is one of the worst languages out there. If nothing else, note that to be usable it needs libraries like jQuery.
I'm not saying PHP is "good", but if we're picking favorites here, I don't get why JS would make the list.

It's useful and there's nothing better, so it's "good" in that sense, but fundamentally I don't see why it's well designed or anything like that.

[bernie1227]

I actually think that JavaScript is quite usable as a client-side language, and when it comes to the other choices for client-side languages, it isn't half bad. I find the syntax for basic control structures to be fairly similar to php syntax (for loops, if statements, etc.), however, I find JavaScript quite easy to control when it comes to making server-side changes to the code, or validating a form, and from this it is easy to see how a large company like google would adopt it rather then anything else.

Im that you're criticisms of John's beloved JavaScript will be enough to bring him into the conversation :P

[djr33]

John's good at using Javascript-- I'm not sure that he likes it as a language fundamentally (but he may join the conversation now, yes). He has the exact opposite perspective I do: strong familiarity with JS and more recently starting to learn PHP.


I actually think that JavaScript is quite usable as a client-side language, and when it comes to the other choices for client-side languages, it isn't half bad.Which? Are there even other options? In a practical sense, JS is fine. But that doesn't mean it's the best possible language for what it does.

[bernie1227]

Choices:
JavaScript (widely supported since netscape, hence why it is used)
Vbscript (Internet explorer's version of JavaScript, so only on ie)
Perlscript (trust me this is a language, but it requires ie with an active state plugin)

As you can see from the above, javascriot is the only one you can really choose, and looking at the large number of server-side languages, (python, php, perl, etc.), you can see that If someone wasn't happy enough with it, that they would make their own language, it would have happened. (who knows, I may be causing the inception of DanielScript (.ds) here :p).

[djr33]

I don't find the browser-specific variation to be relevant, and anything that requires a plugin is effectively useless. So, that leaves JS.

[bernie1227]

hence why I am assuming that if people hated it so much, they would have made another client-side language

[traq]

Javascript, IMO, is fantastic.

Javascript in the browser (and, admittedly, that's the main place you find it) has this terrible problem called "the DOM". I really like the language itself: it's powerful, straightforward, and I actually prefer its inheritance model over PHP's. As you point out, Daniel, it has serious shortcomings in implementations, as a result of different companies writing their own engines and adding their own features. There are also some dumb things in the language itself, left over from the very beginning, that never got fixed. But I like it.

[djr33]

Hm. The organization of the language? I suppose it's fine.
The two things that bother me most above Javascript are:
1. Using it for anything (=DOM). (I mean, what else is there, in a practical sense?)
2. The inconsistencies both across browsers and a lack of strict syntax requirements. I find it idiotic that JS allows a final comma in arrays-- that's just a terrible way to encourage bad code; likewise, the lack of semi-colons at the end of lines.

If another language were modeled after JS using the same organization, I suppose it could be fine.


hence why I am assuming that if people hated it so much, they would have made another client-side languageIt doesn't work like that. You can't just make one. Take a look at Microsoft Silverlight for example. It's meant to do the same things Flash does. And it does do them. It might even be better (I have no idea!), but it's basically useless because no one has it. Only people who use Netflix, as far as I know, ever bother to install Silverlight. And even Flash (which is very widely supported but not everywhere) has limitations because it's not part of the browser.
Javascript is part of the browser. If you want to see how this works, then just look at HTML/CSS/JS as they get updated-- XHTML and IE, or proprietary CSS, or Google Chrome trying to allow users to drag images onto upload boxes from their desktops. All of that works (at least for a time) only in certain browsers (and then there's the awful backwards compatibility problem), and the result is that creating a whole new language and getting it out there would extremely difficult. Perhaps if the next version of Google Chrome (or IE or FF, or whatever) comes with a new language, then in the next 5-10 versions of all browsers it would become supported. But JS, despite its problems, works, so no one has bothered because that's simply too hard. In the real world, that would also cause more problems, not fewer, because there would not only be many versions of JS, but now there would be many versions of JS and some new programming language (perhaps with other versions out there too).

In contrast, all that a serverside language needs is one individual who wants to install it and use it on a server and then it's immediately compatible with all visitors.
A clientside language needs updates on every user's computer, some sort of movement to make that happen, and probably an insider at one of the major browsers to get things started.
So most people just deal with JS and don't try to change it.

Of course the other option is to fix Javascript, but that has many of the same problems and would, by fixing things, cause backwards compatibility issues.




Traq, I guess you can consider jQuery to be a DOM solution then? It also has other things like Ajax, though. To me, needing to use a library like that (it's very popular, or at least some library for each person), seems to defeat the point. Although there are some extensions/libraries for PHP, it works fine without them and most people don't use/need extras.

[traq]

Traq, I guess you can consider jQuery to be a DOM solution then? It also has other things like Ajax, though. To me, needing to use a library like that (it's very popular, or at least some library for each person), seems to defeat the point. Although there are some extensions/libraries for PHP, it works fine without them and most people don't use/need extras.
yes, absolutely, and it's very good at that. And jQuery is written in ...javascript!

I don't think it defeats the point - every developed programming language has code libraries, application frameworks, extensions, and so forth. It's code reuse. PHP has the PEAR library, Zend framework, all sorts of other ones - as you say, many people never touch them, but I think that's more a result of most people never creating really complicated apps.

[bernie1227]

That's exactly what I am saying Daniel, Say if google and Mozilla decide that they've had enough of JavaScript and go off making some obscure language, supporting it in their browsers and then picking it to opera and Internet explorer, and bam, you've got a new JavaScript, however, that isn't going to happen, because they like JavaScript, (as I mentioned earlier), and you shouldnt fix something that aint broke.

[djr33]

traq, hm, I guess that's true.
But something like PEAR is just an extension of functions for specific tasks.
jQuery actually takes over JS for most things.

Zend isn't very popular as far as I know-- it's out there and used, but not at all in the same way as jQuery. Right?



That's exactly what I am saying Daniel, Say if google and Mozilla decide that they've had enough of JavaScript and go off making some obscure language, supporting it in their browsers and then picking it to opera and Internet explorer, and bam, you've got a new JavaScript, however, that isn't going to happen, because they like JavaScript, (as I mentioned earlier), and you shouldnt fix something that aint broke.
Sure, if in some crazy alternate reality all of the browsers decide to cooperate :)
Look at VML, supported only in IE. It just doesn't work like that. They're trying to compete (which makes it harder on the end users in this case).

It's more like "if it ain't really totally unusable, don't bother fixing it".

[bernie1227]

I going to have to use that quote :p

Very true, but if you look at javascriot as a case study, Internet explorer was running around with vbscript, Netscape had JavaScript, and look where it took us, now JavaScript is the most ( and really only) wide supported client-side language.

[djr33]

Maybe I'm not aware of the details here, but I thought vbscript became Javascript. So it's like merging ASP and PHP into one new thing. Javascript wasn't the first version anyway-- there were a few versions out there that all collapsed into one. Now we can write it all in "javascript" and it works across browsers, but in some sense we're still writing all of the different languages that happen now to be identical.
Is that classification wrong?

[bernie1227]

Maybe I'm not aware of the details here, but I thought vbscript became Javascript. So it's like merging ASP and PHP into one new thing. Javascript wasn't the first version anyway-- there were a few versions out there that all collapsed into one.

A far as I know, vbscript disappeared into the nether, with limited use ( although you can ask keyboard1333 about his rather interesting use of it, in accidentally deleting some of my code ), but it is quite true that JavaScript is not the first iteration of the language, after a quick search, it turns out that it started out as livescript, went to JavaScript, and then was submitted to ECMA international and became standardized.

[djr33]

Hm, looks like I was wrong about that. VBScript is still part of IE, and it is used more generally on Windows OS as well as the basis for ASP scripting. So it's just something totally separate and has been effectively replaced by Javascript (but not merged in any sense) within browsers, including IE.
The exception, I think, is ASP applications that involve client-side components, which is why some websites are IE-only-- they use VBScript and ASP to create the full experience.

[traq]

There's a good reason for jQuery to cover "everything," and not just the stuff that needs it: it's all part of providing a consistent API. It also ties the functionality into jQuery's selector syntax, which is [really] the single most useful thing jQuery does: it gives you an easy way to specify DOM element(s) and wraps them in a nice, neat object wrapper that you can do whatever you like with.

[djr33]

There's no "consistent API" used in PHP, and I don't think anyone really wants one. That's what I'm pointing out as the difference. I agree with what you said though. But in the end, the utility of jQuery to me is a problem of Javascript-- it should by default have all of that functionality built in without needs some extra thing on top of it.

[bernie1227]

Now that's something I Definately agree with, I have a big problem with jquery, in that those functionalities, should not have to have its own library to happen, it should be a built in part of JavaScript.

[djr33]

As should be the cross-browser compatibility made possible by jQuery-- as-is, we need a library to make a single function work in several browsers (eg, getting window height) because the browsers do it differently.

[bernie1227]

You know there is something slightly wrong with a language when it has to have adding to make it more friendly. I don't see why they don't add the jquery functionalities in javascript.

[djr33]

I don't see why they don't add the jquery functionalities in javascript. The irony is that it would take away from the utility-- different browsers would implement it differently and then it would be useless. So having a third-party plugin like that is actually the solution. It's partly inherent in client-side things, at least those that are defined by the browser rather than by a plugin (eg, Flash, which works the same on all devices, with slight variation by Flash version number).

[jscheuer1]

I was very resistant to libraries in general and jQuery in particular even after I started working in them and with it. But now I prefer working in a jQuery environment. I maintain a high degree of fluency in ordinary javascript though. There simply are times when it's either the best or only way to deal with something. The jQuery folks either can't or just don't cover every cross browser peculiarity, and they cover each such issue that they do cover in only one manner. That's almost always with the current most standard method with a fallback method if any for older browsers. So there are times when you might want to reverse that, or opt out of the fallback or use a different fallback. And I've found some things it just doesn't do. Then there are times, like for doing analytics or providing any sort of third party widget via javascript that it's prudent to assume that the page you are going to be used on could use one or more other of various libraries and/or versions thereof already, so it's best to write code like that in ordinary javascript.

And jQuery is only good with 'version 6' browsers and up. That's IE 6 and other browsers released around that time by other browser makers. If you want more backward compatibility as can be demanded in certain environments, you have to write it yourself. jQuery is forward looking and even some earlier Mozilla (Like Firefox 10, or 5 or 3) and other older browsers will fail on some of its code.

When designing a site though, if you're going to use much javascript, do yourself a big favor and use one version of jQuery for the entire site and use it as much as possible in the scripts you employ for the site.

I think a jQuery like library for PHP would be a good thing if it normalized and made concise the usage as much as possible across the various possible server configurations and PHP versions. It would be no substitute for understanding PHP though. It would make writing complex PHP code much more pleasant.

[djr33]

Good to hear your thoughts on it, John. And I completely agree-- replacing JS knowledge with jQuery knowledge is a bad idea, and it's not a replacement for JS in any way. But as you've said, it is helpful or even almost necessary sometimes, which means there's a gap in JS.

I'm not sure what you mean about PHP. I've never had the feeling that I needed something more to handle any of it, except perhaps shortened names for certain functions like mysql_real_escape_string() (which I could do easily myself if I wanted). As someone newer to PHP (again, as I said a few posts ago, a similar experience to mine for JS), what do you think would be useful as far as shortcuts in a library?
There are plenty of extension functions available out there (in many places) and I do use those; but beyond that, I don't really see the need for shortcuts or even how that would function in it. There's no problem like "DOM" or anything remotely parallel to that-- and as needed, PHP has functions for almost everything, either built in or in some cases by extension of some sort.

[bernie1227]

'bout time you joined the party John.

What kind of things would you put in a php library? I might have a thread about what functions people would include in php.

[jscheuer1]

I really don't know enough to make a lot of recommendations. But just as an example a normalization of file_put_contents for PHP less than 5 that would use the native function in PHP 5 and above, while substituting a function using fopen, fwrite, etc. for PHP 4. Things like that so you don't have to think about fallbacks for cross version code. And ways of dealing with server restrictions via changing the local environment. I'm a little less clear on how that would work out and know there are many things that just couldn't be dealt with at that level, but for those that could be, it would make it easier to write cross server PHP code.

That said, I agree that PHP has a lot going for it already. It's just that like writing in javascript with jQuery you can write a lot more code with far fewer lines than with ordinary javascript. If that could be accomplished for PHP, it would be a good thing.

[djr33]

I think PHP is already "far fewer lines", but just not relative to anything :)

There are two major complaints about PHP that are true: 1) the versions change a lot and end up causing problems; 2) the naming conventions are sometimes very odd. (For example file() seems like it should be the default but that does weird stuff with line breaks, while file_get_contents() is actually useful.)

I don't really think either of those is particularly easy to solve, even with some sort of phpQuery, or whatever.

Some sort of system-normalizer wouldn't be a bad idea, something that deals with for example magic_quotes and so forth. I don't know how much overall that would accomplish (how much could be accomplished due to security and variation), but as an idea, it's valid.

Something that really surprises me about jQuery is how smoothly it fits into Javascript, and I really don't understand how that works at all. I can't imagine something parallel for PHP really.

[traq]

I understand what you're saying, John, and I agree. Just to use your example as my own, however, at this point in time, using PHP4 at all should be flatly discouraged.

Cross-platform compatibility is an issue with PHP, but not nearly as much as in javascript because your script isn't going to unexpectedly switch platforms. I generally like to keep my code compatible with PHP5+, and it's not too hard to do so. Keeping code portable between Apache versions/configurations is harder. And when you write PHP on a Linux server and then run it on Windows, obscure things might happen that will just completely baffle you.

Yes, it would be good to wrap everything up so that code would work anywhere, but it's not as pressing an issue.

-----------------
As for the "fewer lines of code" issue, absolutely. That's where frameworks come in. The problem is that object-oriented PHP is much more daunting than object-oriented javascript. With javascript, you really don't even need to tell anyone that that's what they're doing. jQuery is very approachable: Zend framework is definitely not.


...we'll see if this still makes sense to me in the morning. sorry, guys. night

[edit]
Daniel, good points. Something that bothers me about PHP is that different functions take similar parameters in different orders - like strpos( $haystack,$needle ) and in_array( $needle,$haystack ). Another example is all of those string functions which aren't UTF-safe. Those sorts of things would benefit from something like phpQuery (as you put it), but there's a trade-off in performance that I'm not sure would be worth it.

[djr33]

Cross-platform compatibility is an issue with PHP, but not nearly as much as in javascript because your script isn't going to unexpectedly switch platforms.That's a crucial point-- in most PHP scripts, you don't need any cross-platform compatibility-- it'll be running on one server and generating the same text output for everything.
Moving servers can be a pain but with some experience everything works out easily enough (and those few things that are hard are actually very difficult to imagine fixing with something like jQuery).

The real reason for something like that is for distributing PHP, where you get something similar to the problem of Javascript. It's not quite as big a problem, but trying to write, for example, a forum that works on all servers is at this point a bit of a mess.


jQuery is very approachable: Zend framework is definitely not.Hm. I need to try Zend at some point. I don't have any immediate need for it. But I guess I should have some idea what it is and how it works.

[bernie1227]

C++ is the "sacred" language (if you want to call it that). Java used to have almost as many haters as PHP does. and Python is still a fairly "new".

Daniel: I didn't think I'd really care about array( ) vs. [ ] , either. But then I tried it. :)

Back to one of traq's original posts, python was created 4 years before php.

[traq]

didn't mean to imply that it was younger than php, though I didn't know it was that much older. Maybe the python community just complains more about not being taken seriously than the php community does. :p

[bernie1227]

Actually, that sounds surprisingly accurate, according to IRC stats, python is the most talked about out of the three.