Java Servlets || JSP || PHP

[JGadrow]

lol Yup. But the very first phrase in what you quoted is the key point of that argument.

[Harkins]

Because it sucks at strings and web coding is, I swear, 80% munging strings by volume.

But I gave it my vote because I didn't like that my preferred choices were missing.

PHP's interpreter is written in C... So, it can't be any better at processing strings seeing as how they have to go through an interpretive process and then are dealt with in C afterwards.

False, PHP adds excellent new abstractions for strings on top of C. If that were true, no language could be better than machine code.

[JGadrow]

False, PHP adds excellent new abstractions for strings on top of C. If that were true, no language could be better than machine code.

Were you speaking of something other than in terms of performance? That's how I thought you'd meant it. In that case there is nothing better than machine code. But boy is it a pain to maintain.

My point with C++ was that you got blazing performance (because it's a compiled language which removes the interpretation layer which is a limit to performance of non-compiled languages) but you also have the excessively large base of knowledge that comes with the language. I mean, this language is so popular it takes up 2 of the top 3 spots at TIOBE so, essentially, you can't throw a rock without it skipping off at least 6 C/C++ coders.

[Harkins]

False, PHP adds excellent new abstractions for strings on top of C. If that were true, no language could be better than machine code.

Were you speaking of something other than in terms of performance? That's how I thought you'd meant it. In that case there is nothing better than machine code. But boy is it a pain to maintain.

Yeah, I was just talking about C++ strings being ugly and awkward.

[Nox]

And yet they're incomparably so much better than C's "strings"....

[dsheroh]

My point with C++ was that you got blazing performance (because it's a compiled language which removes the interpretation layer which is a limit to performance of non-compiled languages)

In principle, absolutely.

In practice, that's really more a matter of who wrote the interpreter vs. who's writing the compiled code.  The interpreter is generally going to be compiled code, after all, and it's probably going to be pretty highly-optimized compiled code at that, since they're generally written and maintained by people who are damn good at what they do and have been given a lot more time and resources to spend on it than the rest of us get for most of our projects, so there are many cases where interpreted languages, despite the interpretation overhead, will perform better than custom-written compiled code doing the same thing.

So, sure, I could write my own string-handling routines in compiled C which do everything that native Perl/PHP/Python/Ruby strings do, but using native strings in Perl/PHP/Python/Ruby would probably run faster anyhow (as well as eating up a lot less development time).

[JGadrow]

In principle, absolutely.

In practice, that's really more a matter of who wrote the interpreter vs. who's writing the compiled code.

No disagreement there. However, you could also write crappy code in the interpreted language as well. Take a developer with equal knowledge of both languages and have him write the same program in both types of application. I would think it very likely that his compiled version would run faster. So, the fact that someone could write a crappy program is irrelevant. With the same amount of knowledge / ability, the compiled language is likely to grant a performance optimization just by its nature. If they know the interpreted language better, then it was my previous advice that they use that one instead.

The interpreter is generally going to be compiled code, after all, and it's probably going to be pretty highly-optimized compiled code at that, since they're generally written and maintained by people who are damn good at what they do and have been given a lot more time and resources to spend on it than the rest of us get for most of our projects, so there are many cases where interpreted languages, despite the interpretation overhead, will perform better than custom-written compiled code doing the same thing.

Again, no argument here. At some level some part of the process is compiled code. Unless there's been a major leap in technology that I'm unaware of.

So, sure, I could write my own string-handling routines in compiled C which do everything that native Perl/PHP/Python/Ruby strings do, but using native strings in Perl/PHP/Python/Ruby would probably run faster anyhow (as well as eating up a lot less development time).

Or, leveraging the fact that C/C++ is one of the most popular languages in the world, you could look and see if someone else has already solved this problem for you. Sure, that's just a quick Google result but I'm certain you could dig up other solutions if you had a specific need in mind. I just did a search for: C++ string handling.

*Edit - Minor grammatical error corrected.

[ST-Mike]

Admins have ignored my deletion request - if you're not going to delete my account then don't have the option there please.

[Delifisek]

Javascrtipt + Your favorite serverside scripting language...