• bearophile <bearophileHUGS lycos.com> Jan 03 2011
• Andrej Mitrovic <andrej.mitrovich gmail.com> Jan 03 2011
• Andrej Mitrovic <andrej.mitrovich gmail.com> Jan 03 2011
• Dmitry Olshansky <dmitry.olsh gmail.com> Jan 03 2011
• Walter Bright <newshound2 digitalmars.com> Jan 03 2011

bearophile <bearophileHUGS lycos.com> writes:

Walter:

 I'm afraid that's baloney, as I pointed out in the other thread.


What you have said was about application code. It's not true for kernel code,
where you need strict control on what, how, and if the compiler performs
certain optimizations.


 I think that is a serious misinterpretation of the complaint. The complaint
was 
 actually that the high level abstractions that one can choose to use in C++
can 
 be impenetrable in what they do. In D, if you want low level control, write
low 
 level code. It's that simple.


This is true for C++ too. But he doesn't want high level abstractions in kernel
code. So he has not much use for C++ and D too. But he wants more static
analysis.


 Typed assembler is a waste of effort in a language like D, as you only need a 
 few drops of assembler here and there.


This talk says:
http://www.linuxjournal.com/article/7272
The problem is that being the kernel has to do a lot of things that break
typechecking. Which you see more in the kernel than in a lot of other programs.
You end up having a lot of inline assembly which is obviously completely
opaque.<


In the Nucleus of the experimental operating system Verve I have seen a good
amount of assembly code. They are able to use so much assembly because it's not
normal assembly, it's typed its assertions are often verified statically. So
it's not completely opaque.

In the D runtime I have counted 2100 lines of asm just for the array operations
implementation, (that's unfinished still). asm code is uncommon in application
programs, but it's clearly more than few drops.


 Those languages are failures at what they propose to do; they need years and 
 perhaps decades to fulfill that.


C#4 has contracts too, as a library:
http://research.microsoft.com/en-us/projects/contracts/

But this page says something interesting:
http://msdn.microsoft.com/en-us/devlabs/dd491992.aspx

Code Contracts Premium Edition: This version installs only if you have one of
the following: Visual Studio 2008 Team System, Visual Studio 2010 Premium
Edition, or Visual Studio 2010 Ultimate Edition. It includes the static checker
in addition to all of the features in the Code Contracts Standard Edition.<


It means that if today you have better versions of Visual Studio, then you have
a static checker for contracts. I have not used them yet, I will try to try
them. As you see Microsoft is pushing some of its research in the Real World
today.

And regardless the usefulness of Verve today, they contain some quite
interesting ideas. I'm not just an engineer, I like ideas too. Shutting the
brain closed is stupid.

Bye,
bearophile

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

"Code Contracts Premium Edition"

That's just hillarious. What's next, will the customers be forced to
buy a dozen pointers in a bundle? If you try using more than 10
pointers in your app you'll get a pop-up saying you're can't do that
in the trial version, upgrade now!. LOL!

Andrej Mitrovic <andrej.mitrovich gmail.com> writes:

"Limited offer: Increase your stack size, for only 49.99$!"

Dmitry Olshansky <dmitry.olsh gmail.com> writes:

On 03.01.2011 16:19, Andrej Mitrovic wrote:
 "Limited offer: Increase your stack size, for only 49.99$!"


to developers  :)

-- 
Dmitry Olshansky

Walter Bright <newshound2 digitalmars.com> writes:

bearophile wrote:
 It means that if today you have better versions of Visual Studio, then you
 have a static checker for contracts. I have not used them yet, I will try to
 try them. As you see Microsoft is pushing some of its research in the Real
 World today.


And as I pointed out to you, their contract support is *fundamentally* broken.
Furthermore, their static checker for contracts only works in *trivial* cases, 
as I also showed to you. This is not a technology that is ready for real world
use.


 And regardless the usefulness of Verve today, they contain some quite
 interesting ideas. I'm not just an engineer, I like ideas too. Shutting the
 brain closed is stupid.


Interesting ideas is not the same thing as usable/better for kernel dev. 
Interesting ideas are a dime a dozen. Getting them to work in a professionally 
useful tool is an entirely different matter.