March 03, 2006
In article <du8l4c$v6n$1@digitaldaemon.com>, Kevin Bealer says...
>
>[snip]
>Let me propose some general hype; these will look a little like hyperbole, but
>most of them are more or less true (or could be without *too* much pain):
>[snip]

I'd add:

7. D has all (well, most of) the power of C++ but with a grammar that is sane enough to allow decent tools. The state of C++ tooling is abysmal, because it's so pathologically awful to parse. Going back to C++ development after working in a refactoring environment (e.g. VS+ReSharper for C#, or Eclipse/IDEA for Java) feels like being dragged back to the Stone Age; productivity drops through the floor.

cheers
Mike


March 03, 2006
I completely agree with Andrew's points. Interspersed some comments below:


Andrew Fedoniouk wrote:
> 
> 4. Execution model: VM + real GC. Safe sandbox. Pure byte code cannot GPF
> in principle.

Concurrency and the memory model should be mentioned. Final, volatile and object initialization are well defined in a concurrent setting (as of J2SE 5).

> 
> 5. Extremely simple Java Native Interface mechanism - bridge to native code for
> mission crititcal pieces.

Minimal exposure, even to JNI programmers, of the VM's internals. Verbose, ugly? Maybe, but works as intended.

> 
> 6. Extremely simple bytecode system. I know around 12 working implementations
> of Java VM.

Mobility of state and behavior -- this was one of the original requirements for the Oak language and runtime when it was first implemented. It is interesting to note that the platform was initially designed for PDAs and other mobile gadgets with wireless connectivity. The internet, browsers and applets came much later; and "accidentally" turned out to be the most effective vehicle for marketing the system. Leave out the byte code and we might instead be programming in Dylan or some other "exotic" language.

> 
> 7. ClassLoader as an entity. Killer thing, IMO.
> 
Should we mention that a dynamic compiler will optimize (e.g. inline) across units that are loaded at runtime? For server-side programming, even D will be challenged on this front.

> 8. Reflection as part of runtime.
> 
> ------------------
> Having said that Java has problems of course. It is good for some set of tasks.
> It is not an universal language.
> 
> But it is damned stable. Last 7 years or so it is working as it is.
> 
> 

Agreed. D is a great step forward for C and C++ programmers, as these languages compete in the same application domains. Java and C# will continue to dominate in managed environments. IMHO, Scala is the kind of language that might challenge Java/C# in the long run.

Matthias
March 03, 2006
In article <dua2qh$ong$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Kevin Bealer wrote:
>
>>>I just don't see why GDC would have to be bundled with the rest of the GNU Compiler Collection in order for it to be used everywhere ?
>[...]
>> There is no technical reason.  But go to your boss and tell him you want to use a new language.  He'll be sceptical...  Now tell him you need to build your own patched version GCC to get a compiler for it...
>
>But one can still build binary packages for it (GDC), without it first being a FSF project ? The only caveat being that if your system compiler is too far away from what GDC works with, you'll need *another* GCC too. (which could still be offered as an alternative installation, though...)

Like I said .. no *technical* reason, per se -- you could do this.  But asking your boss to approve a toolchain that you patch together yourself, is going to be like telling him that he doesn't need to *buy* a car, he can just go to the junkyard and get a nearly complete one running.  He could, but he won't.

If your boss does programming or you have a lot of autonomy, you may have a little flexibility here.  But it will never make it in a "Java shop" programming environment if you have to spend several hours fixing rejected patches to GCC every time the next revision of GDC or GCC is desired.

It doesn't have to be part of the GCC found on GNU's FTP site, but you need to at least be able to install the compiler and libphobos from "RPMs" or build them from one or two tar files.

