"kris" <foo@bar.com> wrote in message news:4420779B.6020604@bar.com...
> It would be more interesting if this were entitled D vs C++. After all, isn't that (as Mattias indicated) the target "competition" ?

We've already had those threads in spades <g>.

Walter Bright wrote:
> "kris" <foo@bar.com> wrote in message news:4420779B.6020604@bar.com...
> 
>>It would be more interesting if this were entitled D vs C++. After all, isn't that (as Mattias indicated) the target "competition" ?
> 
> 
> We've already had those threads in spades <g>. 

True <g>

Did anyone mention DDL? Given that it would make D the only compiled language I've heard of with a runtime link-loader, that would seem to have some bearing?

Jari-Matti Mäkelä wrote:

>     catch(TinyEmergeProblem p) {
>       GentooBugzilla.report(p);
>       wait();
>       emerge(sync);
>       continue install;
>     }
>   }
>   // done, user happy
> }

Speaking of Gentoo, anyone know what happens with:
http://bugs.gentoo.org/show_bug.cgi?id=46806 ?

I don't really use Gentoo myself anymore (too "LFS")
but the ebuild is still working OK for version 150.

--anders

AFAIK, we were in the process or already a not-for-profit.  Honestly, I don't remember anymore.  That helps a lot.

There are two different terms here:
  - open source: this is a philosophical term.  It means source with as few restrictions to the end user as possible, except those necessary to keep it that way.
  - free software: software which is free.  It may also have less restrictions than non-free software.

Technically, the software I developed and supported was not open source.  We did not allow people to redistribute the code in full - only patches, etc. were allowed.  You were also required to display a copyright notice visibly.  But it was free software, and the source code was available.

Many different groups and organizations have different business models and strategies.  For example, Mozilla gets money from many large businesses interested in their software running on mobile devices, and similar.

The model I have described works best for good programmers.  If you can write something well, with a good concept, and support it well, you will prosper.  If someone else comes along and enhances your code, and supports it better than you, you've just been pwned.

We had software vendors who rebranded our software and sold it, or support for it.  They paid us for this, of course.  At first they didn't expect to, and so we told them we had a lawyer.  Situation solved. Seriously, if you do your job well, and you license it correctly, this won't be a problem.

I don't go quite as far as some with the philosophy of open source.  I believe it is great, amazing, and only logical for the code to be available.  For others to be able to compile it, patch it, change it.  I do not believe it is fair for them to provide it under their own name. I do not believe it is always fair for them to be able to redistribute it, even (although for smaller things it is.)

Free software scales a lot faster, in my experience.  You get people who care.  Who will throw tomatoes at this other company.  It's PR without a department for it.

For games, I'll agree with you.  Those usually just don't work.  Open source and free software just don't apply to everything.  But it's more about plot.  However, think of this:

You provide a framework with which people can make games (except, let's assume you actually make it so the games can be unique and of some quality, not something useless.)  This isn't far from what big game companies do, by the way.  Then, you open source/free this.  You provide support for it, services again.

For plot, for other things... open source is strange.  It's all about the code.

I didn't mention a lot of benefits it gives you.  Bugs, evangelism/free marketing department, peer support (which isn't great compared to yours, but takes slack off your back), third party plug-ins/extensions, reach, etc.

The only problem is, if you suck as a programmer, you're gonna have problems.  People can see it, people can see your glaring security holes, people will find your backdoors... etc.  But although I don't know much of you, considering you're interested in D I'll assume this won't be a problem.

All that said (yes, I know I'm long-winded), the computer my mouse is attached to almost always runs Windows.

However, all my servers are Linux or Unix-based (RHEL, FreeBSD, CentOS, etc.) and some consider my company to be in the "entertainment industry" (since we do websites for Fox, etc.)  But I suppose that's still business.

-[Unknown]


> 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...

Def wrote:
> 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... ;-)

In the dynamic compiler case, the VM/compiler could be written 20 years
later than the program itself, optimizing for a CPU/Arch that the developer
team had never heard of at the time the program was developed.
A static compiler could never do anything like that.
(given that source code is not available)

Java can be statically compiled with gcj (with some limitations).

I see no reason why a D compiler could not produce instructions for
a VM/dynamic compiler like .NET/Mono/JVM. In fact I think a
D compiler should have that as a codegen option, to give developers/
users as much flexibility as possible. It would also be a very good
temporary measure until a native compiler exists for all platforms.

Roald

Anders F Björklund wrote:
> Jari-Matti Mäkelä wrote:
> 
>>     catch(TinyEmergeProblem p) {
>>       GentooBugzilla.report(p);
>>       wait();
>>       emerge(sync);
>>       continue install;
>>     }
>>   }
>>   // done, user happy
>> }
> 
> Speaking of Gentoo, anyone know what happens with: http://bugs.gentoo.org/show_bug.cgi?id=46806 ?
> 
> I don't really use Gentoo myself anymore (too "LFS")
> but the ebuild is still working OK for version 150.

