On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote:
> On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
>> On another perspective: Consider this question "Would you be willing to have all your software (incl. OS) running 10% or even 20% slower but without bugs, leaks, (unintended) backdoors and the like?"
>>
>> My guess: Upwards of 80% would happily chime "YES!".
>
> Would you accept it if it means a 3x slowdown and no real time capabilities (no video games for instance) ?

I would, because my experience with Native Oberon and AOS (Blue Bottle),
teached me that those real time capabilities are possible in a desktop
OS written in a GC enabled systems programming language.

As example, BlueBottle has a video player, just the decoder has some snippets written in Assembly.

http://www.ocp.inf.ethz.ch/wiki/Documentation/WindowManager?action=download&upname=AosScreenshot1.jpg


--
Paulo

On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
> There are basically two ways to implement generics. Type erasure (Java,Haskell) or template instantiation (C++,D). Instantiation provides better performance, but sacrifices error messages (fixable?), binary code size, and compilation modularity (template implementation must be available for instantiation). Type safety is not a problem in either approach.

See this brief discussion from Greg Morrisett on the topic, with a finer subdivision of approaches

http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt

that confirms your bad news that monomorphization (C++/D templates) and separate compilation won't play well together. Nor do monomorphization and some advanced type system features work together, but that's less of a worry for D.

That said, I like the D approach of putting a lot of power in the macro-like template system. I worry more about the reliance on GC in a systems programming language, as historically that's been a losing proposition.

-- Brian

On Thursday, 22 August 2013 at 14:18:09 UTC, Brian Rogoff wrote:
> See this brief discussion from Greg Morrisett on the topic, with a finer subdivision of approaches
>
> http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt
>
> that confirms your bad news that monomorphization (C++/D templates) and separate compilation won't play well together. Nor do monomorphization and some advanced type system features work together, but that's less of a worry for D.

Well, in that paper they make a bit too hard statement - such model implies certain limitations for separate compilations (either explicit instantiation or having access to sources) but does not destroy completely. No silver bullet here, every approach has its own pros and cons.

As have been discussed recently, ancient object file / linker tool stack harms it much more when comes to practice.

>> http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt

