Lucas Goss wrote:

>> That's with a dynamic lib for C++, right ?
> 
> Of course. But why would you statically link the whole stdc++ lib :)

Well, it did that on Mac OS X 10.3 (it doesn't on Mac OS X 10.4)

/usr/lib/gcc/darwin/3.3/libstdc++.a

Just for a comparison...

--anders

Dave wrote:
> How do you like Ubuntu, say, compared to Fedora Core 4 if you've used that?
> 
> (I'm past the stage where I want to compile kernel modules, etc. to install a
> *nix system, so how is the setup routine?).

Setup for Ubuntu is pretty easy (and the new dapper is nice). Compared to Fedora 4 I like it better just because I've always had a problem their RPM and updates (somehow I could always break them), but maybe they've got better? Ubuntu is nice though.

I'm kinda torn though because I don't like the whole 6 month release thing (which is why I run Ubuntu alphas). So Gentoo would be nice. But at the same time I don't want to spend a lot of time compiling, well unless it's my programs.

Walter Bright wrote:
> 
> Essentially, I learned that if you are supporting an application, and you need to be in control of your support costs, you have to be able to control the generation of the executable. That's impossible with a VM.

Very interesting point.

> But also, really, what is the difference between relying on a JIT compiler for each platform, and a native compiler for each platform? Why should the JIT compiler be more reliable? There's no technical reason it should be. If the language has portable semantics, and the compilers implement those semantics correctly, it should be write once, run everywhere. There's no technical reason a VM is required to make that happen. 

There is no difference :-)  The only reason a VM was attractive is because it allowed applets to run in a sandbox.  And since Java applets failed as a technology, there's no real reason to consider default VM support as an advantage.  Others are also quick to point out that there's no reason C++ or D couldn't run on a VM as well, as .NET has proven.


Sean

In article <dvpces$oti$1@digitaldaemon.com>, Lucas Goss says...
>
>Unknown W. Brackets wrote:
>> Free Software uses a different business model - I should know, I used to be quite involved with it.  The idea is to make money from the service, not from the product.
>> 
>>> Interesing point. I think the "Free Software" model is flawed.
>>>
>
>I somewhat agree with both points. I see the value of open source and how it can work as a service, but it doesn't always seem to work this way. Maybe someone can clear this up for me... or maybe I'll just muddy the waters. Does it work in these cases?
>
>This one I'm not sure about, but what if I make an innovative new software product and release it as open source. Some business comes along and likes my product, so they have their developers (who are paid) to make enhancements to my original. Then they decide to support clients who use this software (as they bundle the software with their product). And since this company is bigger in the market, most people that need the support go to this company. How do I make money from that?
>
>Secondly... games! This is where open source doesn't fit in my opinion. I make a game and release it, who will pay for support. Users will think it's a bad game if it doesn't work or if it's buggy. And gamers won't pay to add things (unless it's maybe like $5), and instead choose to try to do Mod's.
>
>So it seems...
>Business/Education = Linux
>Home/Entertainment = Mac/Windows
>
>Hmm...

Fair points. Suppose a group of developers produced a very slick/functional Office suite which supported WordML and the other XML Office formats under GPL. Without the backing of Sun(OpenOffice) how would the developers get paid. The linux distributions could include it without paying the developers. This mainly applies to slick desktop software. Not enough people may be willing to pay for a software support service. Personally i would be happy with a halfway house. The developers charge a reasonable amount (eg an iLife-ish $79) and release as much source as possible. And individual developers who like the app can submit patches and new functionality etc. And make it free for educational use! A kind of halfway house. For me its more about seeing the source and having confidence in the source than software being free.

Jari-Matti Mäkelä wrote:

>>Of course, then you also need to make sure that the receiving end of
>>those programs have the correct version of runtime library installed,
>>something that is a Huge Pain for distributing C++ programs on Linux...
> 
> void fix() {
>   if (user.experiencing == HugePainWithLibraries) {
>     auto GentooLinux = download(www.gentoo.org/stage3);
>     try {
>       user.install(GentooLinux);
>     }

Well, maybe I was overstating the problem. It's easy enough to fix
the dependencies on libstdc++.so.5 or libstdc++.2.9 or whatever, if
you have a Linux distribution with a reasonable ports/package manager.
(all of Gentoo and Ubuntu and Fedora qualifies, as far as I'm concerned)

--anders

> Interesing point. I think the "Free Software" model is flawed. Programmers need to get paid. Apple with OSX have shown that people are willing to pay for a decent integrated experience - at a reasonable price. eg iLife and iWork are $79. A decent biz model would be the os(kernel and desktop) is free with the app suites paid for. With as much as the source code as possible available for viewing to keep the techies happy. Quite franky i find it reassuring that the company that makes things i use has a biz model - and can survive in the longterm.

Well, there is many business models for free software which one do you think is flawed ??

1) Free software don't have to be a business it can just be a hobby like tennis, gardening or chess.

2) Make a open source library and make it dual licence
Where one licence is GPL and the other is commercial.
So, that every one writing a close source app. using the
library should buy a commercial license or release
there app. open source.

3) Make a non-profit organisation.
Your develop open source apps. and let
clients donate money for there favorite extension.
You get paid and they get there open source extension and a tax writeof.

4) Get money from real estate investments write open source software for fun and education.

That is just some of the ideas that comes to mind.

In article <dvpfa8$sq1$1@digitaldaemon.com>, Walter Bright says...

>But also, really, what is the difference between relying on a JIT compiler for each platform, and a native compiler for each platform? Why should the JIT compiler be more reliable? There's no technical reason it should be. If the language has portable semantics, and the compilers implement those semantics correctly, it should be write once, run everywhere. There's no technical reason a VM is required to make that happen.

For me the biggest difference is that a VM makes "sort of" cross-compiling
possible. As a user of Win32 & beginning/experimenting with Linux on an x86
machine, I simply can't afford to buy a Mac just to support MacOS. Still, I
can't test a Java app on a Mac - I can only hope that it works reasonably well.
But GDC for Mac won't help me at all unless I give the sources to someone with a
Mac. Of course, this is not D's fault. One could blame Apple for not releasing
their libraries free of charge or at low cost for cross-compiling from non-Mac
machines. It's a pity there's no Mac equivalent to MinGW available.
Anyway, with Intel Mac's I might be able to boot Win/Mac/Linux in the future.
:-)

Def

Walter Bright wrote:
> I'm no expert on Java programming, but I get this question a lot: "What compelling reason does D have that would entice a Java programmer to switch to D?"
> 
> I know several of you have come to D from Java, and are expert Java programmers, so you folks' reasons would be very valuable. 
> 
> 

I agree with Andrew that D and Java belong in separate categories. Java is intended for managed environments where the guts of the runtime are not exposed to the programmer. The object model is simple, the dynamic linking mechanism with class loaders is very powerful, and dynamic compilation achieves performance that is acceptable for many applications.

If you look at just the language, it would be very easy to say D is competitive or superior. But if you look at the whole application life-cycle from specification, development, deployment, management, maintenance, evolution, etc., and the tools that support you in this cycle; D has quite a ways to go -- not so much the language, but the ecosystem around it.

I do believe that, for certain applications, a dynamic compiler will at some point do a better job of optimizing code than a static compiler. Why?

1. A dynamic compiler knows about the architecture of the machine, e.g. cache sizes; and the profile of the running application, e.g. I/O boundedness. The data path is likely to be the main bottleneck in coming years.

2. Languages like Java have the advantage that they don't expose the actual layout of objects in memory to the programmer. Any language with pointers has a disadvantage in the context of dynamic optimization.

3. Multicore/multithreaded systems will provide for enough computational bandwidth for dynamic compilers and GCs to run in parallel with the programs they operate on. Performance degradation due to compilation at runtime will become a moot point on server systems very soon.

4. The ability to run multiple applications in the same runtime context; i.e. sharing the heap, the GC and the dynamically compiled bits of code; will reduce the overhead (which today is clearly a big issue for certain applications). Such a feature will be more easily implemented for a language like Java than D.

Scalability. Java scales quite well to very large projects. Applications with millions of lines of code built by hundreds of developers (with different skill sets) are not out of the ordinary. If D can achieve this scalability (with the right tools, of course) then it will have come a long way. C/C++ do not scale this well primarily because they are system-dependent, have weaker semantics, limited library functionality, expose memory to the programmer and don't support garbage collection. Ownership patterns in large code bases are lost on the masses, and programming in the large becomes increasingly a breeding ground for dictatorships. One might argue Java is a mediocre programming language, but most programmers are mediocre, so less is more...

Mobility. If you were a Comcast or a Vodafone, would you like to manage native downloadable applications for each and every gadget architecture that will appear on the planet. The ARM Cortex A8 architecture has this Jazelle RTC technology which will help byte-code apps scale on mobile, embedded systems. The infrastructure to manage native binaries is too expensive (not to mention fragile) and the performance degradation for byte code apps will be addressed (in hardware, if necessary).

