Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25558 > unrolled thread

Re: Java vs C++

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Java vs C++ Owen Jacobson <angrybaldguy@gmail.com> - 2011-02-05 10:42 -0500
    Re: Java vs C++ Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-08 09:22 +1300
      Re: Java vs C++ Arne Vajhøj <arne@vajhoej.dk> - 2011-02-07 19:57 -0500
        Re: Java vs C++ Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-08 16:06 +1300
    Re: Java vs C++ Arne Vajhøj <arne@vajhoej.dk> - 2011-02-07 19:56 -0500
      Re: Java vs C++ Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-08 16:06 +1300
        Re: Java vs C++ Arne Vajhøj <arne@vajhoej.dk> - 2011-02-07 22:17 -0500
        Re: Java vs C++ Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-02-08 19:46 -0400
    Re: Java vs C++ Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-07 12:23 +1300
      Re: Java vs C++ Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-02-07 07:37 -0500
      Re: Java vs C++ Arne Vajhøj <arne@vajhoej.dk> - 2011-02-06 20:08 -0500
        Re: Java vs C++ Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-07 19:06 +1300
    Re: Java vs C++ Helium Balloon <hb.3459s._jsf3k@goo.abvg> - 2011-02-06 19:55 -0500
    Re: Java vs C++ Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-07 13:29 +1300
      Re: Java vs C++ Arne Vajhøj <arne@vajhoej.dk> - 2011-02-06 20:47 -0500
      Re: Java vs C++ Arne Vajhøj <arne@vajhoej.dk> - 2011-02-06 20:38 -0500
    Re: Java vs C++ Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-02-06 09:34 -0400

#25558 — Re: Java vs C++

On 2011-02-05 06:15:07 -0500, Lawrence D'Oliveiro said:

> This PDF copy of “The Java Language Specification”, 3rd Edition, that I’m
> currently reading, has 684 pages. By comparison, the paper copy of “The C++
> Standard” on my bookshelf has 782 numbered pages. As you can see, Java is no
> longer that far off C++ in complexity.

This is an extremely dubious measure of complexity. The Common Lisp 
specification is over a thousand pages long in some editions*, but Lisp 
is generally considered a much simpler language than either C++ or Java.

You've posted extensively about things you see in Java that you don't 
like, and there's a strong "C++ is better" undercurrent to your posts. 
While I disagree with the undercurrent, I will defend to the death your 
right to program in C++ instead. Just, please, go away.

-o

* <http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html>, which 
predates the ANSI spec.

[toc] | [next] | [standalone]

#25598

In message <iiop28$8jj$1@news.eternal-september.org>, Joshua Cranmer wrote:

> On 02/07/2011 01:06 AM, Lawrence D'Oliveiro wrote:
>
>> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>> And the C spec leaves a lot of things to implementations.
>>
>> Not too much that you can’t write portable code in it.
> 
> Writing portable code in C pretty much requires you to do hefty
> compatibility layers.

Not really. Sticking to standard POSIX types like size_t, time_t etc gets 
you a lot of the way there.