We still need the find a friendly developer to take care of the ebuild.

Gentoo is too "LFS"? Well, it's already possible to install Gentoo with a graphical installer, genkernel eliminates the need to hack with the kernel and package management / USE-flag editing do both have graphical frontends. The only problem is that there's no handy way to install up-to-date prebuilt binary packages compiled with custom use-flags and cflags. Debian/Slackware/Arch aren't really much "higher level". I'm using Arch myself on slower PCs since portage is currently a bit too "heavy".

-- 
Jari-Matti

kris wrote:
> Walter Bright wrote:
>> "kris" <foo@bar.com> wrote in message news:4420779B.6020604@bar.com...
>>
>>> It would be more interesting if this were entitled D vs C++. After all, isn't that (as Mattias indicated) the target "competition" ?
>>
>>
>> We've already had those threads in spades <g>. 
> 
> True <g>
> 
> Did anyone mention DDL? Given that it would make D the only compiled language I've heard of with a runtime link-loader, that would seem to have some bearing?

Just what I was thinking. Can DDL make compile once, run everywhere possible? (assuming that is an idiom we would like to support)

Jari-Matti Mäkelä wrote:

> We still need the find a friendly developer to take care of the ebuild.

A maintainer ? OK, the same problem as with Debian then... I understand.

> Gentoo is too "LFS"? Well, it's already possible to install Gentoo with
> a graphical installer, genkernel eliminates the need to hack with the
> kernel and package management / USE-flag editing do both have graphical
> frontends. The only problem is that there's no handy way to install
> up-to-date prebuilt binary packages compiled with custom use-flags and
> cflags. Debian/Slackware/Arch aren't really much "higher level". 

I like Gentoo a lot, it sort of reminds me of FreeBSD which I also like.
Found that doing a Gentoo install was well documented but very hands-on.

Just that marketing forces has me running distros originating from R.H.
And I still think that Ubuntu and Linspire are less scary for "users" ?

So while I still have Gentoo installed, I don't really use it much :-(
But maybe I should take another look at 2006.0, it looks much improved.

> I'm using Arch myself on slower PCs since portage is currently a bit
 > too "heavy".

Yeah, sounds like "typical Python" :-) But I have never seen Arch Linux.
Sounds like a nice inbetween of Slack and Gentoo, but I might be wrong ?

--anders

In article <dvpfa8$sq1$1@digitaldaemon.com>, Walter Bright says...
>
>
[...]
>
>With VMs, you have a lot more platforms to test, because you cannot control which version of which VM your customers will be using.

In theory, and in the general case, yes.
In practice I never had a JVM bug reported in 10 years. In any JVM. In the end
the bug was in my code.

Also, in my particular case I can control the VM, because it's me that put the VM in the machine I sell to customers.

>Back in the early days, Microsoft shipped a linker with MS-DOS. Great, I didn't have to write a linker for my compiler, just use the MS one everyone had. Unfortunately, MS shipped version after version of that linker. Some worked, some didn't, and soon the number of different versions grew into the scores. I had disks full of different versions, and started keeping logs of which worked and which didn't. Even worse, when customer X had a non-working linker, I couldn't ship him one that worked, as I had no license to. It was so bad it became clear that I had to come up with our own linker.
>
>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.

This is something I was afraid of, at the beginnin of my work with Java. In the
end, after 10 years, I can say it never applied to Java.
I don't exclude that in the Java VM design there's something that ease the
verification of the VM correctness, giving always high quality VMs. And I don't
use only Sun's JVM. The fact that you have to pass a lot of test by Sun before
you can use the word "Java" for your VM maybe means something.

>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.

Maybe there's one: the JIT compiler task is much like the work of a macro assembler than that of a HLL compiler.

>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.

In theory you are right.
In practice a VM makes the task more easy and lead to more robust results.
Prove me wrong with D ;-).

Ciao

---
http://www.mariottini.net/roberto/

Kyle Furlong wrote:
> kris wrote:
> 
>> Walter Bright wrote:
>>
>>> "kris" <foo@bar.com> wrote in message news:4420779B.6020604@bar.com...
>>>
>>>> It would be more interesting if this were entitled D vs C++. After all, isn't that (as Mattias indicated) the target "competition" ?
>>>
>>>
>>>
>>> We've already had those threads in spades <g>. 
>>
>>
>> True <g>
>>
>> Did anyone mention DDL? Given that it would make D the only compiled language I've heard of with a runtime link-loader, that would seem to have some bearing?
> 
> 
> Just what I was thinking. Can DDL make compile once, run everywhere possible? (assuming that is an idiom we would like to support)

No, DDL does no such thing. Nor is it intended to (instead, it's deliberately machine-architecture specific).

Functionality exposed by DDL is roughly the equivalent of a Java class-loader, but for pre-optimized native object-code exposing a D callable interface. This is a highly unusual attribute for native code runtime, and is (in my opinion) one of the most important assets for the D language. DDL also has the potential to support full reflection.