>I don't necessarily think it's a bad idea. Just wonder why it has to be. I'd worry more about the language spec not being open, or even finished.
>
>[...]
>> It may never have bytecode, but users don't actually care about that if compile/link is fast -- which seems to be true for dmd but not necessarily gdc. The dmd compile feels faster than just starting the Java interpreter.  I haven't benchmarked it though.
>
>Part of this speed comes from optlink, I think ? (when it doesn't crash) At least I've found the GCC linking to be slower, doubly so for C++...
>
>--anders

I don't know - I usually work in Linux, and there it looks like dmd uses gcc to do the link. There is an option that lets you see the commands its running.

Kevin


March 03, 2006
Kevin Bealer wrote:

> It doesn't have to be part of the GCC found on GNU's FTP site, but you need to
> at least be able to install the compiler and libphobos from "RPMs" or build them
> from one or two tar files.

There *are* RPMs for GDC and DMD, though ?
Just haven't had space for the binaries...

But the specs can be found from here:
http://www.algonet.se/~afb/d/gdc.spec
http://www.algonet.se/~afb/d/dmd.spec

>>Part of this speed comes from optlink, I think ? (when it doesn't crash)
>>At least I've found the GCC linking to be slower, doubly so for C++...
> 
> I don't know - I usually work in Linux, and there it looks like dmd uses gcc to
> do the link. There is an option that lets you see the commands its running.

Yes, that is true - it does use gcc on Linux.

--anders
March 04, 2006
Andrew Fedoniouk wrote:

> 7. ClassLoader as an entity. Killer thing, IMO.
> 


Forgot to mention that this one is not entirely new, it was in Oberon (circa 1986).

see:

http://www.ics.uci.edu/~franz/SlimBinaries.html
http://www.ics.uci.edu/~franz/pubs-pdf/C09.pdf
http://mini.net/tcl/4400


March 04, 2006
Kevin Bealer wrote:
 > Let me propose some general hype; these will look a little like hyperbole, but
> most of them are more or less true (or could be without *too* much pain):
> 
> 1. D unites scripting style and C/C++ performance.
> 
> 2. D is like C++ after the lessons learned from Java, Python, and Perl.
> 
> 3. D is a high performance Java.
> 
> 4. D can do Perl or Python-style rapid development, but is safe enough and fast
> enough for "BIG" problems.
> 
> 5. D is like Java, but for systems programming tasks.
> 
> 6. D has all the power of C++ with the safety of Java.
> 

#3 and #6 is exactly what brought me to D, and I think it can bring many others!!
March 04, 2006
On 2006-03-01 02:15:35 -0800, "Walter Bright" <newshound@digitalmars.com> said:

> 
> "S. Chancellor" <dnewsgr@mephit.kicks-ass.org> wrote in message news:du376e$1fbf$2@digitaldaemon.com...
>> Something like this would be equivalent?
>> 
>> Transaction abc()
>> {
>> Foo f;
>> Bar b;
>> Def d;
>> Auto scoped = new Scoper();  //scoped.exit() can be called by the destructor.  We won't add a finally block.
>> 
>> try {
>> scoped.failures ~= void delegate () { dofoo_unwind(f); }
>> f = dofoo();
>> 
>> scoped.failures ~= void delegate () { dobar_unwind(b); }
>> b = dobar();
>> 
>> scoped.success()
>> } catch (Exception o) {
>> scoped.failed()
>> throw o;
>> }
>> 
>> return Transaction(f, b, d);
>> }
> 
> Should be:
>      f = dofoo();
>      scoped.failures ~= void delegate () { dofoo_unwind(f); }
> etc. Other than that, it looks like it'll work, but it's a lot more code than on_scope. You also need to be sure that the delegates don't refer to any variables declared inside the try block, as those variables no longer exist in the catch block - and the compiler can't catch that error. This isn't a problem with on_scope.

Why would that be the case?  If dofoo() throws an error, that delegate would not yet be appended to the failures delegate array.  Thus it wouldn't be able to do it's job in the catch block.  I know your and derek's order was like this originally, but it seemed like a typo so I fixed it.

-S.

March 04, 2006
On Sat, 4 Mar 2006 01:09:47 -0800, S. Chancellor <dnewsgr@mephit.kicks-ass.org> wrote:
> On 2006-03-01 02:15:35 -0800, "Walter Bright" <newshound@digitalmars.com> said:
>
>>  "S. Chancellor" <dnewsgr@mephit.kicks-ass.org> wrote in message news:du376e$1fbf$2@digitaldaemon.com...
>>> Something like this would be equivalent?
>>>  Transaction abc()
>>> {
>>> Foo f;
>>> Bar b;
>>> Def d;
>>> Auto scoped = new Scoper();  //scoped.exit() can be called by the destructor.  We won't add a finally block.
>>>  try {
>>> scoped.failures ~= void delegate () { dofoo_unwind(f); }
>>> f = dofoo();
>>>  scoped.failures ~= void delegate () { dobar_unwind(b); }
>>> b = dobar();
>>>  scoped.success()
>>> } catch (Exception o) {
>>> scoped.failed()
>>> throw o;
>>> }
>>>  return Transaction(f, b, d);
>>> }
>>  Should be:
>>      f = dofoo();
>>      scoped.failures ~= void delegate () { dofoo_unwind(f); }
>> etc. Other than that, it looks like it'll work, but it's a lot more code than on_scope. You also need to be sure that the delegates don't refer to any variables declared inside the try block, as those variables no longer exist in the catch block - and the compiler can't catch that error. This isn't a problem with on_scope.
>
> Why would that be the case?  If dofoo() throws an error, that delegate would not yet be appended to the failures delegate array.  Thus it wouldn't be able to do it's job in the catch block.  I know your and derek's order was like this originally, but it seemed like a typo so I fixed it.

The idea of dofoo_unwind is to reverse the changes made by dofoo when dofoo succeeds and a later step fails. If/when dofoo throws it should undo it's own changes before returning.

Regan
March 07, 2006
Anders F Björklund wrote:
> ianc wrote:
> 
>> Any idea what
>> Digital Mars biz model is for D when version 1 is released?
> 
> No idea, but it would be interesting if they (he?) could expand on it...
> I *guess* it would be similar to their C/C++ business model, though ?
> 
> http://www.digitalmars.com/shop.html

OEM licencing of DMD derivatives.
6 7 8 9 10 11 12 13 14 15 16
Next ›   Last »