View mode: basic / threaded / horizontal-split · Log in · Help
March 03, 2006
Re: why and how D can solve the next software crisis (was Re: Negative)
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
Re: Negative (or why people started adopting java)
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
Re: why and how D can solve the next software crisis (was Re: Negative)
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
Re: why and how D can solve the next software crisis (was Re: Negative)
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
Re: Negative
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
Re: why and how D can solve the next software crisis (was Re: Negative)
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
Re: try..catch..pass..finally Was: DMD 0.148 - scope guard
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
Re: try..catch..pass..finally Was: DMD 0.148 - scope guard
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
Re: why and how D can solve the next software crisis (was Re: Negative)
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.
Next ›   Last »
12 13 14 15 16
Top | Discussion index | About this forum | D home