> Many projects use typedefs to get proper-sized int variables (you can't
> use stdint.h, as MSVC doesn't implement it, as of MSVC 9.0).

How sad for MSVC...

[toc] | [prev] | [next] | [standalone]

#25929

On 07-02-2011 15:22, Lawrence D'Oliveiro wrote:
> In message<iiop28$8jj$1@news.eternal-september.org>, Joshua Cranmer wrote:
>> On 02/07/2011 01:06 AM, Lawrence D'Oliveiro wrote:
>>> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>> And the C spec leaves a lot of things to implementations.
>>>
>>> Not too much that you can’t write portable code in it.
>>
>> Writing portable code in C pretty much requires you to do hefty
>> compatibility layers.
>
> Not really. Sticking to standard POSIX types like size_t, time_t etc gets
> you a lot of the way there.

POSIX does not cover all aspects.

And not all platforms are POSIX compliant.

Arne

[toc] | [prev] | [next] | [standalone]

#26077

In message <4d5094f2$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 07-02-2011 15:22, Lawrence D'Oliveiro wrote:
>
>> In message<iiop28$8jj$1@news.eternal-september.org>, Joshua Cranmer
>> wrote:
>>>
>>> On 02/07/2011 01:06 AM, Lawrence D'Oliveiro wrote:
>>>
>>>> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj
>>>> wrote:
>>>>> And the C spec leaves a lot of things to implementations.
>>>>
>>>> Not too much that you can’t write portable code in it.
>>>
>>> Writing portable code in C pretty much requires you to do hefty
>>> compatibility layers.
>>
>> Not really. Sticking to standard POSIX types like size_t, time_t etc gets
>> you a lot of the way there.
> 
> POSIX does not cover all aspects.

Well, you need tools like autoconf as well to handle the more complicated 
cases.

> And not all platforms are POSIX compliant.

All the ones worth using are.

[toc] | [prev] | [next] | [standalone]

#25622

On 07-02-2011 01:06, Lawrence D'Oliveiro wrote:
> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 18:23, Lawrence D'Oliveiro wrote:
>>> For comparison, I have a couple of draft C99 specs floating around. They
>>> total 550 pages, until you realize most of that is section 7, the
>>> standard library. Leave that out, and you end up with 163 pages.
>>
>> I am not sure that comparing a language reference with a standard
>> spec gives much meaning.
>
> That’s right, I forgot there is no “standard spec” for Java, it is simply
> what Sunacle says it is.

What do you think the S in JLS stands for?

>> And the C spec leaves a lot of things to implementations.
>
> Not too much that you can’t write portable code in it.

Real C apps that will run predictable on any platform is
pretty rare.

Real C apps that support a wide range of platforms via
ifdef's are common.

C apps that the programmer think is portable but is not
are also common.

Arne

[toc] | [prev] | [next] | [standalone]

#25741

In message <4d50949a$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 07-02-2011 01:06, Lawrence D'Oliveiro wrote:
>
>> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>> On 06-02-2011 18:23, Lawrence D'Oliveiro wrote:
>>>>
>>>> For comparison, I have a couple of draft C99 specs floating around.
>>>> They total 550 pages, until you realize most of that is section 7, the
>>>> standard library. Leave that out, and you end up with 163 pages.
>>>
>>> I am not sure that comparing a language reference with a standard
>>> spec gives much meaning.
>>
>> That’s right, I forgot there is no “standard spec” for Java, it is simply
>> what Sunacle says it is.
> 
> What do you think the S in JLS stands for?

Not “standard”.

>>> And the C spec leaves a lot of things to implementations.
>>
>> Not too much that you can’t write portable code in it.
> 
> Real C apps that will run predictable on any platform is
> pretty rare.

Really?? We have them coming out our ears. I have thousands of them 
installed on my system alone. Let’s see, the Linux kernel, 15 million lines 
of source code, almost entirely in C, portable across about two dozen 
different major processor architectures. GCC, Apache, Python, Blender (a 
million lines of C, plus about 220 thousand lines of C++), Gimp ... the list 
goes on and on.

[toc] | [prev] | [next] | [standalone]

#25797

On 07-02-2011 22:06, Lawrence D'Oliveiro wrote:
> In message<4d50949a$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
>> On 07-02-2011 01:06, Lawrence D'Oliveiro wrote:
>>
>>> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>
>>>> On 06-02-2011 18:23, Lawrence D'Oliveiro wrote:
>>>>>
>>>>> For comparison, I have a couple of draft C99 specs floating around.
>>>>> They total 550 pages, until you realize most of that is section 7, the
>>>>> standard library. Leave that out, and you end up with 163 pages.
>>>>
>>>> I am not sure that comparing a language reference with a standard
>>>> spec gives much meaning.
>>>
>>> That’s right, I forgot there is no “standard spec” for Java, it is simply
>>> what Sunacle says it is.
>>
>> What do you think the S in JLS stands for?
>
> Not “standard”.

specification

It is the specification for Java.

>>>> And the C spec leaves a lot of things to implementations.
>>>
>>> Not too much that you can’t write portable code in it.
>>
>> Real C apps that will run predictable on any platform is
>> pretty rare.
>
> Really?? We have them coming out our ears. I have thousands of them
> installed on my system alone. Let’s see, the Linux kernel, 15 million lines
> of source code, almost entirely in C, portable across about two dozen
> different major processor architectures. GCC, Apache, Python, Blender (a
> million lines of C, plus about 220 thousand lines of C++), Gimp ... the list
> goes on and on.

No. I don't think many of those apps are portable C. Most likely
none of them are. Those apps are just ported to a number of platforms.
Ported by someone adding #ifdef sections etc. to make them work
on a specific platform.

Arne

[toc] | [prev] | [next] | [standalone]

#26178

On 11-02-07 11:06 PM, Lawrence D'Oliveiro wrote:
> In message<4d50949a$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
[ SNIP ]

>> Real C apps that will run predictable on any platform is
>> pretty rare.
>
> Really?? We have them coming out our ears. I have thousands of them
> installed on my system alone. Let’s see, the Linux kernel, 15 million lines
> of source code, almost entirely in C, portable across about two dozen
> different major processor architectures. GCC, Apache, Python, Blender (a
> million lines of C, plus about 220 thousand lines of C++), Gimp ... the list
> goes on and on.
>
You've got a very optimistic definition of "portable" happening there. 
It may come as a surprise to you, but all sorts of #ifdefs and 
platform-specific configure scripts and makefiles don't mean that you've 
got portable code - all of that is a response to the fact that you've 
got _non-portable_ code.

AHS

-- 
We must recognize the chief characteristic of the modern era - a 
permanent state of what I call violent peace.
-- James D. Watkins

[toc] | [prev] | [next] | [standalone]

#25626

In message <4d4e25e8@news.x-privat.org>, Ken Wesson wrote:

> In that flamewar, someone estimated the size of Clojure's documentation
> by browsing its website and counting pagedown keypresses needed to reach
> the bottom of each web page.

Funny, I did the same thing for Python, just for comparison 
<http://docs.python.org/py3k/reference/>. The figure I came up with for that 
Language Reference was 92 pages. To be fair, I suppose you should include 
the first 6 chapters of rhe Library Reference 
<http://docs.python.org/py3k/library/>, which is another 69 pages, for a 
total of 161.

For comparison, I have a couple of draft C99 specs floating around. They 
total 550 pages, until you realize most of that is section 7, the standard 
library. Leave that out, and you end up with 163 pages.

[toc] | [prev] | [next] | [standalone]

#25814

On 02/07/2011 01:06 AM, Lawrence D'Oliveiro wrote:
> In message<4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> And the C spec leaves a lot of things to implementations.
>
> Not too much that you can’t write portable code in it.

Writing portable code in C pretty much requires you to do hefty 
compatibility layers. Many projects use typedefs to get proper-sized int 
variables (you can't use stdint.h, as MSVC doesn't implement it, as of 
MSVC 9.0). Anything more complex than basic I/O requires the use of 
other, largely incompatible layers, for common things like 
multithreading, asynchronous I/O, network I/O, etc. Let's not even get 
into basic GUIs.

And even then, a careful reading of the C standard would reveal that it 
gives very few absolute requirements of stuff, so that I could make 
size_t be an 800-bit integer and still follow the standard, as well as 
probably breaking everyone's so-called "portable C" code.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#26015

On 06-02-2011 18:23, Lawrence D'Oliveiro wrote:
> In message<4d4e25e8@news.x-privat.org>, Ken Wesson wrote:
>> In that flamewar, someone estimated the size of Clojure's documentation
>> by browsing its website and counting pagedown keypresses needed to reach
>> the bottom of each web page.
>
> Funny, I did the same thing for Python, just for comparison
> <http://docs.python.org/py3k/reference/>. The figure I came up with for that
> Language Reference was 92 pages. To be fair, I suppose you should include
> the first 6 chapters of rhe Library Reference
> <http://docs.python.org/py3k/library/>, which is another 69 pages, for a
> total of 161.

Either Python is a simple language or the language reference is not
very detailed.

> For comparison, I have a couple of draft C99 specs floating around. They
> total 550 pages, until you realize most of that is section 7, the standard
> library. Leave that out, and you end up with 163 pages.

I am not sure that comparing a language reference with a standard
spec gives much meaning.

And the C spec leaves a lot of things to implementations.

Arne

[toc] | [prev] | [next] | [standalone]

#26155

In message <4d4f45fc$0$23760$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 18:23, Lawrence D'Oliveiro wrote:
>
>> In message<4d4e25e8@news.x-privat.org>, Ken Wesson wrote:
>>
>>> In that flamewar, someone estimated the size of Clojure's documentation
>>> by browsing its website and counting pagedown keypresses needed to reach
>>> the bottom of each web page.
>>
>> Funny, I did the same thing for Python, just for comparison
>> <http://docs.python.org/py3k/reference/>. The figure I came up with for
>> that Language Reference was 92 pages. To be fair, I suppose you should
>> include the first 6 chapters of rhe Library Reference
>> <http://docs.python.org/py3k/library/>, which is another 69 pages, for a
>> total of 161.
> 
> Either Python is a simple language or the language reference is not
> very detailed.

Go on, study the references for yourself, even get some experience with the 
language, then let us know your verdict.

>> For comparison, I have a couple of draft C99 specs floating around. They
>> total 550 pages, until you realize most of that is section 7, the
>> standard library. Leave that out, and you end up with 163 pages.
> 
> I am not sure that comparing a language reference with a standard
> spec gives much meaning.

That’s right, I forgot there is no “standard spec” for Java, it is simply 
what Sunacle says it is.

> And the C spec leaves a lot of things to implementations.

Not too much that you can’t write portable code in it.

[toc] | [prev] | [next] | [standalone]

#25630

On 06/02/2011 7:29 PM, Lawrence D'Oliveiro wrote:
> Except, of course, for Android. Which is why I’m here.

Shouldn't you be off watching football, or something?

[toc] | [prev] | [next] | [standalone]

#25731

In message <4d4e25e8@news.x-privat.org>, Ken Wesson wrote:

> Java is very widely used for network and business applications, and web
> apps, these days ...

I was trying to make sense of where you were coming from with your 
predictions, and then I realized—you’re primarily talking about corporate 
development. Because that’s just about the only place languages like Java 
and C#/Dotnet get much use. Very few mass-market or open-source apps are 
written in those languages, for example.

Except, of course, for Android. Which is why I’m here.

[toc] | [prev] | [next] | [standalone]

#26078

On 06-02-2011 20:38, Arne Vajhøj wrote:
> On 06-02-2011 19:29, Lawrence D'Oliveiro wrote:
>> In message<4d4e25e8@news.x-privat.org>, Ken Wesson wrote:
>>> Java is very widely used for network and business applications, and web
>>> apps, these days ...
>>
>> I was trying to make sense of where you were coming from with your
>> predictions, and then I realized—you’re primarily talking about corporate
>> development. Because that’s just about the only place languages like Java
>> and C#/Dotnet get much use. Very few mass-market or open-source apps are
>> written in those languages, for example.
>
> Which is just plain wrong.
>
> Java and C# are both very popular for open source projects.
>
> Sometimes statistics are done for SF projects.
>
> The last I can find for December 2007 has Java as #1 and
> C# as #7 and VB.NET as #14.
>
> So Java and .NET are very much used for open source.
>
> Desktop market is still dominated by native apps. It may
> change someday if MS starts to rewrite MFC stuff in .NET.

And in case somebody wants to check the list:
   http://www.c2.com/cgi/wiki?ProgrammingLanguagePopularity

Arne

[toc] | [prev] | [next] | [standalone]

#26154

On 06-02-2011 19:29, Lawrence D'Oliveiro wrote:
> In message<4d4e25e8@news.x-privat.org>, Ken Wesson wrote:
>> Java is very widely used for network and business applications, and web
>> apps, these days ...
>
> I was trying to make sense of where you were coming from with your
> predictions, and then I realized—you’re primarily talking about corporate
> development. Because that’s just about the only place languages like Java
> and C#/Dotnet get much use. Very few mass-market or open-source apps are
> written in those languages, for example.

Which is just plain wrong.

Java and C# are both very popular for open source projects.

Sometimes statistics are done for SF projects.

The last I can find for December 2007 has Java as #1 and
C# as #7 and VB.NET as #14.

So Java and .NET are very much used for open source.

Desktop market is still dominated by native apps. It may
change someday if MS starts to rewrite MFC stuff in .NET.

Arne

[toc] | [prev] | [next] | [standalone]

#25920

On 11-02-06 12:39 AM, Ken Wesson wrote:
[ SNIP good overview ]

> In reality, Java's static types and checked exceptions will throw a fair
> amount of syntactic salt into this, barring a hefty (and again Haskell-
> like) infusion of type inference. Java could lose out in the long run to
> JVM hosted languages designed to be functional from the ground up. Of
> these the frontrunners seem to be Clojure and Scala, with Scala's non-
> Lispy syntax giving it an edge in familiarity (and especially with
> management) and Clojure's macros (and consequent ability to reify
> boilerplate patterns into things you can name and call and not
> reimplement over and over again) giving it an edge in expressivity.
>
> Both are gaining traction even with management types, especially when
> stuff coded in them can be bundled into jars and deployed on application
> servers in a manner identical to deploying Java code. It doesn't look or
> feel any different to management than deploying Java; the coders are
> pushing different symbols around in their text editors and IDEs but
> they're still using IDEA or NetBeans or Eclipse and still producing .jar
> files that behave the same way when put on the server. So if the coders
> are typing stuff that looks incomprehensible in a different way than it
> did before, and seem a bit happier, and are suddenly making their
> deadlines instead of missing them, and nothing has stopped working or
> started working differently at a level management notices, management
> won't rock the boat. At most they'll want to be assuaged about
> intellectual property rights, mainly that a) the company still owns its
> code and b) they aren't going to get sued for using this stuff. Both
> languages in question have, if anything, less stringent license
> requirements than Java itself.
[ SNIP ]

I'm currently pushing Scala (nothing against Clojure really, I am just 
considerably more familiar with Scala) quietly, in-house and also on 
some client projects, with similar thinking in mind. It _is_ a fact that 
management truly doesn't care that this chunk of opcodes was originally 
Java source, and that other chunk of opcodes was originally Scala 
source. If a project development team can incrementally introduce user 
libraries into a Java EE environment that happen to be written in Scala, 
and they are developed faster and we end up with more reliable code, 
nobody is going to complain.

AHS
-- 
We must recognize the chief characteristic of the modern era - a 
permanent state of what I call violent peace.
-- James D. Watkins

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web