Does anyone else wish the C++ standards committee would give us parity with other programming languages?
Anonymous Infidel - Aborted Islam with a hanger
Yannick Tremblay
Anonymous Infidel - Aborted Islam with a hanger <messi...@yahoo.com> wrote:
>Or better yet, force them(C#, Java, etc) to do the catch up game....
Might be useful if you would clarify what in your mind is making the
C++ language trail behind these other languages.
Yan
Anonymous Infidel
>
> Might be useful if you would clarify what in your mind is making the
> C++ language trail behind these other languages.
Note: You can use Google to see the differences between C++ and other
programming languages.
Juha Nieminen
> Simple...That would be all the things they can do that C++ can't.
If C++ is not doing what you want, then the answer to this problem is
also rather simple: Don't use C++.
Stop bitching and trolling.
co...@mailvault.com
> Anonymous Infidel wrote:
> > Simple...That would be all the things they can do that C++ can't.
>
> If C++ is not doing what you want, then the answer to this problem is
> also rather simple: Don't use C++.
>
That may be the answer in some cases, but I'm not sure it's
a very good answer in other cases. Java has some strengths
in terms of reflection and marshalling support that C++
doesn't have. Both languages have their strengths and
weaknesses -- Java in my opinion has more than it's fair
share of weaknesses, but C++ has some weaknesses as well
also. What if you need to write a scientific application
that needs to send and receive a lot of messages? It would
be helpful to have the strengths of C++ and Java for that
application.
Brian Wood
Ebenezer Enterprises
www.webEbenezer.net
Anonymous Infidel
>
> If C++ is not doing what you want
Thx to companies, like Microsoft, coming up with their own proprietary
crap.
Thx to the fact that we can use the other languages within our
program.
Thx to the fact that we can do asm within our code.
Etc, etc, etc. [It would be grand if we could just do everything
directly using C++]
>
> Stop bitching
Sadly, that is all we got.
Eww, the standards committee is going to standardise support for
multithreaded programming...Yipeee. [We should have had that how many
years ago?]
>
> and trolling.
I did no such thing.
Note: I love C++...it just frustrates me on how I have to use the
above methods to get things done. Don't you feel the same way Juha?
Arne Mertz
> What if you need to write a scientific application
> that needs to send and receive a lot of messages? It would
> be helpful to have the strengths of C++ and Java for that
> application.
>
You'll have to search a third language that has the strengths that
you really need - and perhaps some weaknesses that neither Java nor
C++ have.
The problem is: some things that could be considered weaknesses in a
certain context/with respect to a certain application you want to
code, are strengths in other contexts/applications. There is no
means to have a perfect language, so in most cases there is no sense
in wanting your favourite feature of other languages in C++ (or Java).
The standards committee won't ever give us parity with other
programming languages WRT automatic memory management, e.g. garbage
collectors and all that stuff that make Java & Co. so "easy to use".
They won't because C++ is not designed to have GC. Its not a bug,
its a feature that we must/can manage the free stor ourselves.
At any time there are lots of people complaining about "flaws" that
C++ has and that should be correctet - not realizing that
"correcting" these flaws would cut away some basic features of the
language.
Sure, there are things that could be done better. And the committee
is working hard to get them done better. And we _are_ given parity
with other languages, in many areas C++ is even doing better than
most other languages. In other areas, the other languages are doing
better than C++.
Arne
Thomas J. Gritzan
> Or better yet, force them(C#, Java, etc) to do the catch up game....
Why should we force the C# guys or the Java guys to catch up with C++?
Well, it would be nice if those languages had support for RAII, or even
templates, but why force them? ;-)
--
Thomas
sebastian
What are you talking about? Catch up *how*? You can do just about
anything with C++. You might have to write it from scratch, of
course...
James Kanze
> > >Or better yet, force them(C#, Java, etc) to do the catch up game....
> > Might be useful if you would clarify what in your mind is making the
> > C++ language trail behind these other languages.
> Simple...That would be all the things they can do that C++ can't.
Which are? And what about all the things you can do in C++ that
you can't do in Java.
> Note: You can use Google to see the differences between C++
> and other programming languages.
Who needs to? Most of us have actively programmed in several
different languages. Including some of the newer ones, like
Java or C#.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
> c...@mailvault.com schrieb:
> The problem is: some things that could be considered
> weaknesses in a certain context/with respect to a certain
> application you want to code, are strengths in other
> contexts/applications.
The problem is, exactly, that one size doesn't fit all.
> There is no means to have a perfect language, so in most cases
> there is no sense in wanting your favourite feature of other
> languages in C++ (or Java). The standards committee won't
> ever give us parity with other programming languages WRT
> automatic memory management, e.g. garbage collectors and all
> that stuff that make Java & Co. so "easy to use".
I wouldn't bet on garbage collectors. The committee has voted
in favor of them, although for schedule considerations, not
right away.
> They won't because C++ is not designed to have GC. Its not a
> bug, its a feature that we must/can manage the free stor
> ourselves.
Not really. It's a feature that we *can* manage it ourselves,
when appropriate. But the basic philosophy of C++ is to give
the programmer the choice, which means garbage collection when
appropriate.
> At any time there are lots of people complaining about "flaws"
> that C++ has and that should be correctet - not realizing that
> "correcting" these flaws would cut away some basic features of
> the language.
Or break backwards compatibility. The biggest "flaw" C++ has is
a totally broken declaration syntax, which leads to all sorts of
ambiguities and problems. It inherited that flaw from C, and
anything which might fix it would probably also break all, or
almost all existing code.
Anonymous Infidel
> > > Might be useful if you would clarify what in your mind is making the
> > > C++ language trail behind these other languages.
> > Simple...That would be all the things they can do that C++ can't.
>
> Which are? And what about all the things you can do in C++ that
> you can't do in Java.
>
> > Note: You can use Google to see the differences between C++
> > and other programming languages.
>
> Who needs to?
>
> Most of us
So you speak for everyone now? [When was that vote held?]
>
> have actively programmed in several
> different languages. Including some of the newer ones, like
> Java or C#.
Have a nice day.
Anonymous Infidel
wrote:
areas C++ is a lil behind. [IMHO, it's still the best language out
there and with asm can do all the good things other languages can]
James Kanze
> > > > >Or better yet, force them(C#, Java, etc) to do the
> > > > >catch up game....
> > > > Might be useful if you would clarify what in your mind
> > > > is making the C++ language trail behind these other
> > > > languages.
> > > Simple...That would be all the things they can do that C++ can't.
> > Which are? And what about all the things you can do in C++
> > that you can't do in Java.
> Read what I said about Google.
In other words, you don't know of any.
As I said, I've yet to find anything important that I could do
in Java that I couldn't do in C++, and I've extensive experience
in both languages. (There is perhaps one exception: reflection.
But other than creating a class, given its name, I've not found
that much use for it. And while it takes more work in C++ to
create an instance of a class, given its name, the results are
more robust.)
> > > Note: You can use Google to see the differences between
> > > C++ and other programming languages.
> > Who needs to?
> Clearly you do...Seeing as how you asked the question above.
Clearly I don't, since you can't site any counter examples (even
if you've used Java).
> > Most of us
> So you speak for everyone now? [When was that vote held?]
I'm speaking about the people who post regularly here. I don't
know of any experienced C++ programmer who isn't competent in
several other languages as well.
> > have actively programmed in several
> > different languages. Including some of the newer ones, like
> > Java or C#.
> Then why did you ask me what the differences were above?
I didn't ask what the differences were; I know what the
differences are (and why we continue to use C++ for most serious
applications, rather than Java or C#). You claimed that there
were things you could do in Java, but not in C++. I asked you
to back up that claim. Obviously, you can't.
Christof Donat
> As I said, I've yet to find anything important that I could do
> in Java that I couldn't do in C++, and I've extensive experience
> in both languages.
I'd say, e.g. writing web applications in C++ is a bit more difficult than
just hacking a servlet. Of course it is not impossible, but it is hard
compared to Java. On the other hand hacking a servlet is more complicated
than hacking a PHP script and PHP nowadays is powerfull enough to even crete
bigger web applications.
So this is just an type of application where I wouldn't prefer to use C++ at
the moment.
> You claimed that there
> were things you could do in Java, but not in C++. I asked you
> to back up that claim. Obviously, you can't.
Of course it is enough to know, that C++ is turing complete. I guess his
point was more on things that are a lot easier to do in Java than in C++.
Other things apart from web applications that come to my mind are the more
or less standardized OR-mapper (JDO), an aspect oriented framework for
enterprise applications (spring), a standardized, platform independent UI
library (Swing, I guess Qt could fill that gap), etc.
I don't think, all of this should be in the standard, because in my oppinion
it doesn't belong there. But a set of libraries and frameworks that are
close to the standard, like the boost libraries, could help. Actually being
not close to the standard library is in my oppinion the worst drawback of
Qt.
Christof
Anonymous Infidel
> > > > > >catch up game....
> > > > > Might be useful if you would clarify what in your mind
> > > > > is making the C++ language trail behind these other
> > > > > languages.
> > > > Simple...That would be all the things they can do that C++ can't.
> > > Which are? And what about all the things you can do in C++
> > > that you can't do in Java.
> > Read what I said about Google.
>
> In other words, you
point to some library that uses asm hacks, microsoft proprietary crap,
etc, etc, etc. [Then I would have to point out that it's nonstandard
and not part of C++(which is what we were discussing)]
>
> > > > Note: You can use Google to see the differences between
> > > > C++ and other programming languages.
> > > Who needs to?
> > Clearly you do...Seeing as how you asked the question above.
>
> Clearly I don't
are.
>
> > > Most of us
> > So you speak for everyone now? [When was that vote held?]
>
> I'm speaking about the people
weak attempt to use peer pressure to win a game I'm not playing.
>
> > > have actively programmed in several
> > > different languages. Including some of the newer ones, like
> > > Java or C#.
> > Then why did you ask me what the differences were above?
>
> I didn't ask what the differences were; I know what the
> differences are
none.
Good day to you sir.
James Kanze
> > As I said, I've yet to find anything important that I could
> > do in Java that I couldn't do in C++, and I've extensive
> > experience in both languages.
> I'd say, e.g. writing web applications in C++ is a bit more
> difficult than just hacking a servlet.
And I'd agree. But it's not a language problem, and probably
not even a library problem. The existing infrastructure in web
servers is designed to support Java; it's not designed to
support any compiled language. If there were a demand for it,
it probably wouldn't be that hard to implement a server which
supported C++, but typically, the code the server addresses
directly consists of a lot of small, constantly changing modules
(Java beans)---something where the weaknesses of Java aren't
really significant.
> Of course it is not impossible, but it is hard compared to
> Java. On the other hand hacking a servlet is more complicated
> than hacking a PHP script and PHP nowadays is powerfull enough
> to even crete bigger web applications.
Whatever happened to JSP?
> So this is just an type of application where I wouldn't prefer
> to use C++ at the moment.
There are lots of applications where I choose some other
language; I've probably written more lines of AWK or Bourne
shell in the last year or two than C++. And if I were doing a
lightweight GUI client, I'd probably choose Java, simply because
Swing seems better than either wxWidgets or Qt. (Admittedly,
that might be mainly because I know it better, but the little
bit I've seen of wxWidgets hasn't impressed me, and I don't
really like Qt's policy of an additional preprocessor.) Also,
it's the type of application where Java's portability of
compiled code could be an advantage. Of course, all of this is
perfectly possible in C++: the GUI libraries are there, and
there's certainly nothing to stop a vendor from implementing C++
in a VM. (And portability isn't always an issue---more than a
few companies standardize on Windows on a PC for their client
machines.)
> > You claimed that there were things you could do in Java, but
> > not in C++. I asked you to back up that claim. Obviously,
> > you can't.
> Of course it is enough to know, that C++ is turing complete.
Yes and no. I considered pointing that out, but I think that
there's a real sense that it's irrelevant. Java is also Turing
complete, but there are more than a few things that you can't
write in Java. Turing complete only concerns the actual
calculations---the fact that a language is Turing complete
doesn't necessarily mean that you'll be able to write device
drivers in it, for example. (And of course, you can't write the
kernel code which does the context switching in either Java or
C++.)
> I guess his point was more on things that are a lot easier to
> do in Java than in C++.
His point is not at all clear. My postings have tried to make
him make it clear, by asking him what he means---what can you do
in Java that you cannot do in C++, or at least, what does he
have in mind. Especially given his mention in the header of the
standards committee: the standards committee doesn't address
larger environment issues; there's nothing that the standards
committee could do, for example, to force web servers to give
C++ the same level of support they give Java.
There are certainly cases where other languages are to be
preferred; as I said, I've probably written more lines of Bourne
shell and AWk than C++ recently. But I fail to see any "lack of
parity", nor anything that the committee can or should do in
this respect. There are some important pieces missing: C++
doesn't have a decent module system. But then, Java (and C#?)
are even worse in this respect; using header files, you can at
least fake it in C++. And it would certainly help if garbage
collection were standand, rather than a third party library, and
threading did come a bit late---doubtlessly due to aleas of the
schedule. It was too soon to add it in the last version of the
standard, which means effectively waiting 10 years. But it's
quite possible to use garbage collection or threading in C++
today---a fair number of people use garbage collection, and I'd
guess that most use threading. In theory, both require some
support from the standard, but in practice, all of the existing
implementations do avoid things that would prevent them from
working, even if the standard doesn't require it.
Christof Donat
> On Mar 29, 2:07 pm, Christof Donat <c...@okunah.de> wrote:
>
>> > As I said, I've yet to find anything important that I could
>> > do in Java that I couldn't do in C++, and I've extensive
>> > experience in both languages.
>
>> I'd say, e.g. writing web applications in C++ is a bit more
>> difficult than just hacking a servlet.
>
> And I'd agree. But it's not a language problem, and probably
> not even a library problem. The existing infrastructure in web
> servers is designed to support Java;
No. Most installed web servers use apache as server software. Apache doesn't
support java without any additional modules and an external server process,
but apache supports C modules without any changes. It is a problem of the
API. The apache module API is - well - a bit more complicated thant the
servlet API.
I agree with you, that it is not a language problem, but I think it is a
library problem.
> it's not designed to support any compiled language.
Well, C is a compiled language, isn't it? Apart from the apache module
interface the CGI interface as well as the FastCGI Interfacce is completely
language agnostic. You could even write CGI scripts in Java - just that it
will start the whole VM for every request. The difference is that scripting
languages like Perl, Python or Ruby come with an API that supports easy
writing of portable CGI applications.
> If there were a demand for it,
> it probably wouldn't be that hard to implement a server which
> supported C++,
Web developers care much about not binding themselves to a speciffic
implementation. Java servlets work with any servlet container, not just
tomcat. CGI scripts written in Perl work anywehere where a Perl interpreter
is available and the Webserver supports the CGI interface (virtually any).
PHP scripts just need one of three ways to get the PHP interpreter run:
apache module, CGI or FastCGI.
As an example why this might be important: beginning with version 2 apache
supports multithreaded operation in contrast to just multiple processes. The
PHP apache module does not. whenever you whant to use the PHP apache module
you must go back to processes. For a customer we switched to the FastCGI
Version of PHP without any code changes. Then we could use a multithreaded
MPM module which increased the throughput of the server more than one order
of magnitude on the same hardware.
> but typically, the code the server addresses
> directly consists of a lot of small, constantly changing modules
> (Java beans)---something where the weaknesses of Java aren't
> really significant.
That is not true as well. Typically a web application itsself doesn't change
too much if it is well thought out. Maybe some bugs are fixed or some
components are added once in a while, but usually nothing changes all the
time. Some of the weaknesses of Java are the reason why there is a servlet
API and not just CGI.
Actually I think, C++ as a language and as a runntime environment as much
more potential for web applications than Java ever had, but there is no easy
to use portable API:
1. There is the possibility of writing apache, IIS, whatever sever modules.
The drawback is that you are tied to apache, IIS, whatever then.
Additionally these APIs are usually not really too simple.
2. The second way is to use CGI. Then for every request a process will be
spawned and the application will be started. That is OK for small things,
but as soon as your program becomes more complex, you have long startup
times, can't share ressources over multiple requests (e.g. DB connections)
and have to use usually platform speciffic shared memory APIs to facillitate a
fast communication between parallel requests.
3. The third way is FastCGI. With FastCGI all the drawbacks of server
modules and CGI can be solved, but my understanding of "easy to use" is
something very different.
>> Of course it is not impossible, but it is hard compared to
>> Java. On the other hand hacking a servlet is more complicated
>> than hacking a PHP script and PHP nowadays is powerfull enough
>> to even crete bigger web applications.
>
> Whatever happened to JSP?
There still seem to be some people out there using it, but it has proven to
be the worst of two worlds. Well designed web applications that should stay
so usually don't use JSP. Whenever you use JSP as view abstraction in a
application that will be maintained by multiple developers, someone will
come along and put code into the JSP that doesn't belong in the view, but in
the application layer.
As you see, JSP is considered harmfull. Use explicit template systems like
e.g. XSLT instead.
Of course the same thing happens with PHP, but that is just a basic language
problem of PHP that Java itsself doesn't have. Why add it?
> And if I were doing a
> lightweight GUI client, I'd probably choose Java, simply because
> Swing seems better than either wxWidgets or Qt.
Actually I'd prefer either XUL/XBL/JavaScript or Python/PyQt.
> there's nothing that the standards
> committee could do, for example, to force web servers to give
> C++ the same level of support they give Java.
As I said, I don't think it should be in the standard. A well defined API,
like WSGI for Python as a start, and a fiew implementations that are as
portable as possible and can use various server APIs (e.g. apache module,
FastCGI and CGI) or run as a minimal stand allone HTTP server would be a
good beginning. Not in the standard, but very closely related to it.
How could this happen? The committe I guess has a lot of more important
things to do. So maybe we could find some interested people and first describe
such a API and then implement it. If the committe spreads the word of that
API as the state of the art way of implementing web applications with C++,
that would be great support for their part.
Christof
Yannick Tremblay
You know, there's a difference between constructive criticism or
starting a worthwhile discussion on possible improvements to the C++
language and moaning or trolling. At your post stand, I am afraid I
can't classify them as constructive criticism...
Of course C++ is not perfect but no language is. You can use Google
to search anything about anything. You can use google to search for
the difference between Java and other programming language.
If you are really interested in improving on the flaws of C++, then
please start discussing about some features that say you like in Java
and you would like to see in C++. Who knows, there might be a simple
way to do it, someone may have written or be motivated to write a
library to solve this flaw or this discussion might even lead to a
proposal to the standard committee. Your posts as they stand lead to
nothing useful.
Yannick
Anonymous Infidel
> >programming languages.
>
> You know, there's a difference between constructive criticism
Stroustrup himself, is going to change how fast the committee works.
[Any discussion about A, B or C being added in 2100 is
pointless...Which is why I refuse to do it]
> If you are really interested in improving on the flaws of C++
The only flaws are a slow standards committee and the only way to fix
it is to replace em.
Note: I will let you work on that.
Have a nice day.
Noah Roberts
Tell you what, go do their job and let us know how long it takes.
Anonymous Infidel
need to wait for the CSC to have support for multithreaded apps]
Tony
"James Kanze" <james...@gmail.com> wrote in message
news:25b2360c-da3a-444b...@j39g2000yqn.googlegroups.com...
> At any time there are lots of people complaining about "flaws"
> that C++ has and that should be correctet - not realizing that
> "correcting" these flaws would cut away some basic features of
> the language.
"Or break backwards compatibility. The biggest "flaw" C++ has is
a totally broken declaration syntax, which leads to all sorts of
ambiguities and problems. It inherited that flaw from C, and
anything which might fix it would probably also break all, or
almost all existing code."
Of course "talk is cheap". Don't use C++ for new development. (OK, you have
no choice. You will have choice "shortly" though). I use it too, but have
stopped production code of any kind seeing the future is built upon the
artifacts of C++ and other languages. D did it poorly, IMO, the next guy may
do it better or not, but it will happen.
Tony
Tony
On Mar 27, 6:55 pm, Anonymous Infidel <messiah2...@yahoo.com> wrote:
> > >Or better yet, force them(C#, Java, etc) to do the catch up game....
> > Might be useful if you would clarify what in your mind is making the
> > C++ language trail behind these other languages.
> Simple...That would be all the things they can do that C++ can't.
"Which are? And what about all the things you can do in C++ that
you can't do in Java."
That's not the problem, but you seem to jump at the bit for those
opportunities to propagandize. (?).
> Note: You can use Google to see the differences between C++
> and other programming languages.
"Who needs to?"
Prima Donna" remark?
" Most of us"
Please do expound on how you assert that information. Do you have privy on
how many lurkers read this ng? Who is "us", in your mind?
Tony
Tony
"I'm speaking about the people who post regularly here. I don't
know of any experienced C++ programmer who isn't competent in
several other languages as well."
Are you asserting that fluency in multiple languages is "trumping" those who
program in only one language? Why? C'mon now, C++ as the lowest level,
close-to-the hardware language and promoting potential eco-system of library
development has failed: it's for rocket scientists only and has held back
humanity (it hasn't, the implementors have). YOU may be a scientist, but to
hold back others because of technicality? Pfft!
NO BAILOUT FOR GM/CHRYSLER/FORD/C++
> > have actively programmed in several
> > different languages. Including some of the newer ones, like
> > Java or C#.
> Then why did you ask me what the differences were above?
"I didn't ask what the differences were; I know what the
differences are (and why we continue to use C++ for most serious
applications, rather than Java or C#). You claimed that there
were things you could do in Java, but not in C++. I asked you
to back up that claim. Obviously, you can't."
Sounds like a pissing contest in the making. JK pissing his false authority
first, hoping that it will delude the infidel (no pun on the troll's nick
meant).
Tony
Tony
"Christof Donat" <c...@okunah.de> wrote in message
news:gqnknk$22l$1...@svr7.m-online.net...
> Hi,
>
>> As I said, I've yet to find anything important that I could do
>> in Java that I couldn't do in C++, and I've extensive experience
>> in both languages.
>
> I'd say, e.g. writing web applications in C++ is a bit more difficult than
> just hacking a servlet.
Uh oh!! One of my first projects with my new library was going to be a web
server! (Oh, did you mean HOSTED?)
> Of course it is not impossible, but it is hard
> compared to Java
Uhh... isn't harder to say you are "slave of Sun" ("Are you a slave son?").
> . On the other hand hacking a servlet is more complicated
> than hacking a PHP script and PHP nowadays is powerfull enough to even
> crete
> bigger web applications.
That's "Administratorland".
>
> So this is just an type of application where I wouldn't prefer to use C++
> at
> the moment.
So maybe there is nothing out there for you to use or you want it for free.
Go figure. Guess you'll have to start from scratch huh.
>
>> You claimed that there
>> were things you could do in Java, but not in C++. I asked you
>> to back up that claim. Obviously, you can't.
>
> Of course it is enough to know, that C++ is turing complete.
Uh.. reality check, uh no.
> I guess his
> point was more on things that are a lot easier to do in Java than in C++.
> Other things apart from web applications that come to my mind are the more
> or less standardized OR-mapper (JDO), an aspect oriented framework for
> enterprise applications (spring), a standardized, platform independent UI
> library (Swing, I guess Qt could fill that gap), etc.
I'm not "buying" that. C++ is stillborn. It's progeny hinders it. A few
critical choices were made that will bury it. It's easy to say in
retrospect. A new language (many?) is (are?) imminent. Soon, no one will
program against C++ or Microsoft (apparently in the same category).
> Actually being
> not close to the standard library is in my oppinion the worst drawback of
> Qt.
You are young grasshopper.
Tony
Tony
On Mar 29, 2:07 pm, Christof Donat <c...@okunah.de> wrote:
> > As I said, I've yet to find anything important that I could
> > do in Java that I couldn't do in C++, and I've extensive
> > experience in both languages.
> I'd say, e.g. writing web applications in C++ is a bit more
> difficult than just hacking a servlet.
"And I'd agree. But it's not a language problem, and probably
not even a library problem."
It is.
"The existing infrastructure in web
servers is designed to support Java;"
Your paradigm: web hosts. How does that equate to "software development"?
Incoming request and can't even code up a spit back of bytes?
"Infrastructure?". Marketeering. Develop your own site (and webserver).
Problem solved. Next!
"it's not designed to
support any compiled language."
And so languages should evolved to sit on top of ... no... HTTP is a
protocol. If you're trying to map other paradigms on it, it's building on
weak foundations. Get out of the forrest to see the trees.
"If there were a demand for it,
it probably wouldn't be that hard to implement a server which
supported C++"
HTTP is a protocol and orthogonal to languages. You're proposing
horse-designed-cart.
> So this is just an type of application where I wouldn't prefer
> to use C++ at the moment.
"There are lots of applications where I choose some other
language; I've probably written more lines of AWK or Bourne
shell in the last year or two than C++. And if I were doing a
lightweight GUI client, I'd probably choose Java, simply because
Swing seems better than either wxWidgets or Qt. (Admittedly,
that might be mainly because I know it better, but the little
bit I've seen of wxWidgets hasn't impressed me, and I don't
really like Qt's policy of an additional preprocessor.) Also,
it's the type of application where Java's portability of
compiled code could be an advantage. Of course, all of this is
perfectly possible in C++: the GUI libraries are there, and
there's certainly nothing to stop a vendor from implementing C++
in a VM. (And portability isn't always an issue---more than a
few companies standardize on Windows on a PC for their client
machines.)"
You are "Programmer Extreme" in that you can program in everything. But I
wonder if you can program in anything ascribed. No offense, but I wouldn't
hire anyone on the internet in the tech groups because 1.) They know so much
about so little that they are not useful to me or 2.) They have been in a
commercial programming role and the risk of that taint (patent lawsuits etc)
is too big to take.
I will hire consultants and use them as I see appropriate though. C++
consultants: Nah, been there/here done that.
> > You claimed that there were things you could do in Java, but
> > not in C++. I asked you to back up that claim. Obviously,
> > you can't.
> Of course it is enough to know, that C++ is turing complete.
"Yes and no. I considered pointing that out, but I think that
there's a real sense that it's irrelevant. Java is also Turing
complete, but there are more than a few things that you can't
write in Java. Turing complete only concerns the actual
calculations---the fact that a language is Turing complete
doesn't necessarily mean that you'll be able to write device
drivers in it, for example. (And of course, you can't write the
kernel code which does the context switching in either Java or
C++.)"
Well why don't you write an OS?. That would look good on your resume. Get me
to use it would be even better (or worse!). ;)
> I guess his point was more on things that are a lot easier to
> do in Java than in C++.
"His point is not at all clear."
I think it was clear from the start by his nick that he intended to perturb
or be facetious, but who's to say not malevalent: more money for false
leaders? GM/Chrysler/Ford/Hitler.... Give money? Who's money? Oh you're the
President. I suggest "The Presidency" is as bankrupt as the <> HE intends to
support. Or moreso.
Tony
Tony
"James Kanze" <james...@gmail.com> wrote in message
news:fd494040-a961-48b4...@h5g2000yqh.googlegroups.com...
"There are certainly cases where other languages are to be
preferred"
That set reduces from a top-down analysis rather than a bottom-up on (not
that most programmers stagnate in the realm of code).
"; as I said, I've probably written more lines of Bourne
shell and AWk than C++ recently. But I fail to see any "lack of
parity", nor anything that the committee can or should do in
this respect."
Stop suppressing humanity and abusing people for lack of substance. If there
is substance there, show it to your audience. Else just... I don't know,
cobble a tombstone. ? We're talking about technology, not even, just
technical details... or a tactic?
" There are some important pieces missing"
Then you would have D. C++ is old, dying, has baggage insurmountable. Just
deal with it already.
": C++
doesn't have a decent module system."
As if you were young.
[snip]
10 years according to "the committee"? I not only do not recognize any
"committee" as relevant, I see it as imposing.
Tony
Tony
> Hi,
>
>> On Mar 29, 2:07 pm, Christof Donat <c...@okunah.de> wrote:
>>
>>> > As I said, I've yet to find anything important that I could
>>> > do in Java that I couldn't do in C++, and I've extensive
>>> > experience in both languages.
>>
>>> I'd say, e.g. writing web applications in C++ is a bit more
>>> difficult than just hacking a servlet.
>>
>> And I'd agree. But it's not a language problem, and probably
>> not even a library problem. The existing infrastructure in web
>> servers is designed to support Java;
>
> No. Most installed web servers use apache as server software.
It's administrator level dialog and not appropriate that the language level.
You want a C++ API to Apache? Surely that is there, but maybe HTTP is not
that hard and you'll want to host your own site with your own code (it
sounds so much simpler to me).
> Apache
Go to the Apache rooms. Nuff said.
Tony
Tony
"Yannick Tremblay" <ytre...@nyx.nyx.net> wrote in message
news:73245779...@irys.nyx.net...
> In article
> <12c8d09c-9a90-4dd4...@k19g2000prh.googlegroups.com>,
> Anonymous Infidel <messi...@yahoo.com> wrote:
>>> >Or better yet, force them(C#, Java, etc) to do the catch up game....
>>>
>>> Might be useful if you would clarify what in your mind is making the
>>> C++ language trail behind these other languages.
>>Simple...That would be all the things they can do that C++ can't.
>>
>>Note: You can use Google to see the differences between C++ and other
>>programming languages.
>
> You know, there's a difference between constructive criticism or
> starting a worthwhile discussion on possible improvements to the C++
> language and moaning or trolling.
That's quintesential lamer manager-wannabe-speak: USA meltdown, you are the
reason.
> At your post stand, I am afraid I
> can't classify them as constructive criticism...
I suggest you antagonize the White House's people rather than boring me.
>
> Of course C++ is not perfect but no language is. You can use Google
> to search anything about anything. You can use google to search for
> the difference between Java and other programming language.
>
> If you are really interested in improving on the flaws of C++, then
> please start discussing about some features that say you like in Java
> and you would like to see in C++. Who knows, there might be a simple
> way to do it, someone may have written or be motivated to write a
> library to solve this flaw or this discussion might even lead to a
> proposal to the standard committee. Your posts as they stand lead to
> nothing useful.
Didn't I already note that the "suggestion box" "theory" of first-time
"managers" (read, go to Iraq on the frontline!) IS A CLICHE!!
Tony
James Kanze
> > On Mar 29, 2:07 pm, Christof Donat <c...@okunah.de> wrote:
> >> > As I said, I've yet to find anything important that I could
> >> > do in Java that I couldn't do in C++, and I've extensive
> >> > experience in both languages.
> >> I'd say, e.g. writing web applications in C++ is a bit more
> >> difficult than just hacking a servlet.
> > And I'd agree. But it's not a language problem, and probably
> > not even a library problem. The existing infrastructure in web
> > servers is designed to support Java;
> No. Most installed web servers use apache as server software.
> Apache doesn't support java without any additional modules and
> an external server process, but apache supports C modules
> without any changes. It is a problem of the API. The apache
> module API is - well - a bit more complicated thant the
> servlet API.
Do you know of any Apache servers running without the Java
module. (Come to think of it, our intranet server does. But it
just serves up web pages; it doesn't do anything interactive or
that would require any "programming".)
> I agree with you, that it is not a language problem, but I
> think it is a library problem.
> > it's not designed to support any compiled language.
> Well, C is a compiled language, isn't it? Apart from the
> apache module interface the CGI interface as well as the
> FastCGI Interfacce is completely language agnostic. You could
> even write CGI scripts in Java - just that it will start the
> whole VM for every request. The difference is that scripting
> languages like Perl, Python or Ruby come with an API that
> supports easy writing of portable CGI applications.
Yes. And the Perl interpreter is "compiled" as well. The
lowest level interface has to be at the lowest level, which
means machine code, which is what comes out of the compiler.
But in practice, I can't imagine anyone using this level
directly. As you say, it's a bit more complicated than the
alternatives. But it's true that my distinction concerning
compiled languages is probably not valid. Although it does seem
that all of the higher level API's available are for interpreted
or byte coded languages: Java, Perl, Python, Ruby...
When I spoke of support, I was thinking more in terms of
embedded development tools. I don't think that Apache has any
of these, but other products, like WebLogic or WebSphere do.
But your point is well taken; even before worrying about
embedded debugging, the available API is an issue. And for
whatever reasons, I'm not aware of such an API for C++; I'm not
even sure who should be responsible for it. It obviously
doesn't belong in ISO's hands, since it's only relevant for a
small subset of environments. Maybe Apache should define and
implement one.
> > If there were a demand for it, it probably wouldn't be that
> > hard to implement a server which supported C++,
> Web developers care much about not binding themselves to a
> speciffic implementation. Java servlets work with any servlet
> container, not just tomcat. CGI scripts written in Perl work
> anywehere where a Perl interpreter is available and the
> Webserver supports the CGI interface (virtually any). PHP
> scripts just need one of three ways to get the PHP interpreter
> run: apache module, CGI or FastCGI.
A C++ program can handle CGI too. As you say, the problem is in
the API for accessing it. CGI is standardized, but it's a bit
low level. (One can argue, however, that C++ already has the
interface, standardized, in the form of getenv() and std::cout.
Except that you can't output binary on std::cout.)
> As an example why this might be important: beginning with
> version 2 apache supports multithreaded operation in contrast
> to just multiple processes. The PHP apache module does not.
> whenever you whant to use the PHP apache module you must go
> back to processes. For a customer we switched to the FastCGI
> Version of PHP without any code changes. Then we could use a
> multithreaded MPM module which increased the throughput of the
> server more than one order of magnitude on the same hardware.
And how would this have been any different if you'd have used
C++? Except that you would have had to access at a lower level.
> > but typically, the code the server addresses
> > directly consists of a lot of small, constantly changing modules
> > (Java beans)---something where the weaknesses of Java aren't
> > really significant.
> That is not true as well. Typically a web application itsself
> doesn't change too much if it is well thought out.
Typically, web applications aren't well thought out:-). I don't
know, but the pages I access do seem to change a lot.
[...]
> > Whatever happened to JSP?
> There still seem to be some people out there using it, but it
> has proven to be the worst of two worlds. Well designed web
> applications that should stay so usually don't use JSP.
> Whenever you use JSP as view abstraction in a application that
> will be maintained by multiple developers, someone will come
> along and put code into the JSP that doesn't belong in the
> view, but in the application layer.
> As you see, JSP is considered harmfull. Use explicit template
> systems like e.g. XSLT instead.
Well, I wasn't too impressed with the idea when I used it (a
little bit in early 2002). It seemed like a case of mixing
concerns which should have been separate. Putting all the HTML
in the Java (or C++) code was obviously a pain, but hiding the
Java code buried in the middle of a lot of HTML seemed like just
exchanging one problem for another. (I've been doing a lot of
code generation lately, and I ended up designing and
implementing a template approach as well. All those lines
outputting boilerplate ended up obscuring the actual logic.)
> Of course the same thing happens with PHP, but that is just a
> basic language problem of PHP that Java itsself doesn't have.
> Why add it?
> > And if I were doing a lightweight GUI client, I'd probably
> > choose Java, simply because Swing seems better than either
> > wxWidgets or Qt.
> Actually I'd prefer either XUL/XBL/JavaScript or Python/PyQt.
Since I don't know them, I can't say.
> > there's nothing that the standards
> > committee could do, for example, to force web servers to give
> > C++ the same level of support they give Java.
> As I said, I don't think it should be in the standard.
I don't think it can be. It's a little too specialized. On the
other hand, an organization like W3C could define such.
> A well defined API, like WSGI for Python as a start, and a
> fiew implementations that are as portable as possible and can
> use various server APIs (e.g. apache module, FastCGI and CGI)
> or run as a minimal stand allone HTTP server would be a good
> beginning. Not in the standard, but very closely related to
> it.
> How could this happen? The committe I guess has a lot of more
> important things to do. So maybe we could find some interested
> people and first describe such a API and then implement it. If
> the committe spreads the word of that API as the state of the
> art way of implementing web applications with C++, that would
> be great support for their part.
The problem is that ISO doesn't really have any procedure for
issuing "recommended practices". And it's lead times are
probably too long for this domain as well. The advantage of
Java or C# here is that they belong to a single company, and
don't have to spend the time building consensus. (Of course, in
many ways, that's really a disadvantage. But it sure can
shorten your lead times.)
Christof Donat
>> No. Most installed web servers use apache as server software.
>> Apache doesn't support java without any additional modules and
>> an external server process, but apache supports C modules
>> without any changes. It is a problem of the API. The apache
>> module API is - well - a bit more complicated thant the
>> servlet API.
>
> Do you know of any Apache servers running without the Java
> module.
Yes, almost any of them. Running a tomcat as an additional process on the
same server eats quite an ammount of memory, even if it is not used. So
anywhere where the web applications are not written in Java, the admin
should not install tomcat and the according apache module. The latter would
only add to the workload of apache and is completely useless without a
running tomcat. Most webservers run applications like typo3, Wordpress,
Zope, etc. which don't need any Java servlet engine.
However, how would that change the situation for C++?
> But in practice, I can't imagine anyone using this level
> directly.
The reason for that is, that there is no simple API. I remember to have read
of some company that once tried to establish a clone of the servlet API for
C++, but 1. they only sold their product, there was no alternative
implementation of the same API and noone invests quite an ammount of money
just for trying and 2. they more or less copied the Java Servlet API wich is
fine for Java, but uncomfortable for C++. A good solution should of course
use typical C++ techniques and integrate well with the standard library.
> And for
> whatever reasons, I'm not aware of such an API for C++; I'm not
> even sure who should be responsible for it. It obviously
> doesn't belong in ISO's hands, since it's only relevant for a
> small subset of environments. Maybe Apache should define and
> implement one.
Since the apache project seems to have moved largely towards Java I'd
suggest, we try ourselves. I guess a good starting point for an
implementation could be JAWS
(http://www.dre.vanderbilt.edu/JAWS/research.html#jaws) but before we start
with an implementation the API should be defined.
>> As an example why this might be important: beginning with
>> version 2 apache supports multithreaded operation in contrast
>> to just multiple processes. The PHP apache module does not.
>> whenever you whant to use the PHP apache module you must go
>> back to processes. For a customer we switched to the FastCGI
>> Version of PHP without any code changes. Then we could use a
>> multithreaded MPM module which increased the throughput of the
>> server more than one order of magnitude on the same hardware.
>
> And how would this have been any different if you'd have used
> C++? Except that you would have had to access at a lower level.
It depends on which API we would have chosen. If the application was an
apache module, we would have been forced to make it thread safe, or change
the underlying API. If we had chosen CGI, we never would have been able to
do some optimizations like e.g. sharing of database connections. Only if we
had chosen FastCGI before beeing aware of the concrete problem, we could
have solved it after it has shown up.
If we had written the application in Python, we would have used WSGI as API,
which is quite usual for Python. There are WSGI implementations (I know of)
as apache modules, as CGI Scripts, as FastCGI applications and as a stand
allone server. Even if we had chosen to have it as an apache module in the
first place, we could easily have switched to Fast CGI when needed.
That is exactly the thing that I am missing for C++.
>> > but typically, the code the server addresses
>> > directly consists of a lot of small, constantly changing modules
>> > (Java beans)---something where the weaknesses of Java aren't
>> > really significant.
>
>> That is not true as well. Typically a web application itsself
>> doesn't change too much if it is well thought out.
>
> Typically, web applications aren't well thought out:-). I don't
> know, but the pages I access do seem to change a lot.
When the paqes conntent or appearance change that doesn't mean that the
underlying application has changed. It could be that the data in the
database has changed, or the templates, or even just the css stylesheets.
In any of these cases the application doesn't need to change at all.
>> How could this happen? The committe I guess has a lot of more
>> important things to do. So maybe we could find some interested
>> people and first describe such a API and then implement it. If
>> the committe spreads the word of that API as the state of the
>> art way of implementing web applications with C++, that would
>> be great support for their part.
>
> The problem is that ISO doesn't really have any procedure for
> issuing "recommended practices".
Hm, but there are still people in the standards committe. If (take the best
known ;-) ) e.g. Bjarne would write down somewhere "using this API is very
much recommended for web applications written in C++" that would almost have
an effect like standardization. People would at least consider that API for a
start.
Christof
Ian Collins
> On Mar 30, 1:46 pm, Christof Donat <c...@okunah.de> wrote:
>
>> No. Most installed web servers use apache as server software.
>> Apache doesn't support java without any additional modules and
>> an external server process, but apache supports C modules
>> without any changes. It is a problem of the API. The apache
>> module API is - well - a bit more complicated thant the
>> servlet API.
>
> Do you know of any Apache servers running without the Java
> module.
Many, including most I have configured.
C++ (and C) is widely used in web applications. Not for the business
logic but for the back end (think databases).
I have used this model a few times, PHP script opening a connection to a
running back end C++ application.
--
Ian Collins
James Kanze
> James Kanze wrote:
> > On Mar 30, 1:46 pm, Christof Donat <c...@okunah.de> wrote:
> C++ (and C) is widely used in web applications. Not for the
> business logic but for the back end (think databases).
Certainly. The typical configuration (that I've seen, at least)
has a thin, rather volatile Java layer interfacing between the
server and the business logic (which is typically written in
C++, although I've also seen Cobol, and heard of cases using
Smalltalk or Objective C). The Java is responsible for actually
generating the page display and is what the HTTP server invokes.
(And it's volatile because the visual aspects of the page
display tend to change rapidly).
> I have used this model a few times, PHP script opening a
> connection to a running back end C++ application.
I don't know why, but the sites I've been involved in (even
distantly) have used Java instead of PHP for this. For small
sites (strictly internal use), I've also seen C#. I could
easily be wrong, but my impression was that PHP was mostly used
for private web pages, but not so much for commercial pages.
(As someone else pointed out, it suffers from the same problems
as JSP---the "code" and the HTML are mixed in the same file. I
would think that Java feeding from a template would be far more
readable, and I think that direct support for such exists.)
Ian Collins
> On Apr 3, 9:24 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> I have used this model a few times, PHP script opening a
>> connection to a running back end C++ application.
>
> I don't know why, but the sites I've been involved in (even
> distantly) have used Java instead of PHP for this. For small
> sites (strictly internal use), I've also seen C#. I could
> easily be wrong, but my impression was that PHP was mostly used
> for private web pages, but not so much for commercial pages.
I don't thank that's the case. I can't see any advantages of doing that
and I can see plenty of disadvantages, complexity being one. I recently
set up two wiki servers, one with MediaWiki (PHP) and the other Java
(anonymous to protect the guilty). The former took a couple of minutes,
the latter half a day messing with the application ad Tomcat.
> (As someone else pointed out, it suffers from the same problems
> as JSP---the "code" and the HTML are mixed in the same file.
Not in my shop it doesn't! There isn't any HTML: the PHP pages
generates it.
--
Ian Collins
Christof Donat
>> (As someone else pointed out, it suffers from the same problems
>> as JSP---the "code" and the HTML are mixed in the same file.
>
> Not in my shop it doesn't! There isn't any HTML: the PHP pages
> generates it.
Correct. I didn't say, that PHP applications are always a mix of HTML and code, but that such an "architecture" is generally promoted by PHP. To do bette you need quite some dicipline. The temptation to simply mix HTML into the PHP Code is huge for many developers.
I am currently leading a quite large PHP project. Our modules create a DOM tree and then our framework uses XSLT to create the HTML output. That is great, but I am constantly telling my personnel why their mixed in HTML doesn't appear where they exspect it and that they should not do that. As we see, the temptation is really huge.
That experience and my eperience with JSP lead me to the statement, that with JSP the Java web community just imports the PHP problems. Actually wherever I see Java web applications, they are either old or they don't use JSP any more. Seems like others have made similar experiences and as we see, JSP is considered harmfull - not only by me.
Christof
Ian Collins
> Hi,
>
>>> (As someone else pointed out, it suffers from the same problems
>>> as JSP---the "code" and the HTML are mixed in the same file.
>> Not in my shop it doesn't! There isn't any HTML: the PHP pages
>> generates it.
>
Lets not forget that all those processor intensive (XML parsing, DOM
manipulation) bits of PHP are written in C, or in my case, C++!
--
Ian Collins
James Kanze
> James Kanze wrote:
> > On Apr 3, 9:24 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> I have used this model a few times, PHP script opening a
> >> connection to a running back end C++ application.
> > I don't know why, but the sites I've been involved in (even
> > distantly) have used Java instead of PHP for this. For small
> > sites (strictly internal use), I've also seen C#. I could
> > easily be wrong, but my impression was that PHP was mostly used
> > for private web pages, but not so much for commercial pages.
> I don't thank that's the case. I can't see any advantages of
> doing that and I can see plenty of disadvantages, complexity
> being one.
I'm not sure I follow. I've some experience (a while back) with
JSP, and I found mixing the HTML and the Java code in the same
file a maintenance nightmare. From what I understand, PHP is
pretty much the same thing, except that the code isn't Java, but
something specific to the language. The results seem more
complex to me than using pure Java (or C++, or whatever) to
process a template (which contains the HTML). It may be two
files, instead of one, but each file contains only one thing,
rather than having the two mixed.
> I recently set up two wiki servers, one with MediaWiki (PHP)
> and the other Java (anonymous to protect the guilty). The
> former took a couple of minutes, the latter half a day messing
> with the application ad Tomcat.
The only Wiki I set up used perl. Which was a pain. But I'm
not sure that that has anything to do with the language---if the
Wiki is well implemented, you don't even see what language it is
written in.
> > (As someone else pointed out, it suffers from the same
> > problems as JSP---the "code" and the HTML are mixed in the
> > same file.
> Not in my shop it doesn't! There isn't any HTML: the PHP
> pages generates it.
But PHP contains HTML, doesn't it? From what I remember of the
presentations I've seen of it, it *is* HTML, with embedded code.
In any page, there are large blocks of HTML which are going to
be invariable. Somewhere, somehow, you have to write them---if
it is in C++, not using a template, you end up with something
like:
std::cout << "..." ;
where the ... is twenty or thirty lines of HTML. That's not
maintainable, in the long. In JSP (and from what I understand,
PHP), the basic file starts out as HTML, and the code is
inserted into that. From my experience, that's not too
maintainable either.
Ian Collins
> On Apr 3, 11:47 pm, Ian Collins <ian-n...@hotmail.com> wrote:
>> James Kanze wrote:
>>> On Apr 3, 9:24 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>>> I have used this model a few times, PHP script opening a
>>>> connection to a running back end C++ application.
>
>>> I don't know why, but the sites I've been involved in (even
>>> distantly) have used Java instead of PHP for this. For small
>>> sites (strictly internal use), I've also seen C#. I could
>>> easily be wrong, but my impression was that PHP was mostly used
>>> for private web pages, but not so much for commercial pages.
>
>> I don't thank that's the case. I can't see any advantages of
>> doing that and I can see plenty of disadvantages, complexity
>> being one.
>
> I'm not sure I follow.
Java web applications (at least all those I have had the misfortune to
install) require container like Tomcat. PHP just requires mod-php,
which is pretty much a standard Apache configuration.
> I've some experience (a while back) with
> JSP, and I found mixing the HTML and the Java code in the same
> file a maintenance nightmare. From what I understand, PHP is
> pretty much the same thing, except that the code isn't Java, but
> something specific to the language.
Some web developers may do this, but those of us form an application
development background just write PHP scripts as we would any other
application. Any PHP I write will run just as well from the command
line (so it can be unit tested) as it does from a web server.
> The results seem more
> complex to me than using pure Java (or C++, or whatever) to
> process a template (which contains the HTML). It may be two
> files, instead of one, but each file contains only one thing,
> rather than having the two mixed.
What you describe is how most large scale PHP projects are structured.
Only noddy (or machine generated) application embed PHP in HTML.
>> I recently set up two wiki servers, one with MediaWiki (PHP)
>> and the other Java (anonymous to protect the guilty). The
>> former took a couple of minutes, the latter half a day messing
>> with the application ad Tomcat.
>
> The only Wiki I set up used perl. Which was a pain. But I'm
> not sure that that has anything to do with the language---if the
> Wiki is well implemented, you don't even see what language it is
> written in.
Unless you have to muck about installing and configuring Tomcat!
>>> (As someone else pointed out, it suffers from the same
>>> problems as JSP---the "code" and the HTML are mixed in the
>>> same file.
>
>> Not in my shop it doesn't! There isn't any HTML: the PHP
>> pages generates it.
>
> But PHP contains HTML, doesn't it? From what I remember of the
> presentations I've seen of it, it *is* HTML, with embedded code.
Your are way off base there I'm afraid. My PHP is more lice C++ or Java
code than anything else.
> In any page, there are large blocks of HTML which are going to
> be invariable. Somewhere, somehow, you have to write them---if
> it is in C++, not using a template, you end up with something
> like:
>
> std::cout << "..." ;
>
> where the ... is twenty or thirty lines of HTML. That's not
> maintainable, in the long. In JSP (and from what I understand,
> PHP), the basic file starts out as HTML, and the code is
> inserted into that. From my experience, that's not too
> maintainable either.
Often in PHP, one builds or augments an HTML page with DOM and then
exports it to standard out.
This keeps the presentation (HTML) well away form the program logic.
Don't forget there are more and more Ajax application where the dynamic
HTML is generated by client side scripts and all that goes between the
client and the server is RPC messages. I've built applications this way
with both PHP and C++ (through CGI) and both work well. PHP wins on
portability and speed of development, C++ wins when there is more
complex processing to be performed.
--
Ian Collins
Christof Donat
> Java web applications (at least all those I have had the misfortune to
> install) require container like Tomcat. PHP just requires mod-php,
> which is pretty much a standard Apache configuration.
Yes. At least ther usually is CGI or FastCGI available which can be used for PHP as well.
>>>> (As someone else pointed out, it suffers from the same
>>>> problems as JSP---the "code" and the HTML are mixed in the
>>>> same file.
>>
>>> Not in my shop it doesn't! There isn't any HTML: the PHP
>>> pages generates it.
>>
>> But PHP contains HTML, doesn't it? From what I remember of the
>> presentations I've seen of it, it *is* HTML, with embedded code.
>
> Your are way off base there I'm afraid. My PHP is more lice C++ or Java
> code than anything else.
In a way he is correct. PHP originally was meant to be liek that. It originally was meant to be little more than server side includes. Nowadays it has grown up, but still keeps some flaws from the early days. One of those is that in modern PHP applications all files start with "<?php" and end with "?>".
The really bad side is that when you search for a PHP developer about 50-70% of what you get has not catched up with that. You need a Framework that forces them to maintain an absolute minimum of code quality or your code will become write only pretty soon.
> PHP wins on
> portability and speed of development, C++ wins when there is more
> complex processing to be performed.
Here we come back to my original concern. I'd like to have a simpler more or less standard way to createm C++ web applications. Just CGI is not only too low level, it also doesn't maintain a migration path towards better scalability.
A very basic API that can be implemented using CGI, FastCGI and the various module APIs of the various webservers ist the way to go. WSGi for Python is a good example of what I am thinking about: you write your code once and have e.g. four main application files, one for CGI, one for FastCGI, one as a stand allone server and the last one as an apache module. They instantiate the corresponding WSGI implementation and run your application using that implementation.
That API just provides a standardized way to access the HTTP request and set the response which is agnostic of the actually used server interface.
Christof
Christof Donat
>> I recently set up two wiki servers, one with MediaWiki (PHP)
>> and the other Java (anonymous to protect the guilty). The
>> former took a couple of minutes, the latter half a day messing
>> with the application ad Tomcat.
>
> The only Wiki I set up used perl. Which was a pain. But I'm
> not sure that that has anything to do with the language---if the
> Wiki is well implemented, you don't even see what language it is
> written in.
Yes. MediaWiki is mostly well designed. It is the software behind Wikipedia and yes, the user doesn't necessarily notice that it is written in PHP - the admin does of course.
>> > (As someone else pointed out, it suffers from the same
>> > problems as JSP---the "code" and the HTML are mixed in the
>> > same file.
>
>> Not in my shop it doesn't! There isn't any HTML: the PHP
>> pages generates it.
>
> But PHP contains HTML, doesn't it? From what I remember of the
> presentations I've seen of it, it *is* HTML, with embedded code.
Yes. Originally PHP was meant to look something like this:
------
<html>
<head><title><?php print $myTitle; ?></title></head>
<body>
<?php include('menu.php'); ?>
<h1>Here comes the Page content</h1>
<?php print $content; ?>
</body>
</html>
------
In well designed PHP applications you will see more code like this:
------
<?php
class PersonModel extends PersistantObject {
public function __construct($id = null) {
parent::__construct();
$this->tablename = 'person';
if( $id !== null ) $this->loadData($id);
}
}
?>
------
Another file will somehow contain a Template Engine. It will find the template to present the PersonModel on the requested Page and evaluate it.
Some Frameworks use PHP as their template language. We use XSLT and other even havve their own template language. For me the idear of using PHP as template language has proven to be too tempting for PHP developers to keep up a high code quality in a medium sized team. We chose XSLT because we didn't whant to develop a template language and engine in PHP that is powerfull enough.
In the end for the developer this is not easier than creating a Java servlet that uses a template engine. For the admin PHP is a lot easier, because chances are, that the Webserver already has mod_php included or at least makes it easy to configure the CGI od FastCGI Implementation of PHP.
Christof
James Kanze
> >> But PHP contains HTML, doesn't it? From what I remember of
> >> the presentations I've seen of it, it *is* HTML, with
> >> embedded code.
> > Your are way off base there I'm afraid. My PHP is more lice
> > C++ or Java code than anything else.
> In a way he is correct. PHP originally was meant to be liek
> that. It originally was meant to be little more than server
> side includes. Nowadays it has grown up, but still keeps some
> flaws from the early days. One of those is that in modern PHP
> applications all files start with "<?php" and end with "?>".
That explains my misunderstanding. My last contact with PHP was
quite some years ago, six or seven, at least, when my son was
interested in it. The books he has do present PHP as HTML with
something embedded, but they were all purchaced back then. (And
the collegues working on web pages haven't used PHP---just Java.
But then, at least in the case where I knew best what was being
done, the servers weren't Apache.)