The choice for me will be to use D instead of C or C++ when I need to program at the system level -- when it's ready. I certainly think D is on the right track, so keep up the good work. IMHO, Java/C# are on a different track.

Matthias

In article <dvpq5q$1be1$1@digitaldaemon.com>, Matthias Spycher says...

>1. A dynamic compiler knows about the architecture of the machine, e.g. cache sizes; and the profile of the running application, e.g. I/O boundedness. The data path is likely to be the main bottleneck in coming years.

As I see it, there's no technical reason why a static compiler couldn't do the
same with run-time checks for different CPU versions, cache sizes, current
system load, etc. and invoking different code versions accordingly. To prevent
bloat such alternative code sections could even be loaded dynamically into RAM.
It's just that it is a whole lot of work to implement such a compiler.
But I'm sure Walter is already working on this... ;-)

Def

Matthias Spycher wrote:
> Walter Bright wrote:
> 
>> I'm no expert on Java programming, but I get this question a lot: "What compelling reason does D have that would entice a Java programmer to switch to D?"
>>
>> I know several of you have come to D from Java, and are expert Java programmers, so you folks' reasons would be very valuable.
>>
> 
> I agree with Andrew that D and Java belong in separate categories. Java is intended for managed environments where the guts of the runtime are not exposed to the programmer. The object model is simple, the dynamic linking mechanism with class loaders is very powerful, and dynamic compilation achieves performance that is acceptable for many applications.
> 
> If you look at just the language, it would be very easy to say D is competitive or superior. But if you look at the whole application life-cycle from specification, development, deployment, management, maintenance, evolution, etc., and the tools that support you in this cycle; D has quite a ways to go -- not so much the language, but the ecosystem around it.
> 
> I do believe that, for certain applications, a dynamic compiler will at some point do a better job of optimizing code than a static compiler. Why?
> 
> 1. A dynamic compiler knows about the architecture of the machine, e.g. cache sizes; and the profile of the running application, e.g. I/O boundedness. The data path is likely to be the main bottleneck in coming years.
> 
> 2. Languages like Java have the advantage that they don't expose the actual layout of objects in memory to the programmer. Any language with pointers has a disadvantage in the context of dynamic optimization.
> 
> 3. Multicore/multithreaded systems will provide for enough computational bandwidth for dynamic compilers and GCs to run in parallel with the programs they operate on. Performance degradation due to compilation at runtime will become a moot point on server systems very soon.
> 
> 4. The ability to run multiple applications in the same runtime context; i.e. sharing the heap, the GC and the dynamically compiled bits of code; will reduce the overhead (which today is clearly a big issue for certain applications). Such a feature will be more easily implemented for a language like Java than D.
> 
> Scalability. Java scales quite well to very large projects. Applications with millions of lines of code built by hundreds of developers (with different skill sets) are not out of the ordinary. If D can achieve this scalability (with the right tools, of course) then it will have come a long way. C/C++ do not scale this well primarily because they are system-dependent, have weaker semantics, limited library functionality, expose memory to the programmer and don't support garbage collection. Ownership patterns in large code bases are lost on the masses, and programming in the large becomes increasingly a breeding ground for dictatorships. One might argue Java is a mediocre programming language, but most programmers are mediocre, so less is more...
> 
> Mobility. If you were a Comcast or a Vodafone, would you like to manage native downloadable applications for each and every gadget architecture that will appear on the planet. The ARM Cortex A8 architecture has this Jazelle RTC technology which will help byte-code apps scale on mobile, embedded systems. The infrastructure to manage native binaries is too expensive (not to mention fragile) and the performance degradation for byte code apps will be addressed (in hardware, if necessary).
> 
> The choice for me will be to use D instead of C or C++ when I need to program at the system level -- when it's ready. I certainly think D is on the right track, so keep up the good work. IMHO, Java/C# are on a different track.
> 
> Matthias


Amen; on every point.

What seems to be missing in this topic is the notion of selecting the right tool for the job. One could endlessly debate the overlap and distinction between D and Java, but in the end it's just horses for courses all over again. Heck ~ one might argue that D /is/ statically compiled Java, with the addition of pointers and structs, yet without the library support :-p

It would be more interesting if this were entitled D vs C++. After all, isn't that (as Mattias indicated) the target "competition" ?