I have quickly looked over that paper and find it quite worthless for a couple of reasons (I will not elaborate on, except one: All these scientific elaborations are nice and all but we have real problems here in the real world. Frankly, someone having worked on "Cyclone" may be bright and all, but he definitely hasn't got som major points).

While Eiffel and D look (and in quite some respects are) quite different, both have actually realized some important real world problems and have them addressed in not so different conceptual ways.

One of the reasons D is considerably more safe than C is strikingly simple and one doesn't need any scientific research to spot it: D offers (a quite sane implementation of) strings and "resizeable arrays".

Why is this related to safety? Because zillions of bugs have been created by programmers desperately using, bending and abusing what was available in C (and to a degree in C++). Give them reasonable strings and some reasonable way to handle dynamic arrays and you have prevented gazillions of bugs. Simple as that.

Another pragmatic look at reality underlines my point: In todays world even major software projects are being worked on by people with an almost brutally large degree of variation in their skills. Even worse, each of them (at least sometimes) has to work with code written by others with a (sometimes very) sifferent level of skills.

D has made a very major contribution to safety alone for the fact that it allows  less skilled people to create less errors.
And it has something else that might not seem that big a thing, that however, started a (imo) very important path: safe, trusted and system.
In C/C++ pretty everybody can - and does - play with potentially dangerous mechanism (like pointers) pretty much everywhere. Those simple 3 "code classes" safe, trusted and system can help a great deal there. One (OK, not very creative) example that comes to mind is to have less experienced programmers to work in "safe mode" only, which anyway is good enough for pretty everything the average app needs, and to limit "system mode" to seasoned programmers. Furthermore this D mechanism offers something else of high value by introducing a simple and important question "How much power do I need?".

I might sound streetwise rather than properly educated, I know, but I have experienced again and again that what really counts is results. And I'm sure that D, if understood and used properly, contributes quite much to a very important result: Less bugs and more reliable code.

On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
> One (OK, not very creative) example that comes to mind is to have less experienced programmers to work in "safe mode" only, which anyway is good enough for pretty everything the average app needs, and to limit "system mode" to seasoned programmers.

If I was managing a D based team, I would definitely make use of safe/system for code reviews. Any commit that touches @system code* would have to go through an extra stage or something to that effect.

On Thursday, 22 August 2013 at 15:50:50 UTC, John Colvin wrote:
> On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
>> One (OK, not very creative) example that comes to mind is to have less experienced programmers to work in "safe mode" only, which anyway is good enough for pretty everything the average app needs, and to limit "system mode" to seasoned programmers.
>
> If I was managing a D based team, I would definitely make use of safe/system for code reviews. Any commit that touches @system code* would have to go through an extra stage or something to that effect.

Yep. Considering that pretty every non-trivial/small utility software is layered anyway it comes even quite natural.

But I (often involved in systems stuff) will also use it as a private warning system. Trying to get done whatever can get done using @safe. Quite probably ("probably" because I lack experience with D) it will even reflect back on the design along the line of tinkering "does this *really* need to be here?".

On Thursday, 22 August 2013 at 14:37:21 UTC, Dicebot wrote:
> On Thursday, 22 August 2013 at 14:18:09 UTC, Brian Rogoff wrote:
>> See this brief discussion from Greg Morrisett on the topic, with a finer subdivision of approaches
>>
>> http://www.eecs.harvard.edu/~greg/cs256sp2005/lec15.txt
>>
>> that confirms your bad news that monomorphization (C++/D templates) and separate compilation won't play well together. Nor do monomorphization and some advanced type system features work together, but that's less of a worry for D.
>
> Well, in that paper they make a bit too hard statement - such model implies certain limitations for separate compilations (either explicit instantiation or having access to sources) but does not destroy completely. No silver bullet here, every approach has its own pros and cons.

Yeah, I agree, there are probably some tricks to make some things better, but overall it's a good description of the problem. Like you say, each approach has tradeoffs.

For a systems programming language, I think monomorphization is best.

-- Brian

On Thu, Aug 22, 2013 at 05:50:49PM +0200, John Colvin wrote:
> On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
> >One (OK, not very creative) example that comes to mind is to have less experienced programmers to work in "safe mode" only, which anyway is good enough for pretty everything the average app needs, and to limit "system mode" to seasoned programmers.
> 
> If I was managing a D based team, I would definitely make use of safe/system for code reviews. Any commit that touches @system code* would have to go through an extra stage or something to that effect.

Are you sure about that?

	import std.stdio;
	void main() @safe {
		writeln("abc");
	}

DMD says:

	/tmp/test.d(3): Error: safe function 'D main' cannot call system function 'std.stdio.writeln!(string).writeln'

SafeD is a nice concept, I agree, but we have a ways to go before it's usable.


T

-- 
LINUX = Lousy Interface for Nefarious Unix Xenophobes.

On Thursday, 22 August 2013 at 16:46:46 UTC, H. S. Teoh wrote:
> On Thu, Aug 22, 2013 at 05:50:49PM +0200, John Colvin wrote:
>> On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
>> >One (OK, not very creative) example that comes to mind is to have
>> >less experienced programmers to work in "safe mode" only, which
>> >anyway is good enough for pretty everything the average app needs,
>> >and to limit "system mode" to seasoned programmers.
>> 
>> If I was managing a D based team, I would definitely make use of
>> safe/system for code reviews. Any commit that touches @system code*
>> would have to go through an extra stage or something to that effect.
>
> Are you sure about that?
>
> 	import std.stdio;
> 	void main() @safe {
> 		writeln("abc");
> 	}
>
> DMD says:
>
> 	/tmp/test.d(3): Error: safe function 'D main' cannot call system function 'std.stdio.writeln!(string).writeln'
>
> SafeD is a nice concept, I agree, but we have a ways to go before it's
> usable.
>
>
> T

Fair point. Why is that writeln can't be @trusted?

On Thursday, 22 August 2013 at 17:16:13 UTC, John Colvin wrote:
> On Thursday, 22 August 2013 at 16:46:46 UTC, H. S. Teoh wrote:
>> On Thu, Aug 22, 2013 at 05:50:49PM +0200, John Colvin wrote:
>>> On Thursday, 22 August 2013 at 15:42:15 UTC, Ramon wrote:
>>> >One (OK, not very creative) example that comes to mind is to have
>>> >less experienced programmers to work in "safe mode" only, which
>>> >anyway is good enough for pretty everything the average app needs,
>>> >and to limit "system mode" to seasoned programmers.
>>> 
>>> If I was managing a D based team, I would definitely make use of
>>> safe/system for code reviews. Any commit that touches @system code*
>>> would have to go through an extra stage or something to that effect.
>>
>> Are you sure about that?
>>
>> 	import std.stdio;
>> 	void main() @safe {
>> 		writeln("abc");
>> 	}
>>
>> DMD says:
>>
>> 	/tmp/test.d(3): Error: safe function 'D main' cannot call system function 'std.stdio.writeln!(string).writeln'
>>
>> SafeD is a nice concept, I agree, but we have a ways to go before it's
>> usable.
>>
>>
>> T
>
> Fair point. Why is that writeln can't be @trusted?

In the case of a string, that is.