www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why is `scope` planned for deprecation?

reply "Mike" <none none.com> writes:
First of all, what exactly is planned for deprecated? It [1] says 
"Note that scope for other usages (e.g. scoped variables) is 
unrelated to this feature and will not be deprecated.", but the 
example...

void main()
{
     A obj;
     {
         scope A a = new A(1);
         obj = a;
     }
     assert(obj.x == 1);  // fails, 'a' has been destroyed
}

... looks a lot like a scoped variable to me, so it's not clear 
to me what exactly is planned for deprecation. Please clarify.


Ok, with that out of the way, I get why it is unsafe, but isn't 
it only unsafe because it has not yet been implemented?  Isn't it 
possible to implement escape analysis and make it a safe and 
useful feature?

This question was asked before, but never received an answer.[2]

Mike

[1] 
http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack
[2] http://forum.dlang.org/post/k549l4$1s24$1 digitalmars.com
Nov 10 2014
next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
I think the general direction is that scope will be re-purposed as a
type modifier for implementing effective borrowing/escape analysis.
...at least, I really really hope that's the plan! :)

On 11 November 2014 09:33, Mike via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 First of all, what exactly is planned for deprecated? It [1] says "Note that
 scope for other usages (e.g. scoped variables) is unrelated to this feature
 and will not be deprecated.", but the example...

 void main()
 {
     A obj;
     {
         scope A a = new A(1);
         obj = a;
     }
     assert(obj.x == 1);  // fails, 'a' has been destroyed
 }

 ... looks a lot like a scoped variable to me, so it's not clear to me what
 exactly is planned for deprecation. Please clarify.


 Ok, with that out of the way, I get why it is unsafe, but isn't it only
 unsafe because it has not yet been implemented?  Isn't it possible to
 implement escape analysis and make it a safe and useful feature?

 This question was asked before, but never received an answer.[2]

 Mike

 [1]
 http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack
 [2] http://forum.dlang.org/post/k549l4$1s24$1 digitalmars.com
Nov 10 2014
prev sibling next sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
On 11/10/14 6:33 PM, Mike wrote:

 First of all, what exactly is planned for deprecated? It [1] says "Note
 that scope for other usages (e.g. scoped variables) is unrelated to this
 feature and will not be deprecated.", but the example...

 void main()
 {
      A obj;
      {
          scope A a = new A(1);
          obj = a;
      }
      assert(obj.x == 1);  // fails, 'a' has been destroyed
 }

 .... looks a lot like a scoped variable to me, so it's not clear to me
 what exactly is planned for deprecation. Please clarify.


 Ok, with that out of the way, I get why it is unsafe, but isn't it only
 unsafe because it has not yet been implemented?  Isn't it possible to
 implement escape analysis and make it a safe and useful feature?

 This question was asked before, but never received an answer.[2]

 Mike

 [1]
 http://dlang.org/deprecate.html#scope%20for%20allocating%20classes%20on%20the%20stack

 [2] http://forum.dlang.org/post/k549l4$1s24$1 digitalmars.com


Well, that's a funny thing. I looked it up, apparently using scope to 
designate "scope variables" is a thing:

http://dlang.org/attribute.html#scope

" For local declarations, scope implements the RAII (Resource 
Acquisition Is Initialization) protocol. This means that the destructor 
for an object is automatically called when the reference to it goes out 
of scope. The destructor is called even if the scope is exited via a 
thrown exception, thus scope is used to guarantee cleanup. "

Anyone used to using structs for RAII would think WAT? But a long time 
ago, structs did not have dtors. So I think at that time, scope simply 
applied only to classes. Note how it specifically says "objects"

What I think it means is, scope declarations for allocating classes will 
be destroyed when leaving scope, but will not be allocated on the stack.

I don't know why this is less dangerous. Perhaps it's destroyed but not 
deallocated?

But the deprecation says "(e.g. scoped variables) is unrelated to this 
feature." Seems pretty related.

My real guess is that the deprecation message is wrong. We have 
scope(exit), I don't see why we would need scope variables as well.

-Steve
Nov 10 2014
prev sibling parent reply "Dicebot" <public dicebot.lv> writes:
This is a bit complicated. Originally intention was to deprecate 
scope variables (scope var = new Class) completely and make 
people switch to std.typecons.scoped - primarily because of how 
fragile and inflexible its implementation was (can't have scope 
fields in aggregates for example)

However it never actually got deprecated and still kind of works 
with no warnings printed by compiler. Also I remember Daniel 
mentioning that he uses it extensively in DDMD project which, 
unfortunately, makes full deprecation unlikely.

There is however a long standing desire to re-purpose `scope` as 
qualifier for lifetime/ownership semantics which could have made 
current uses simply a subset of full `scope` implementation. But 
this is very complicated topic and may take years to fly.
Nov 11 2014
parent reply "ixid" <nuaccount gmail.com> writes:
On Tuesday, 11 November 2014 at 15:29:49 UTC, Dicebot wrote:

 But this is very complicated topic and may take years to fly.


The ship will have sailed by the time it's ready to fly 
(gloriously mixed metaphors), this would seem like such a 
fundamental issue with a big knock-on effect on everything else 
that it should surely be prioritized higher than that? I am aware 
you're not the one setting priorities. =)
Nov 11 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Tuesday, 11 November 2014 at 16:54:10 UTC, ixid wrote:

 On Tuesday, 11 November 2014 at 15:29:49 UTC, Dicebot wrote:

 But this is very complicated topic and may take years to fly.


 The ship will have sailed by the time it's ready to fly 
 (gloriously mixed metaphors), this would seem like such a 
 fundamental issue with a big knock-on effect on everything else 
 that it should surely be prioritized higher than that? I am 
 aware you're not the one setting priorities. =)


It is going to take such long time not because no one considers 
it important but because designing and implementing such system 
is damn hard. Prioritization does not make a difference here.
Nov 11 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Dicebot:


 ixid:

 The ship will have sailed by the time it's ready to fly 
 (gloriously mixed metaphors), this would seem like such a 
 fundamental issue with a big knock-on effect on everything 
 else that it should surely be prioritized higher than that? I 
 am aware you're not the one setting priorities. =)


 It is going to take such long time not because no one considers 
 it important but because designing and implementing such system 
 is damn hard. Prioritization does not make a difference here.


I agree it's a very important topic (more important/urgent than 
the GC, also because it reduces the need of the GC). But I think 
Walter thinks this kind of change introduces too much complexity 
in D (despite it may eventually become inevitable for D once Rust 
becomes more popular and programmers get used to that kind of 
static enforcement).

Regarding the design and implementation difficulties, is it 
possible to ask for help to one of the persons that designed (or 
watched closely design) the similar thing for Rust?

Bye,
bearophile
Nov 11 2014
next sibling parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 12 November 2014 04:01, bearophile via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Dicebot:


 ixid:

 The ship will have sailed by the time it's ready to fly (gloriously mixed
 metaphors), this would seem like such a fundamental issue with a big
 knock-on effect on everything else that it should surely be prioritized
 higher than that? I am aware you're not the one setting priorities. =)



 It is going to take such long time not because no one considers it
 important but because designing and implementing such system is damn hard.
 Prioritization does not make a difference here.



 I agree it's a very important topic (more important/urgent than the GC, also
 because it reduces the need of the GC). But I think Walter thinks this kind
 of change introduces too much complexity in D (despite it may eventually
 become inevitable for D once Rust becomes more popular and programmers get
 used to that kind of static enforcement).


I agree. scope is top of my wishlist these days. Above RC/GC, or
anything else you hear me talking about.
I don't think quality RC is practical without scope implemented, and
rvalue temps -> references will finally be solved too.
Quite a few things I care about rest on this, but it doesn't seem to
be a particularly popular topic :(


 Regarding the design and implementation difficulties, is it possible to ask
 for help to one of the persons that designed (or watched closely design) the
 similar thing for Rust?

 Bye,
 bearophile
Nov 12 2014
prev sibling parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 11/11/2014 18:01, bearophile wrote:

 I agree it's a very important topic (more important/urgent than the GC,
 also because it reduces the need of the GC). But I think Walter thinks
 this kind of change introduces too much complexity in D (despite it may
 eventually become inevitable for D once Rust becomes more popular and
 programmers get used to that kind of static enforcement).


I think Rust's lifetimes would be a huge change if ported to D. In Rust 
user types often need annotations as well as function parameters. People 
tend to want Rust's guarantees without the limitations. I think D does 
need some kind of scope attribute verification, but we need to throw out 
some of the guarantees Rust makes to get an appropriate fit for existing 
D code.

For example, taking a mutable borrowed pointer for a variable means you 
can't even *read* the original variable whilst the pointer lives. I 
think no one would try to make D do that, but Rust's reason for adding 
it is actually memory safety (I don't quite understand it, but it 
involves iterator invalidation apparently). It's possible their feature 
can be refined, but basically 'mut' in Rust really means 'unique'.
Nov 12 2014
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven 
wrote:

 On 11/11/2014 18:01, bearophile wrote:

 I agree it's a very important topic (more important/urgent 
 than the GC,
 also because it reduces the need of the GC). But I think 
 Walter thinks
 this kind of change introduces too much complexity in D 
 (despite it may
 eventually become inevitable for D once Rust becomes more 
 popular and
 programmers get used to that kind of static enforcement).


 I think Rust's lifetimes would be a huge change if ported to D. 
 In Rust user types often need annotations as well as function 
 parameters. People tend to want Rust's guarantees without the 
 limitations. I think D does need some kind of scope attribute 
 verification, but we need to throw out some of the guarantees 
 Rust makes to get an appropriate fit for existing D code.


Have you seen my proposal?

http://wiki.dlang.org/User:Schuetzm/scope

It takes a slightly different approach from Rust. Instead of 
specifying lifetimes, it uses owners, and it's also otherwise 
more simple than Rust's system. E.g. there is no full blown 
borrow checker (and no need for it).


 For example, taking a mutable borrowed pointer for a variable 
 means you can't even *read* the original variable whilst the 
 pointer lives. I think no one would try to make D do that, but 
 Rust's reason for adding it is actually memory safety (I don't 
 quite understand it, but it involves iterator invalidation 
 apparently). It's possible their feature can be refined, but 
 basically 'mut' in Rust really means 'unique'.


In my proposal, there's "const borrowing". It still allows access 
to the owner, but not mutation. This is necessary for safe 
implementation of move semantics, and to guard against iterator 
invalidation. It also has other uses, like the problems with 
"transient range", e.g. stdin.byLine(), which overwrite their 
buffer in popFront(). On the other hand, it's opt-in; by default, 
owners are mutable while borrowed references exist.
Nov 12 2014
parent reply Nick Treleaven <ntrel-pub mybtinternet.com> writes:
On 12/11/2014 17:16, "Marc Schütz" <schuetzm gmx.net>" wrote:

 On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven wrote:

 For example, taking a mutable borrowed pointer for a variable means
 you can't even *read* the original variable whilst the pointer lives.
 I think no one would try to make D do that, but Rust's reason for
 adding it is actually memory safety (I don't quite understand it, but
 it involves iterator invalidation apparently). It's possible their
 feature can be refined, but basically 'mut' in Rust really means
 'unique'.


 In my proposal, there's "const borrowing". It still allows access to the
 owner, but not mutation. This is necessary for safe implementation of
 move semantics, and to guard against iterator invalidation. It also has
 other uses, like the problems with "transient range", e.g.
 stdin.byLine(), which overwrite their buffer in popFront(). On the other
 hand, it's opt-in; by default, owners are mutable while borrowed
 references exist.


Looks good. Personally I've been meaning to study your (whole) proposal, 
I think its a valuable analysis of what problems we could/should solve.

Just from a quick look, I wonder if 'const borrowing' could solve the 
scoped!C premature destruction problem:

C c = std.typecons.scoped!C();
// memory for c has already been freed (need auto c = ...)

If the destruction of Scoped is disallowed whilst an (implicit alias 
this) borrow for c is alive, the compiler can generate an error.
Nov 13 2014
parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 13 November 2014 at 16:56:01 UTC, Nick Treleaven 
wrote:

 On 12/11/2014 17:16, "Marc Schütz" <schuetzm gmx.net>" wrote:

 On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven 
 wrote:

 For example, taking a mutable borrowed pointer for a variable 
 means
 you can't even *read* the original variable whilst the 
 pointer lives.
 I think no one would try to make D do that, but Rust's reason 
 for
 adding it is actually memory safety (I don't quite understand 
 it, but
 it involves iterator invalidation apparently). It's possible 
 their
 feature can be refined, but basically 'mut' in Rust really 
 means
 'unique'.


 In my proposal, there's "const borrowing". It still allows 
 access to the
 owner, but not mutation. This is necessary for safe 
 implementation of
 move semantics, and to guard against iterator invalidation. It 
 also has
 other uses, like the problems with "transient range", e.g.
 stdin.byLine(), which overwrite their buffer in popFront(). On 
 the other
 hand, it's opt-in; by default, owners are mutable while 
 borrowed
 references exist.


 Looks good. Personally I've been meaning to study your (whole) 
 proposal, I think its a valuable analysis of what problems we 
 could/should solve.

 Just from a quick look, I wonder if 'const borrowing' could 
 solve the scoped!C premature destruction problem:

 C c = std.typecons.scoped!C();
 // memory for c has already been freed (need auto c = ...)

 If the destruction of Scoped is disallowed whilst an (implicit 
 alias this) borrow for c is alive, the compiler can generate an 
 error.


Const borrowing is not even necessary for that. The problem with 
`std.typecons.scoped!C` is that it implicitly converts to `C`. 
Instead, it should only convert to `scope!this(C)`, then the 
assignment will be rejected correctly:

     // ERROR: type mismatch: C != scope(C)
     C c = std.typecons.scoped!C();
     // ERROR: `c` outlives it's owner (temporary)
     scope(C) c = std.typecons.scoped!C();
     // OK: typeof(c) is now scoped!C
     auto c = std.typecons.scoped!C();
Nov 13 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven
wrote:

 I think Rust's lifetimes would be a huge change if ported to D. 
 In Rust user types often need annotations as well as function 
 parameters. People tend to want Rust's guarantees without the 
 limitations. I think D does need some kind of scope attribute 
 verification, but we need to throw out some of the guarantees 
 Rust makes to get an appropriate fit for existing D code.


Rust is not the first language going that road. The problem is
that you get great complexity if you don't want to be too
limiting in what you can do. This complexity ultimately ends up
costing more than what you gain.

I think the sane road to go into is supporting
ownership/burrowing for common cases, and fallback on the GC, or
unsafe construct for the rest.

One have to admit there is no silver bullet, and shoehorning
everything in the same solution is not gonna work.
Nov 12 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/12/14 2:10 PM, deadalnix wrote:

 On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven
 wrote:

 I think Rust's lifetimes would be a huge change if ported to D. In
 Rust user types often need annotations as well as function parameters.
 People tend to want Rust's guarantees without the limitations. I think
 D does need some kind of scope attribute verification, but we need to
 throw out some of the guarantees Rust makes to get an appropriate fit
 for existing D code.


 Rust is not the first language going that road. The problem is
 that you get great complexity if you don't want to be too
 limiting in what you can do. This complexity ultimately ends up
 costing more than what you gain.

 I think the sane road to go into is supporting
 ownership/burrowing for common cases, and fallback on the GC, or
 unsafe construct for the rest.

 One have to admit there is no silver bullet, and shoehorning
 everything in the same solution is not gonna work.


I agree. This is one of those cases in which a good engineering solution 
may be a lot better than the "perfect" solution (and linear types are 
not even perfect...).

Andrei
Nov 12 2014
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
Are you guys saying you don't feel this proposal is practical?
http://wiki.dlang.org/User:Schuetzm/scope

I think it's a very interesting approach, and comes from a practical
point of view. It solves the long-standings issues, like scope return
values, in a very creative way.

On 13 November 2014 08:33, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 11/12/14 2:10 PM, deadalnix wrote:

 On Wednesday, 12 November 2014 at 15:57:18 UTC, Nick Treleaven
 wrote:

 I think Rust's lifetimes would be a huge change if ported to D. In
 Rust user types often need annotations as well as function parameters.
 People tend to want Rust's guarantees without the limitations. I think
 D does need some kind of scope attribute verification, but we need to
 throw out some of the guarantees Rust makes to get an appropriate fit
 for existing D code.


 Rust is not the first language going that road. The problem is
 that you get great complexity if you don't want to be too
 limiting in what you can do. This complexity ultimately ends up
 costing more than what you gain.

 I think the sane road to go into is supporting
 ownership/burrowing for common cases, and fallback on the GC, or
 unsafe construct for the rest.

 One have to admit there is no silver bullet, and shoehorning
 everything in the same solution is not gonna work.



 I agree. This is one of those cases in which a good engineering solution may
 be a lot better than the "perfect" solution (and linear types are not even
 perfect...).

 Andrei
Nov 13 2014
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via 
Digitalmars-d wrote:

 Are you guys saying you don't feel this proposal is practical?
 http://wiki.dlang.org/User:Schuetzm/scope

 I think it's a very interesting approach, and comes from a 
 practical
 point of view. It solves the long-standings issues, like scope 
 return
 values, in a very creative way.


You need to define ownership before defining borrowing.
Nov 13 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 November 2014 19:56, deadalnix via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via Digitalmars-d wrote:

 Are you guys saying you don't feel this proposal is practical?
 http://wiki.dlang.org/User:Schuetzm/scope

 I think it's a very interesting approach, and comes from a practical
 point of view. It solves the long-standings issues, like scope return
 values, in a very creative way.


 You need to define ownership before defining borrowing.


I don't think this proposal has issues with that.
The thing at the root of the call tree is the 'owner'. Nothing can
escape a scope call-tree, so the owner or allocation policy doesn't
matter, and that's the whole point.
Nov 13 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 13 November 2014 at 10:32:05 UTC, Manu via
Digitalmars-d wrote:

 I don't think this proposal has issues with that.
 The thing at the root of the call tree is the 'owner'. Nothing 
 can
 escape a scope call-tree, so the owner or allocation policy 
 doesn't
 matter, and that's the whole point.


That is way to define ownerhsip so that is not a rebutal of my
comment. This makes assumption about ownership, that we may or
may not want;

I think the proposal is sound overall (I haven't try to explore
all special cases scenarios, so it is a reserved yes for now) but
going forward with this before defining ownership is not a good
approach.
Nov 13 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 14 November 2014 09:28, deadalnix via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 13 November 2014 at 10:32:05 UTC, Manu via
 Digitalmars-d wrote:

 I don't think this proposal has issues with that.
 The thing at the root of the call tree is the 'owner'. Nothing can
 escape a scope call-tree, so the owner or allocation policy doesn't
 matter, and that's the whole point.



 That is way to define ownerhsip so that is not a rebutal of my
 comment. This makes assumption about ownership, that we may or
 may not want;

 I think the proposal is sound overall (I haven't try to explore
 all special cases scenarios, so it is a reserved yes for now) but
 going forward with this before defining ownership is not a good
 approach.


I'm super happy your on board with this. You're often a hard sell :)

What about the definition of 'ownership' do you find problematic?
It's clear we're not going to get multiple pointer types (read: owner
types) like in Rust... so then ownership strategy will probably remain
fairly arbitrary.

The point of scope seems to be precisely to set the problem of
ownership aside. That leaves ownership at the root of the call-tree to
remain being managed however the user likes.

Once we have scope, then we can have meaningful implementations of
things like a unique pointer, and finally approach efficient RC.
Personally, it has proven to be the most inhibiting barrier to further
development in most areas I care about left.
Nov 13 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 14 November 2014 at 03:20:42 UTC, Manu via 
Digitalmars-d wrote:

 I'm super happy your on board with this. You're often a hard 
 sell :)

 What about the definition of 'ownership' do you find 
 problematic?


I don't find it problematic. However, the concept of burrowing 
(what we do with scope in that proposal) makes assumptions about 
ownership. So I'd like to see ownership addressed.

Ultimately, we can decide that ownership is loosely defined, but 
that may have very important consequences on the possibility - or 
not - to introduce ownership. I think ownership is an important 
concept to have to get the gc world and the non gc worlds 
interact nicely (which should be a big interest of yours as well).


 It's clear we're not going to get multiple pointer types (read: 
 owner
 types) like in Rust... so then ownership strategy will probably 
 remain
 fairly arbitrary.


I think it make sense to have something for ownership. The error 
of rust wasn't going that road, but going in that road 100%, 
which come at a cost at interface level which is too important. A 
simpler ownership system, that fallback on the GC or unsafe 
feature when it fall short.

I'm confident at this point that we can get most of the benefit 
of an ownership system with something way simpler than rust's 
system if you accept to not cover 100% of the scenarios.


 Once we have scope, then we can have meaningful implementations 
 of
 things like a unique pointer, and finally approach efficient RC.
 Personally, it has proven to be the most inhibiting barrier to 
 further
 development in most areas I care about left.


Yes, that is absolutely necessary to have safe RC, and a great 
tool to make it more efficient.

I'm not fan of unique as this is, IMO, a dumbed down version of 
what ownership can be, with no real upside.
Nov 13 2014
parent reply "Araq" <rumpf_a web.de> writes:
 I think it make sense to have something for ownership. The 
 error of rust wasn't going that road, but going in that road 
 100%, which come at a cost at interface level which is too 
 important. A simpler ownership system, that fallback on the GC 
 or unsafe feature when it fall short.

 I'm confident at this point that we can get most of the benefit 
 of an ownership system with something way simpler than rust's 
 system if you accept to not cover 100% of the scenarios.


Do you happen to have any concrete reasons for that? An example
maybe? Maybe start with explaining how in detail Rust's system is
too complex? I'm sure the Rust people will be interested in how
you can simplify a (most likely sound) type system that took
years to come up with and refine.
Nov 14 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 14 November 2014 at 14:59:39 UTC, Araq wrote:

 I think it make sense to have something for ownership. The 
 error of rust wasn't going that road, but going in that road 
 100%, which come at a cost at interface level which is too 
 important. A simpler ownership system, that fallback on the GC 
 or unsafe feature when it fall short.

 I'm confident at this point that we can get most of the 
 benefit of an ownership system with something way simpler than 
 rust's system if you accept to not cover 100% of the scenarios.


 Do you happen to have any concrete reasons for that? An example
 maybe? Maybe start with explaining how in detail Rust's system 
 is
 too complex? I'm sure the Rust people will be interested in how
 you can simplify a (most likely sound) type system that took
 years to come up with and refine.


I'm not sure we understand rust type system to be too complicated
the same way.

Let's be clear: There is no accidental complexity in Rust's type
system. It is sound and very powerful. There is no way I can
think of you could make it simpler.

That being said, there are cases where Rust's type system shine,
for instance tree like datastructures with same lifetime, passing
down immutable objects to pure functions and so on.

But there are also cases when it become truly infamous like a
digraph of object with disparate lifetime.

Rust made the choice to have this safe memory management that do
not rely on the GC, so they have to handle the infamous cases.
This require a rich and complex type system.

My point is that we can support the nice cases with something
much simpler, while delegating the infamous ones to the GC or
unsafe constructs. The good news is that the nice cases are more
common that the hard ones (or Rust would be absolutely unusable)
so we can reap most of the benefices of a rust like approach
while introducing much less complexity in the language.

  From a cost benefice perspective, this seems like the right way
forward to me.

To quote the guy from the PL for video games video serie, a 85%
solution often is preferable.
Nov 14 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/14/2014 4:32 PM, deadalnix wrote:

 To quote the guy from the PL for video games video serie, a 85%
 solution often is preferable.


Spoken like a true engineer!
Nov 15 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 16 November 2014 at 03:27:54 UTC, Walter Bright wrote:

 On 11/14/2014 4:32 PM, deadalnix wrote:

 To quote the guy from the PL for video games video serie, a 85%
 solution often is preferable.


 Spoken like a true engineer!


More like a consultant for self-help:

http://www.amazon.com/85%25-Solution-Personal-Accountability-Guarantees/dp/0470500166


Real world 85% engineered solutions:

1. Titanic
2. Chernobyl
3. Challenger
4. C++
…
Nov 16 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/16/2014 3:30 AM, "Ola Fosheim Grøstad"

 Real world 85% engineered solutions:

 1. Titanic


Everyone likes to rag on the Titanic's design, but I've read a fair amount
about 
it, and it's quite an unfair rap. It was, for its day, the safest ship afloat, 
and did represent a significant step forward in safety:

1. The watertight compartments were innovative and kept the Titanic afloat for 
hours. Without them, it would have sank very quickly. The damage the Titanic 
suffered was very unusual in its extensiveness, and would have sunk any ship of 
the day.

2. The wireless was new and state of the art, without it the Titanic would have 
sunk with all aboard without a trace, and what happened to it would have been a 
great mystery. The fault with the wireless had nothing to do with its 
engineering, but with its management (the California did not keep a 24 hr watch 
on the radio).

3. The hull steel was inferior by today's standards, but was the best available 
by the standards of its time.

4. The rudder was inadequate, but little was known at the time about how such 
large ships would handle, and they didn't exactly have computer simulation 
software available.

5. The oft-repeated thing about the lifeboats was a little unreasonable. The
way 
ships usually sink it's very difficult to launch any lifeboats successfully. If 
the ship listed, the boats on the high side could not be launched at all, and
if 
it tilted down at a steeper angle none of them could be launched. The way the 
Titanic sank, slowly and fairly levelly, enabling nearly all the boats to be 
launched, was very unusual. The idea was with the watertight compartments it 
would sink slowly enough that the boats could be used to ferry the passengers
to 
safety. That in fact would have worked if the California had been monitoring
the 
wireless.

It's unfair to apply the hubris of hindsight. Apply instead the standards and 
practices of the foresight, and the Titanic comes off very well.

It was not designed to drive full speed into an iceberg, and modern ships can't 
handle that, either. Actually, the Titantic would likely have fared better than 
modern ships if it didn't try to turn but simply rammed it head on. The 
watertight compartments would have kept it afloat.

For comparison, look what happened to that italian cruise ship a few years ago. 
It got a minor hole punched in the side by a rock, rolled over and sank.
Nov 16 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 16 November 2014 at 17:46:09 UTC, Walter Bright wrote:

 Everyone likes to rag on the Titanic's design, but I've read a 
 fair amount about it, and it's quite an unfair rap. It was, for 
 its day, the safest ship afloat, and did represent a 
 significant step forward in safety:


«The 20 lifeboats that she did carry could only take 1,178 
people, even though there were about 2,223 on board.» 
http://en.wikipedia.org/wiki/Lifeboats_of_the_RMS_Titanic

Thats not even a 85% solution, it is a 53% solution.


 It's unfair to apply the hubris of hindsight. Apply instead the 
 standards and practices of the foresight, and the Titanic comes 
 off very well.


I don't know, my grandfather's uncle went with one of the 
expeditions around Greenland and they did not sink. That ship 
(Fram) was designed for being frozen into the ice as it was 
designed for being used in to reach the north pole. The shape of 
the hull was designed to "pop out" of the ice rather than being 
pushed down so that the ship could float over the arctic as part 
of the ice. It was later used for several trips, notably the 
famous trip to reach the south pole. That's a lot closer to a 
100% engineering solution!


 It was not designed to drive full speed into an iceberg, and 
 modern ships can't handle that, either.


It was not sane to drive at full speed I guess. There was a lot 
of arrogance in the execution around Titanic, both leaving with 
insufficient life boats and driving at full speed suggest a lack 
of understanding…


Returning to programming languages: if I cannot implement 100% of 
my design with a language then it is a non-solution. 85% is not 
enough.

In business applications people sometimes have to settle for 
ready-made 85% solutions and change their business practices to 
get the last 15%, but that is not good enough for systems 
programming IMO. That's how you think about frameworks, but not 
how you think about language design (or system level runtime).
Nov 16 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/16/2014 10:27 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 Returning to programming languages: if I cannot implement 100% of my design
with
 a language then it is a non-solution. 85% is not enough.


You can do anything with a language if it is Turing complete.



 In business applications people sometimes have to settle for ready-made 85%
 solutions and change their business practices to get the last 15%, but that is
 not good enough for systems programming IMO. That's how you think about
 frameworks, but not how you think about language design (or system level
runtime).


Be careful you don't fall into kitchen sink syndrome. Add enough features, and 
the language becomes unusable. Features are almost never orthogonal, they
always 
interact and interfere with each other. This applies to all engineering, not 
just languages. There are no 100% solutions.

For example, D doesn't support multiple inheritance. This is on purpose. Yes, 
some C++ programmers believe D is badly broken because of this. I don't at all 
believe it is unreasonable that one should make adaptations in design in order 
to use a language successfully.

After all, D is explicitly designed to be a "pragmatic" language.
Nov 16 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 16 November 2014 at 18:36:01 UTC, Walter Bright wrote:

 You can do anything with a language if it is Turing complete.


That's not the point. If you have to avoid features because they 
aren't general enough or have to change the design to fit the 
language and not the hardware, then the language design becomes a 
problem.


 Be careful you don't fall into kitchen sink syndrome. Add 
 enough features, and the language becomes unusable. Features 
 are almost never orthogonal, they always interact and interfere 
 with each other. This applies to all engineering, not just 
 languages. There are no 100% solutions.


I think C is pretty close to a 98% solution for system level 
programming. Granted, it relies on macros to reach that.


 For example, D doesn't support multiple inheritance. This is on 
 purpose. Yes, some C++ programmers believe D is badly broken 
 because of this. I don't at all believe it is unreasonable that 
 one should make adaptations in design in order to use a 
 language successfully.

 After all, D is explicitly designed to be a "pragmatic" 
 language.


I am not sure if OO-inheritance and virtual functions are all 
that important for system level programming, but generally 
features should work across the board if it can be implemented 
efficiently. E.g. creating "weird" typing rules due to ease of 
implementation does not sit well with me.

Or to put it in more simple terms: figuring out how a programming 
language works is a necessary investment, but having to figure 
out how a programming language does not work and when is really 
annoying.
Nov 16 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/16/2014 10:52 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 I think C is pretty close to a 98% solution for system level programming.


Not at all in my view. It has two miserable failures:

1. C's Biggest Mistake

http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625

This made C far, far more difficult and buggy to work with than it should have
been.


2. 0 terminated strings

This makes it surprisingly difficult to do performant string manipulation, and 
also results in a excessive memory consumption.



 Granted, it relies on macros to reach that.


And it's a crummy macro system, even for its day.


My above remarks should be put in context of when C was designed. As with the 
Titanic, it is unfair to apply modern sensibilities to it. But if we were to, a 
vast amount of C could be dramatically improved without changing its
fundamental 
nature.
Nov 16 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 16 November 2014 at 19:24:47 UTC, Walter Bright wrote:

 This made C far, far more difficult and buggy to work with than 
 it should have been.


Depends on your view of C, if you view C as step above assembly 
then it makes sense to treat everything as pointers. It is a bit 
confusing in the beginning since it is more or less unique to C.


 2. 0 terminated strings

 This makes it surprisingly difficult to do performant string 
 manipulation, and also results in a excessive memory 
 consumption.


Whether using sentinels is slow or fast depends on what you want 
to do, but it arguably save space for small strings (add a length 
+ alignment and you loose ~6 bytes).

Also dealing with a length means you cannot keep everything in 
registers on simple CPUs.

A lexer that takes zero terminated input is a lot easier to write 
and make fast than one that use length.

Nothing prevents you from creating a slice as a struct though.


 sensibilities to it. But if we were to, a vast amount of C 
 could be dramatically improved without changing its fundamental 
 nature.


To me the fundamental nature of C is:

1. I can visually imagine how the code maps onto the hardware

2. I am not bound to a complicated runtime
Nov 16 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/16/2014 11:59 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Sunday, 16 November 2014 at 19:24:47 UTC, Walter Bright wrote:

 This made C far, far more difficult and buggy to work with than it should have
 been.


 Depends on your view of C, if you view C as step above assembly then it makes
 sense to treat everything as pointers.


If you read my article, the fix does not take away anything.



 2. 0 terminated strings

 This makes it surprisingly difficult to do performant string manipulation, and
 also results in a excessive memory consumption.


 Whether using sentinels is slow or fast depends on what you want to do, but it
 arguably save space for small strings (add a length + alignment and you loose
~6
 bytes).

 Also dealing with a length means you cannot keep everything in registers on
 simple CPUs.

 A lexer that takes zero terminated input is a lot easier to write and make fast
 than one that use length.


I've worked enough with C to know that these arguments do not hold up in real
code.



 Nothing prevents you from creating a slice as a struct though.


I've tried that, too. Doesn't work - the C runtime library prevents it, as well 
as every other library.



 sensibilities to it. But if we were to, a vast amount of C could be
 dramatically improved without changing its fundamental nature.


 To me the fundamental nature of C is:

 1. I can visually imagine how the code maps onto the hardware

 2. I am not bound to a complicated runtime


None of the fixes I've suggested impair that in any way.
Nov 16 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 16 November 2014 at 20:26:36 UTC, Walter Bright wrote:

 If you read my article, the fix does not take away anything.


Yes, but that is just what all other languages had at the time, 
so leaving it out was obviously deliberate. I assume they wanted 
a very simple model where each parameter could fit in a register.


 I've worked enough with C to know that these arguments do not 
 hold up in real code.


But you have to admit that older CPUS/tight RAM does have an 
effect? Even 8086 have dedicated string instructions with the 
ability to terminate on zero (REPNZ)
Nov 16 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/16/2014 12:44 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Sunday, 16 November 2014 at 20:26:36 UTC, Walter Bright wrote:

 If you read my article, the fix does not take away anything.


 Yes, but that is just what all other languages had at the time, so leaving it
 out was obviously deliberate. I assume they wanted a very simple model where
 each parameter could fit in a register.


Since structs were supported, this rationale does not work.



 I've worked enough with C to know that these arguments do not hold up in real
 code.


 But you have to admit that older CPUS/tight RAM does have an effect? Even 8086
 have dedicated string instructions with the ability to terminate on zero
(REPNZ)


Remember that I wrote successful C and C++ compilers for 16 bit 8086 machines, 
and programmed on it for a decade. I know about those instructions, and I'm 
familiar with the tradeoffs. It's not worth it.

Besides, C was designed for the PDP-11, which had no such instructions.
Nov 16 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 16 November 2014 at 21:54:40 UTC, Walter Bright wrote:

 Besides, C was designed for the PDP-11, which had no such 
 instructions.


BTW, this is not entirely correct. It had autoincrement on 
registers. This is the example given on Wikipedia:

  MOV #MSG,R1
1$: MOVB (R1)+,R0
  BEQ DONE
  .TTYOUT
  BR 1$
  .EXIT

MSG: .ASCIZ /Hello, world!/

The full example:

http://en.wikipedia.org/wiki/MACRO-11

So the print loop is 4 instructions (I assume .TTYOUT is a I/O 
instruction), with a length you would at least have 5 
instructions and use an extra register, as you would have an 
additional compare.

(As for concat, that I almost never use. In systems programming 
you mostly append to buffers and flush when the buffer is full. 
Don't need length for that. Even in javascript and python I avoid 
regular concat due to the inefficency of concat versus a buffered 
join.)
Nov 18 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2014 9:01 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Sunday, 16 November 2014 at 21:54:40 UTC, Walter Bright wrote:

 Besides, C was designed for the PDP-11, which had no such instructions.


 BTW, this is not entirely correct. It had autoincrement on registers.


Those are not dedicated string instructions. Autoincrement was an addressing 
mode that could be used with any register and any instruction, including the 
stack and program counter (!).

Autoincrement/autodecrement gave rise to *p++ and *p-- in C.


 This is the example given on Wikipedia:

   MOV #MSG,R1
 1$: MOVB (R1)+,R0
   BEQ DONE
   .TTYOUT
   BR 1$
   .EXIT

 MSG: .ASCIZ /Hello, world!/

 The full example:

 http://en.wikipedia.org/wiki/MACRO-11


More than destroyed by every time you have to call strlen().



 So the print loop is 4 instructions (I assume .TTYOUT is a I/O instruction),
 with a length you would at least have 5 instructions and use an extra register,
 as you would have an additional compare.


.TTYOUT is a macro that expands to code that calls the operating system. The 11 
doesn't have I/O instructions.



 (As for concat, that I almost never use. In systems programming you mostly
 append to buffers and flush when the buffer is full. Don't need length for
that.


Uh, you need the length to determine when "the buffer is full".



 Even in javascript and python  I avoid regular concat due to the inefficency of
 concat versus a buffered join.)


Just try to manipulate paths, filenames, and extensions without using strlen() 
and strcat(). Your claim that C string code doesn't use strlen() is patently
absurd.

Besides, you wouldn't be using javascript or python if efficiency mattered.
Nov 18 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 18 November 2014 at 21:07:22 UTC, Walter Bright wrote:

 Those are not dedicated string instructions. Autoincrement was 
 an addressing mode that could be used with any register and any 
 instruction, including the stack and program counter (!).


Yes, Motorola 68000 also had those. Very useful combined with 
sentinels! ;^) It was one of those things that made the 68K asm 
feel a bit like a high level language.


 Autoincrement/autodecrement gave rise to *p++ and *p-- in C.


Might have, but not from PDP-11. It came to C from B which 
predated PDP-11.


 More than destroyed by every time you have to call strlen().


Don't!

And factor in the performance loss coming from reading from 
punched tape… ;-)

(Actually sentinels between fields are also better for recovery 
if you have data corruption in files, although there are many 
other solutions, but this is a non-problem today.)


 .TTYOUT is a macro that expands to code that calls the 
 operating system. The 11 doesn't have I/O instructions.


Ah, ok, so it was a system call.


 Uh, you need the length to determine when "the buffer is full".


For streaming: fixed size, modulo 2.

For allocating: worst case allocate, then release.


 Just try to manipulate paths, filenames, and extensions without 
 using strlen() and strcat(). Your claim that C string code 
 doesn't use strlen() is patently absurd.


No, I don't claim that I never used strlen(), but I never used 
strcat() IIRC, and never had the need to repeatedly call strlen() 
on long strings. Long strings would usually sit in a struct where 
there is space for a length. Slightly annoying, but not the big 
deal.

Filenames are easy, just allocate a large fixed size buffer, then 
fill in. open(). reuse buffer.


 Besides, you wouldn't be using javascript or python if 
 efficiency mattered.


Actually, lately most of my efficiency related programming is 
done in javascript!  I spend a lot of time breaking up javascript 
code into async calls to get good responsiveness. But most of my 
efficiency related problems are in browser engine layout-code 
(not javascript) that I have to work around somehow.

Javascript in isolation is getting insanely fast in the last 
generations of browser JITs. It is almost a bit scary, because 
that means that we might be stuck with it forever…
Nov 18 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2014 1:56 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 Filenames are easy, just allocate a large fixed size buffer, then fill in.
 open(). reuse buffer.


     char s[] = "filename.ext";
     foo(s[0..8]);

But hey, it's simpler, faster, less code, less bug prone, easier to understand 
and uses less memory to:

1. strlen
2. allocate
3. memcpy
4. append a 0
    foo
5. free

instead, right?

I know you said "just allocate a large fixed size buffer", but I hope you 
realize that such practice is the root cause of most buffer overflow bugs, 
because the "640K is enough for anyone" just never works.

And your "just use a struct" argument also promptly falls apart with:

     foo("string")

Now, I know that you'll never concede destruction, after all, this is the 
internet, but give it up :-)
Nov 18 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 19 November 2014 at 00:04:50 UTC, Walter Bright 
wrote:

 I know you're simply being argumentative when you defend VLAs, 
 a complex and
 useless feature, and denigrate simple ptr/length pairs as 
 complicated.


Wait, we are either discussing the design goals of the original C 
or the evolved C. VLAs did not fit the original C either, but in 
the google discussion you find people who find VLAs very useful. 
It looks a loot better than alloca. The reason it is made 
optional is to make embedded-C compilers easier to write, I think.


 But hey, it's simpler, faster, less code, less bug prone, 
 easier to understand and uses less memory to:

 1. strlen
 2. allocate


…

Not faster, but if speed is no concern, sure. It seldom is when 
it comes to filenames.


 I know you said "just allocate a large fixed size buffer", but 
 I hope you realize that such practice is the root cause of most 
 buffer overflow bugs,


strcat() should never have been created, but strlcat is safe.


 Now, I know that you'll never concede destruction, after all, 
 this is the internet, but give it up :-)


I always concede destruction :-)
Nov 19 2014
prev sibling next sibling parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 16 Nov 2014 19:59:52 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 A lexer that takes zero terminated input is a lot easier to write=20
 and make fast than one that use length.


that's why warp is faster than cpp? ;-)
Nov 16 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 16 November 2014 at 22:00:10 UTC, ketmar via 
Digitalmars-d wrote:

 that's why warp is faster than cpp? ;-)


Which implementation of cpp?

(Btw, take a look at lexer.c in DMD :-P)
Nov 16 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 16 Nov 2014 22:09:00 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Sunday, 16 November 2014 at 22:00:10 UTC, ketmar via=20
 Digitalmars-d wrote:

 that's why warp is faster than cpp? ;-)


 Which implementation of cpp?


gcc implementation, afair. it's slowness was the reason for warping.


 (Btw, take a look at lexer.c in DMD :-P)


c++ has no good string type, so there is no much choice.

as a writer of at least four "serious" scripting languages (and alot
more as "toy" ones) i can tell you that zero-terminated strings are
PITA. the only sane way to write a good lexer is working with structure
which emulates D string and slicing (if we must parse text from
in-memory buffer, of course).
Nov 16 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 16 November 2014 at 22:18:51 UTC, ketmar via 
Digitalmars-d wrote:

 On Sun, 16 Nov 2014 22:09:00 +0000
 via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Sunday, 16 November 2014 at 22:00:10 UTC, ketmar via 
 Digitalmars-d wrote:

 that's why warp is faster than cpp? ;-)


 Which implementation of cpp?


 gcc implementation, afair. it's slowness was the reason for 
 warping.


Ok, I haven't seen an independent benchmark, but I believe clang 
is faster. But…

https://github.com/facebook/warp/blob/master/lexer.d#L173


 PITA. the only sane way to write a good lexer is working with 
 structure
 which emulates D string and slicing (if we must parse text from
 in-memory buffer, of course).


Nah, if you know that the file ends with zero then you can build 
an efficient finite automata as a classifier.
Nov 16 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Sun, 16 Nov 2014 22:22:42 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 Nah, if you know that the file ends with zero then you can build=20
 an efficient finite automata as a classifier.


FSA code is a fsckn mess. either adding dependency of external tool and
alot of messy output to project, or writing that messy code manually.
and FSA is not necessary faster, as it's bigger and so it trashing CPU
cache.
Nov 16 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/16/2014 2:22 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Sunday, 16 November 2014 at 22:18:51 UTC, ketmar via Digitalmars-d wrote:

 On Sun, 16 Nov 2014 22:09:00 +0000
 via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Sunday, 16 November 2014 at 22:00:10 UTC, ketmar via Digitalmars-d wrote:

 that's why warp is faster than cpp? ;-)


 Which implementation of cpp?


 gcc implementation, afair. it's slowness was the reason for warping.


 Ok, I haven't seen an independent benchmark, but I believe clang is faster.
But…

 https://github.com/facebook/warp/blob/master/lexer.d#L173


Notice the total lack of strlen()'s in Warp.



 Nah, if you know that the file ends with zero then you can build an efficient
 finite automata as a classifier.


deadalnix busted that myth a while back with benchmarks.
Nov 16 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 17 November 2014 at 01:39:38 UTC, Walter Bright wrote:

 Notice the total lack of strlen()'s in Warp.


Why would you need that? You know where the lexeme begins and 
ends? If we are talking about old architectures you have to 
acknowledge that storage was premium and that the major cost was 
getting the strings into memory in the first place.


 Nah, if you know that the file ends with zero then you can 
 build an efficient
 finite automata as a classifier.


 deadalnix busted that myth a while back with benchmarks.


I haven't seen it, but it is difficult to avoid lexers being 
bandwidth limited these days.

Besides, how do you actually implement a lexer without 
constructing a FA one way or the other?
Nov 16 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/16/2014 5:43 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Monday, 17 November 2014 at 01:39:38 UTC, Walter Bright wrote:

 Notice the total lack of strlen()'s in Warp.


 Why would you need that? You know where the lexeme begins and ends? If we are
 talking about old architectures you have to acknowledge that storage was
premium
 and that the major cost was getting the strings into memory in the first place.


The preprocessor stores lots of strings. Things like identifiers, keywords, 
string literals, expanded macro text, etc.

The C preprocessor I wrote in C years ago is filled with strlen(), as is about 
every C string processing program ever written. Heck, how do you think strcat() 
works?

(Another problem with strlen() is that the string pointed to is in a different 
piece of memory, and it'll have to be loaded into the cache to scan for the 0. 
Whereas with slices, the length data is in the hot cache.)



 Nah, if you know that the file ends with zero then you can build an efficient
 finite automata as a classifier.


 deadalnix busted that myth a while back with benchmarks.


 I haven't seen it,


It's in the n.g. archives somewhere in a thread about implementing lexers.



 but it is difficult to avoid lexers being bandwidth limited
 these days.

 Besides, how do you actually implement a lexer without constructing a FA one
way
 or the other?


That's the wrong question. The question is does a trailing sentinel result in a 
faster FA? deadalnix demonstrated that the answer is 'no'.

You know, Ola, I've been in the trenches with this problem for decades. 
Sometimes I still learn something new, as I did with deadalnix's benchmark. But 
the stuff you are positing is well-trodden ground. There's a damn good reason 
why D uses slices and not 0 terminated strings.
Nov 17 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 17 November 2014 at 10:18:41 UTC, Walter Bright wrote:

 (Another problem with strlen() is that the string pointed to is 
 in a different piece of memory, and it'll have to be loaded 
 into the cache to scan for the 0. Whereas with slices, the 
 length data is in the hot cache.)


Oh, I am not saying that strlen() is a good contemporary 
solution. I am saying that when you have <32KiB RAM total it 
makes sense to save space by not storing the string length.


 deadalnix busted that myth a while back with benchmarks.


 I haven't seen it,


 It's in the n.g. archives somewhere in a thread about 
 implementing lexers.


Well, then it is just words.


 That's the wrong question. The question is does a trailing 
 sentinel result in a faster FA? deadalnix demonstrated that the 
 answer is 'no'.


I hear that, but the fact remains, you do less work. It should 
therefore be faster. So if it is not, then you're either doing 
something wrong or you have bubbles in the pipeline on a specific 
CPU that you fail to fill. On newer CPUs you have a tiny loop 
buffer for tight inner loops that runs microops without decode, 
you want to keep the codesize down there.

Does it matter a lot in the world of SIMD? Probably not, but then 
you get a more complex lexer to maintain.


 deadalnix's benchmark. But the stuff you are positing is 
 well-trodden ground. There's a damn good reason why D uses 
 slices and not 0 terminated strings.


I've never said that D should use 0 terminated strings. Now you 
twist the debate.
Nov 17 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
Remember that the alternative to zero-terminated strings at that 
time was to have 2 string types, one with a one byte length and 
one with a larger length. So I think C made the right choice for 
it's time, to have a single string type without a length.
Nov 17 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 17 November 2014 at 11:43:45 UTC, Ola Fosheim Grøstad 
wrote:

 Remember that the alternative to zero-terminated strings at 
 that time was to have 2 string types, one with a one byte 
 length and one with a larger length. So I think C made the 
 right choice for it's time, to have a single string type 
 without a length.


Black hat hackers, virus and security tools vendors around the 
world rejoice of that decision...

It was anything but right.
Nov 17 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 17 November 2014 at 12:36:49 UTC, Paulo  Pinto wrote:

 On Monday, 17 November 2014 at 11:43:45 UTC, Ola Fosheim 
 Grøstad wrote:

 Remember that the alternative to zero-terminated strings at 
 that time was to have 2 string types, one with a one byte 
 length and one with a larger length. So I think C made the 
 right choice for it's time, to have a single string type 
 without a length.


 Black hat hackers, virus and security tools vendors around the 
 world rejoice of that decision...

 It was anything but right.


I don't think buffer overflow and string fundamentals are closely 
related, if used reasonably, but I'm not surprised you favour 
Pascal's solution of having two string types: one for strings up 
to 255 bytes and another one for longer strings.

Anyway, here is the real reason for how C implemented strings:

«None of BCPL, B, or C supports character data strongly in the 
language; each treats strings much like vectors of integers and 
supplements general rules by a few conventions. In both BCPL and 
B a string literal denotes the address of a static area 
initialized with the characters of the string, packed into cells. 
In BCPL, the first packed byte contains the number of characters 
in the string; in B, there is no count and strings are terminated 
by a special character, which B spelled `*e'. This change was 
made partially to avoid the limitation on the length of a string 
caused by holding the count in an 8- or 9-bit slot, and partly 
because maintaining the count seemed, in our experience, less 
convenient than using a terminator.

Individual characters in a BCPL string were usually manipulated 
by spreading the string out into another array, one character per 
cell, and then repacking it later; B provided corresponding 
routines, but people more often used other library functions that 
accessed or replaced individual characters in a string.»

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
Nov 17 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 17 November 2014 at 12:49:16 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 17 November 2014 at 12:36:49 UTC, Paulo  Pinto wrote:

 On Monday, 17 November 2014 at 11:43:45 UTC, Ola Fosheim 
 Grøstad wrote:

 Remember that the alternative to zero-terminated strings at 
 that time was to have 2 string types, one with a one byte 
 length and one with a larger length. So I think C made the 
 right choice for it's time, to have a single string type 
 without a length.


 Black hat hackers, virus and security tools vendors around the 
 world rejoice of that decision...

 It was anything but right.


 I don't think buffer overflow and string fundamentals are 
 closely related, if used reasonably, but I'm not surprised you 
 favour Pascal's solution of having two string types: one for 
 strings up to 255 bytes and another one for longer strings.

 Anyway, here is the real reason for how C implemented strings:

 «None of BCPL, B, or C supports character data strongly in the 
 language; each treats strings much like vectors of integers and 
 supplements general rules by a few conventions. In both BCPL 
 and B a string literal denotes the address of a static area 
 initialized with the characters of the string, packed into 
 cells. In BCPL, the first packed byte contains the number of 
 characters in the string; in B, there is no count and strings 
 are terminated by a special character, which B spelled `*e'. 
 This change was made partially to avoid the limitation on the 
 length of a string caused by holding the count in an 8- or 
 9-bit slot, and partly because maintaining the count seemed, in 
 our experience, less convenient than using a terminator.

 Individual characters in a BCPL string were usually manipulated 
 by spreading the string out into another array, one character 
 per cell, and then repacking it later; B provided corresponding 
 routines, but people more often used other library functions 
 that accessed or replaced individual characters in a string.»

 http://cm.bell-labs.com/cm/cs/who/dmr/chist.html


I am fully aware how UNIX designers decided to ignore the systems 
programming being done in Algol variants, PL/I variants and many 
other wannabe systems programming languages that came before C.

Which they are repeating again with Go.

--
Paulo
Nov 17 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 17 November 2014 at 13:39:05 UTC, Paulo  Pinto wrote:

 I am fully aware how UNIX designers decided to ignore the 
 systems programming being done in Algol variants, PL/I variants 
 and many other wannabe systems programming languages that came 
 before C.


I wouldn't say that Algol is a systems programming language, and 
Pascal originally only had fixed width strings!

(But Simula actually had decent GC backed string support with 
substrings pointing to the same buffer and a link to the full 
buffer from substrings, thus somewhat more advanced than D ;-)
Nov 17 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/17/2014 3:43 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 Remember that the alternative to zero-terminated strings at that time was to
 have 2 string types, one with a one byte length and one with a larger length.


No, that was not the alternative.
Nov 17 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/17/2014 3:00 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 I am saying
 that when you have <32KiB RAM total it makes sense to save space by not storing
 the string length.


I know what you're saying.

You're saying without evidence that sentinels are faster. They are not.
You're saying without evidence that 0 terminated strings use less memory. They 
do not.

(It does not save space when "filename" and "filename.ext" cannot be
overlapped.)
Nov 17 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 17 November 2014 at 19:24:49 UTC, Walter Bright wrote:

 You're saying without evidence that sentinels are faster. They 
 are not.


You are twisting and turning so much in discussions that you make 
me dizzy.

I've been saying that for SOME OPERATIONS they are too, and that 
is not without evidence. Just plot it out for a 65xx, 680xx, Z80 
etc CPU and it becomes self-evident. Any system level programmer 
should be able to do it in a few minutes.

Using sentinels is a common trick for speeding up algorithms, it 
has some downsides, and some upsides, but they are used for a 
reason (either speed, convenience or both).

Pretending that sentinels are entirely useless is not a sane line 
of argument. I use sentinels in many situations and for many 
purposes, and they can greatly speed up and/or simplify code.


 You're saying without evidence that 0 terminated strings use 
 less memory. They do not.

 (It does not save space when "filename" and "filename.ext" 
 cannot be overlapped.)


0-terminated and shortstring (first byte being used for length) 
takes the same amount of space, but permanent substring reference 
slices are very wasteful of memory for low memory situations:

1. you need a ref count on the base buffer (2-4 bytes)
2. you need pointer to base + 2 offsets (4-12 bytes)

And worst is you retain the whole buffer even if you only 
reference a tiny portion of it. Yuk! In such a use scenario you 
are generally better of reallocation or use compaction. For 
non-permanent substrings you can still use begin/end pointers.

And please no, GC is not the answer, Simula had GC and the kind 
of strings and substrings you argued for but it was not intended 
for system level programming and it was not resource efficient. 
It was convenient. Scripty style concatenation and substring 
slicing is fun, but it is not system level programming. System 
level programming is about taking control over the hardware and 
use it most efficiently. Abstractions "that lie" mess this up.

Is wasting space on meta information less critical today? YES, OF 
COURSE! It does matter that we have 100.000 times more RAM 
available.
Nov 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/17/2014 1:08 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 I've been saying that for SOME OPERATIONS they are too, and that is not without
 evidence. Just plot it out for a 65xx, 680xx, Z80 etc CPU and it becomes
 self-evident. Any system level programmer should be able to do it in a few
minutes.


When designing a language data type, you don't design it for "some" operations. 
You design it so that it works best most of the time, or at least let the user 
decide.

You can always add a sentinel for specific cases. But C forces its use for all 
strings for practical purposes. The design is backwards, and most of the time a 
sentinel is the wrong choice.

BTW, I learned how to program on a 6800. I'm not ignorant of those machines.
And 
frankly, C is too high level for the 6800 (and the other 8 bit CPUs). The idea 
that C maps well onto those processors is mistaken. Which is hardly surprising, 
as C was developed for the PDP-11, a 16 bit machine.

Yes, I know that people did use C for 8 bit machines.
Nov 17 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Monday, 17 November 2014 at 22:03:48 UTC, Walter Bright wrote:

 You can always add a sentinel for specific cases. But C forces 
 its use for all strings for practical purposes. The design is 
 backwards, and most of the time a sentinel is the wrong choice.


Ok, but I would rather say it like this: the language C doesn't 
really provide strings, it only provides literals in a particular 
format. So the literal-format is a trade-off between having 
something generic and simple and having something more complex 
and possibly limited (having 255 char limit is not good enough in 
the long run).

I think there is a certain kind of beauty to the minimalistic 
approach taken with C (well, at least after ANSI-C came about in 
the late 80s). I like the language better than the libraries…


 BTW, I learned how to program on a 6800. I'm not ignorant of 
 those machines. And frankly, C is too high level for the 6800 
 (and the other 8 bit CPUs). The idea that C maps well onto 
 those processors is mistaken.


Yes I agree, but those instruction sets are simple. :-) With only 
256 bytes of builtin RAM (IIRC) the 6800 was kind of skimpy on 
memory! We used it in high school for our classes in digital 
circuitry/projects.

(It is very difficult to discuss performance on x86, there is 
just too much clutter and machinery in the core that can skew 
results.)
Nov 17 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/17/2014 3:15 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 Ok, but I would rather say it like this: the language C doesn't really provide
 strings, it only provides literals in a particular format. So the
literal-format
 is a trade-off between having something generic and simple and having something
 more complex and possibly limited (having 255 char limit is not good enough in
 the long run).


The combination of the inescapable array-to-ptr decay when calling a function, 
coupled with the Standard library which is part of the language that takes
char* 
as strings, means that for all practical purposes C does provide strings, and 
pretty much forces it on the programmer.



 I think there is a certain kind of beauty to the minimalistic approach taken
 with C (well, at least after ANSI-C came about in the late 80s). I like the
 language better than the libraries…


C is a brilliant language. That doesn't mean it hasn't made serious mistakes in 
its design. The array decay and 0 strings have proven to be very costly to 
programmers over the decades.
Nov 17 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright wrote:

 On 11/17/2014 3:15 PM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 Ok, but I would rather say it like this: the language C 
 doesn't really provide
 strings, it only provides literals in a particular format. So 
 the literal-format
 is a trade-off between having something generic and simple and 
 having something
 more complex and possibly limited (having 255 char limit is 
 not good enough in
 the long run).


 The combination of the inescapable array-to-ptr decay when 
 calling a function, coupled with the Standard library which is 
 part of the language that takes char* as strings, means that 
 for all practical purposes C does provide strings, and pretty 
 much forces it on the programmer.



 I think there is a certain kind of beauty to the minimalistic 
 approach taken
 with C (well, at least after ANSI-C came about in the late 
 80s). I like the
 language better than the libraries…


 C is a brilliant language. That doesn't mean it hasn't made 
 serious mistakes in its design. The array decay and 0 strings 
 have proven to be very costly to programmers over the decades.


Heartbleed is a nice example.

The amount of money in developer time, delivery software updates 
to customers and buying new hardware with firmware that cannot be 
replaced.

This is just one case, the CVE List gets updated every day and 
90% of the issues are the usual C suspects regarding pointer 
misuse and out of bounds.

Anyone writing C code should by following practices like 
https://wiki.debian.org/Hardening

--
Paulo
Nov 18 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 18 November 2014 at 08:28:19 UTC, Paulo  Pinto wrote:

 This is just one case, the CVE List gets updated every day and 
 90% of the issues are the usual C suspects regarding pointer 
 misuse and out of bounds.


Sure, but these are not a strict language issues since the same 
developers would turn off bounds-checking at the first 
opportunity anyway!

Professionalism does not involve blaming the tool, it involves 
picking the right tools and process for the task. Unfortunately 
the IT industry has over time suffered from a lack of formal 
education and immature markets. Software is considered to work 
when it crash only once every 24 hours, we would not accept that 
from any other utility?

I've never heard anyone in academia claim that C is anything more 
than a small step up from assembler (i.e. low level), so why 
allow intermediate skilled programmers to write C code if you for 
the same application would not allow an excellent programmer to 
write the same program in assembly (about the same risk of having 
a crash). People get what they deserve.

Never blame the tool for bad management. You get to pick the tool 
and the process, right? Neither the tool or testing will ensure 
correct behaviour on its own. You have many factors that need to 
play together (mindset, process and the tool set).

If you want a compiler that works, you're probably better off 
writing it in ML than in C, but people implement it in C. Why? 
Because they FEEL like it… It is not rational. It is emotional.
Nov 18 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2014 4:18 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 Never blame the tool for bad management.


To bring up the aviation industry again, they long ago recognized that "blame 
the pilot" and "blame the mechanics" is not how safe airplanes are made. They 
are made, in part, by fixing the tools so mistakes cannot happen, as even the 
best humans keep making mistakes.

C is a mistake-prone tool, and suggesting that programmers get better educated 
about how to use it does not work.

As I showed, a great deal of C's propensity for buffer overflows can be 
eliminated by a TRIVIAL change to the language, one that is fully backwards 
compatible, and takes NOTHING away from C's power. I've brought this up in 
conference presentations more than once, and the blank silence I get from C 
programmers just baffles me.

Blaming the tools is often appropriate.
Nov 18 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 18 November 2014 at 19:42:20 UTC, Walter Bright wrote:

 To bring up the aviation industry again, they long ago 
 recognized that "blame the pilot" and "blame the mechanics" is 
 not how safe airplanes are made. They are made, in part, by 
 fixing the tools so mistakes cannot happen, as even the best 
 humans keep making mistakes.


Please note that I said it was a management issue. Clearly if 
management equip workers with unsafe tools that is bad. But there 
have always been safer tools available. It has always been 
possible to do things differently. It has always been possible to 
do risk assessment and adopt to it, in tools, education and 
process.

I am sure the aviation industry is doing a lot better than the IT 
industry!


 Blaming the tools is often appropriate.


If you are forced to use one while being asked to run for a 
deadline, sure.
Nov 18 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 18 November 2014 at 12:18:16 UTC, Ola Fosheim Grøstad
wrote:

 On Tuesday, 18 November 2014 at 08:28:19 UTC, Paulo  Pinto 
 wrote:

 This is just one case, the CVE List gets updated every day and 
 90% of the issues are the usual C suspects regarding pointer 
 misuse and out of bounds.


 Sure, but these are not a strict language issues since the same 
 developers would turn off bounds-checking at the first 
 opportunity anyway!

 Professionalism does not involve blaming the tool, it involves 
 picking the right tools and process for the task. Unfortunately 
 the IT industry has over time suffered from a lack of formal 
 education and immature markets. Software is considered to work 
 when it crash only once every 24 hours, we would not accept 
 that from any other utility?

 I've never heard anyone in academia claim that C is anything 
 more than a small step up from assembler (i.e. low level), so 
 why allow intermediate skilled programmers to write C code if 
 you for the same application would not allow an excellent 
 programmer to write the same program in assembly (about the 
 same risk of having a crash). People get what they deserve.

 Never blame the tool for bad management. You get to pick the 
 tool and the process, right? Neither the tool or testing will 
 ensure correct behaviour on its own. You have many factors that 
 need to play together (mindset, process and the tool set).

 If you want a compiler that works, you're probably better off 
 writing it in ML than in C, but people implement it in C. Why? 
 Because they FEEL like it… It is not rational. It is emotional.


There are good answer to most of this but most importantly, this
do not contain anything actionable and is completely off topic(
reminder, the topic of the thread is SCOPE ).

Reader's time is precious, please don't waste it.
Nov 18 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 19 November 2014 at 01:13:04 UTC, deadalnix wrote:

 There are good answer to most of this but most importantly, this
 do not contain anything actionable and is completely off topic(
 reminder, the topic of the thread is SCOPE ).


The topic is if "scope" is planned for deprecation. That has been 
answered.

The thread has been off topic for a long time, so please don't 
use moderation for silencing an opposing viewpoint from a single 
party. Unless you are a moderator, but then you should also point 
to the rules of the forum.

If you are a moderator, then you should first and foremost 
moderate people who go ad hominem without providing an identity.

Self-appointing moderation will always lead to a very bad 
situation. If the forums need moderation appoint a moderator.



 Reader's time is precious, please don't waste it.


Then don't read. The topic of this thread was never actionable. 
Sounds like you want a pure developers forum.

If you want a community you need a lower threshold general forum. 
"D" is the general forum until it has been defined to not be so, 
but you do need a low threshold forum.

(I never give in to online bullies in unmoderated media… That 
gives them a foothold.)
Nov 19 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright wrote:

 C is a brilliant language. That doesn't mean it hasn't made 
 serious mistakes in its design. The array decay and 0 strings 
 have proven to be very costly to programmers over the decades.


I'd rather say that it is the industry that has misappropriated 
C, which in my view basically was "typed portable assembly" with 
very little builtin presumptions by design. This is important 
when getting control over layout, and this transparency is a 
quality that only C gives me. BCPL might be considered to have 
more presumptions (such as string length), being a minimal 
"bootstrapping subset" of CPL.

You always had the ability in C to implement arrays as a variable 
sized struct with a length and a trailing data section, so I'd 
say that the C provided type safe variable length arrays. Many 
people don't use it. Many people don't know how to use it. Ok, 
but then they don't understand that they are programming in a low 
level language and are responsible for creating their own 
environment. I think C's standard lib mistakingly created an 
illusion of high level programming that the language only 
partially supported.

Adding the ability to transfer structs by value as a parameter 
was probably not worth the implementation cost at the time… 
Having a "magic struct/tuple" that transfer length or end pointer 
with the head pointer does not fit the C design. If added it 
should have been done as a struct and to make that work you would 
have to add operator overloading. There's an avalanche effect of 
features and additional language design issues there.

I think K&R deserves credit for being able to say no and stay 
minimal, I think the Go team deserves the same credit. As you've 
experienced with D, saying no is hard because there are often 
good arguments for features being useful and difficult to say in 
advance with certainty what kind of avalanche effect adding 
features have (in terms of semantics, special casing and new 
needs for additional support/features, time to complete 
implementation/debugging). So saying no until practice shows that 
a feature is sorely missed is a sign of good language design 
practice.

The industry wanted portability and high speed and insisted 
moving as a flock after C and BLINDLY after C++. Seriously, the 
media frenzy around C++ was hysterical despite C++ being a bad 
design from the start. The C++ media noise was worse than with 
Java IIRC. Media are incredibly shallow when they are trying to 
sell mags/books based on the "next big thing" and they can 
accelerate adoption beyond merits. Which both C++ and Java are 
two good examples of.

There were alternatives such as Turbo Pascal, Modula-2/3, Simula, 
Beta, ML, Eiffel, Delphi and many more. Yet, programmers thought 
C was cool because it was "portable assembly" and "industry 
standard" and "fast" and "safe bet". So they were happy with it, 
because C compiler emitted fast code. And fast was more important 
to them than safe. Well, they got what they deserved, right?

Not adding additional features is not a design mistake if you try 
hard to stay minimal and don't claim to support high level 
programming. The mistake is in using a tool as if it supports 
something it does not.

You might be right that K&R set the bar too high for adding extra 
features. Yet others might be right that D has been too willing 
to add features. As you know, the perfect balance is difficult to 
find and it is dependent on the use context, so it materialize 
after the fact (after implementation). And C's use context has 
expanded way beyond the original use context where people were 
not afraid to write assembly.

(But the incomprehensible typing notation for function pointers 
was a design mistake since that was a feature of the language.)
Nov 18 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 18 November 2014 at 11:15:28 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright 
 wrote:

 C is a brilliant language. That doesn't mean it hasn't made 
 serious mistakes in its design. The array decay and 0 strings 
 have proven to be very costly to programmers over the decades.


 I'd rather say that it is the industry that has misappropriated 
 C, which in my view basically was "typed portable assembly" 
 with very little builtin presumptions by design.


Lint was created in 1979 when it was already clear most AT&T 
developers weren't writing correct C code!


 I think K&R deserves credit for being able to say no and stay 
 minimal, I think the Go team deserves the same credit.


Of course, two of them are from the same team.


 The industry wanted portability and high speed and insisted 
 moving as a flock after C and BLINDLY after C++. Seriously, the 
 media frenzy around C++ was hysterical despite C++ being a bad 
 design from the start. The C++ media noise was worse than with 
 Java IIRC. Media are incredibly shallow when they are trying to 
 sell mags/books based on the "next big thing" and they can 
 accelerate adoption beyond merits. Which both C++ and Java are 
 two good examples of.

 There were alternatives such as Turbo Pascal, Modula-2/3, 
 Simula, Beta, ML, Eiffel, Delphi and many more. Yet, 
 programmers thought C was cool because it was "portable 
 assembly" and "industry standard" and "fast" and "safe bet".


This was a consequence of UNIX spreading into the enterprise, 
like we
have to endure JavaScript to target the browser, we were forced to
code in C to target UNIX.

Other OS just followed along, as we started to want to port those 
big
iron utilities to smaller computers.

If UNIX had been written in XPTO-LALA, we would all be coding in 
XPTO-LALA today.


--
Paulo
Nov 18 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 18 November 2014 at 12:02:01 UTC, Paulo  Pinto wrote:

 On Tuesday, 18 November 2014 at 11:15:28 UTC, Ola Fosheim 
 Grøstad wrote:

 I'd rather say that it is the industry that has 
 misappropriated C, which in my view basically was "typed 
 portable assembly" with very little builtin presumptions by 
 design.


 Lint was created in 1979 when it was already clear most AT&T 
 developers weren't writing correct C code!


Sure, but most operating system vendors considered it a strategic 
move to ensure availability of high level languages on their 
mainframes. E.g. Univac provided Algol and gave a significant 
rebate to the developers of Simula on the purchase of a Univac to 
ensure that Simula would be available for high level programming.


 There were alternatives such as Turbo Pascal, Modula-2/3, 
 Simula, Beta, ML, Eiffel, Delphi and many more. Yet, 
 programmers thought C was cool because it was "portable 
 assembly" and "industry standard" and "fast" and "safe bet".


 This was a consequence of UNIX spreading into the enterprise, 
 like we
 have to endure JavaScript to target the browser, we were forced 
 to
 code in C to target UNIX.


Nobody were forced to write code in C to target anything, it was 
a choice. And a choice that grew out of a focus on performance 
and the fact that people still dropped down to write machine 
language quit frequently. Mentality matters.

Javascript is different, since it is "the exposed VM" in the 
browser, but even there you don't have to write in Javascript. 
You can write in a language that compiles to javascript.
Nov 18 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 18 November 2014 at 13:50:59 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 18 November 2014 at 12:02:01 UTC, Paulo  Pinto 
 wrote:
....

 Nobody were forced to write code in C to target anything, it 
 was a choice. And a choice that grew out of a focus on 
 performance and the fact that people still dropped down to 
 write machine language quit frequently. Mentality matters.

 Javascript is different, since it is "the exposed VM" in the 
 browser, but even there you don't have to write in Javascript. 
 You can write in a language that compiles to javascript.


Since when do developers use a different systems programming 
language than the one sold by the OS vendor?

Who has the pleasure to waste work hours writing FFI wrappers 
around SDK tools?

All successful systems programming languages, even if only for a 
few years, were tied to a specific OS.

--
Paulo
Nov 18 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 18 November 2014 at 14:56:42 UTC, Paulo  Pinto wrote:

 Since when do developers use a different systems programming 
 language than the one sold by the OS vendor?

 Who has the pleasure to waste work hours writing FFI wrappers 
 around SDK tools?

 All successful systems programming languages, even if only for 
 a few years, were tied to a specific OS.


Depends on what you mean by system programming. I posit that most 
programs that have been written in C are primarily application 
level programs. Meaning that you could factor out the C component 
as a tiny unit and write the rest in another language… Most high 
level languages provide integration with C. These things are 
entirely cultural.

In the late 80s you could do the same stuff in Turbo Pascal as in 
C, and integrate with asm with no problem. Lots of decent 
software for MSDOS was written in TP, such as BBS server software 
dealing with many connections.

On regular micros you didn't have a MMU so there was actually a 
great penalty for using an unsafe language even during 
development: the OS would reboot (or you would get the famous 
guru meditation on Amiga). That sucked.
Nov 18 2014
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 18 November 2014 at 15:36:58 UTC, Ola Fosheim Grøstad
wrote:

 On Tuesday, 18 November 2014 at 14:56:42 UTC, Paulo  Pinto 
 wrote:

 Since when do developers use a different systems programming 
 language than the one sold by the OS vendor?

 Who has the pleasure to waste work hours writing FFI wrappers 
 around SDK tools?

 All successful systems programming languages, even if only for 
 a few years, were tied to a specific OS.


 Depends on what you mean by system programming. I posit that 
 most programs that have been written in C are primarily 
 application level programs. Meaning that you could factor out 
 the C component as a tiny unit and write the rest in another 
 language… Most high level languages provide integration with C. 
 These things are entirely cultural.



In the 80's almost everything was system programming, even
business applications.

You are forgetting the UNIX factor again.

We only had C available in UNIX systems as compiled language.
HP-UX was the only commercial UNIX I used where we had access to
compilers for other languages.

So who would pay for third party tooling, specially with the way
software used to cost?

Then of course, many wanted to do on their CP/M, Spectrum and
similar systems the type of coding possible at work or
university, which lead to Small C and other C based compilers,
thus spreading the language outside UNIX.



 In the late 80s you could do the same stuff in Turbo Pascal as 
 in C, and integrate with asm with no problem. Lots of decent 
 software for MSDOS was written in TP, such as BBS server 
 software dealing with many connections.


I was doing Turbo Pascal most of the time, by the time I learned C
with Turbo C 2.0, Turbo C++ 1.0 was just around the corner and I
only
touched pure C again on teachers and employers request.


 On regular micros you didn't have a MMU so there was actually a 
 great penalty for using an unsafe language even during 
 development: the OS would reboot (or you would get the famous 
 guru meditation on Amiga). That sucked.


Amiga was programmed in Assembly. Except for Amos, we didn't use
anything else.

--
Paulo
Nov 18 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2014 3:15 AM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright wrote:

 C is a brilliant language. That doesn't mean it hasn't made serious mistakes
 in its design. The array decay and 0 strings have proven to be very costly to
 programmers over the decades.


 I'd rather say that it is the industry that has misappropriated C, which in my
 view basically was "typed portable assembly" with very little builtin
 presumptions by design. This is important when getting control over layout, and
 this transparency is a quality that only C gives me. BCPL might be considered
to
 have more presumptions (such as string length), being a minimal "bootstrapping
 subset" of CPL.

 You always had the ability in C to implement arrays as a variable sized struct
 with a length and a trailing data section, so I'd say that the C provided type
 safe variable length arrays. Many people don't use it. Many people don't know
 how to use it. Ok, but then they don't understand that they are programming in
a
 low level language and are responsible for creating their own environment. I
 think C's standard lib mistakingly created an illusion of high level
programming
 that the language only partially supported.

 Adding the ability to transfer structs by value as a parameter was probably not
 worth the implementation cost at the time… Having a "magic struct/tuple" that
 transfer length or end pointer with the head pointer does not fit the C design.
 If added it should have been done as a struct and to make that work you would
 have to add operator overloading. There's an avalanche effect of features and
 additional language design issues there.

 I think K&R deserves credit for being able to say no and stay minimal, I think
 the Go team deserves the same credit. As you've experienced with D, saying no
is
 hard because there are often good arguments for features being useful and
 difficult to say in advance with certainty what kind of avalanche effect adding
 features have (in terms of semantics, special casing and new needs for
 additional support/features, time to complete implementation/debugging). So
 saying no until practice shows that a feature is sorely missed is a sign of
good
 language design practice.

 The industry wanted portability and high speed and insisted moving as a flock
 after C and BLINDLY after C++. Seriously, the media frenzy around C++ was
 hysterical despite C++ being a bad design from the start. The C++ media noise
 was worse than with Java IIRC. Media are incredibly shallow when they are
trying
 to sell mags/books based on the "next big thing" and they can accelerate
 adoption beyond merits. Which both C++ and Java are two good examples of.

 There were alternatives such as Turbo Pascal, Modula-2/3, Simula, Beta, ML,
 Eiffel, Delphi and many more. Yet, programmers thought C was cool because it
was
 "portable assembly" and "industry standard" and "fast" and "safe bet". So they
 were happy with it, because C compiler emitted fast code. And fast was more
 important to them than safe. Well, they got what they deserved, right?

 Not adding additional features is not a design mistake if you try hard to stay
 minimal and don't claim to support high level programming. The mistake is in
 using a tool as if it supports something it does not.

 You might be right that K&R set the bar too high for adding extra features. Yet
 others might be right that D has been too willing to add features. As you know,
 the perfect balance is difficult to find and it is dependent on the use
context,
 so it materialize after the fact (after implementation). And C's use context
has
 expanded way beyond the original use context where people were not afraid to
 write assembly.

 (But the incomprehensible typing notation for function pointers was a design
 mistake since that was a feature of the language.)


I'm sorry to say this, but these rationalizations as to why C cannot add a 
trivial enhancement that takes nothing away and solves most of the buffer 
overflow problems leaves me shaking my head.

(C has added useless enhancements, like VLAs.)
Nov 18 2014
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d wrote:
[...]

 I'm sorry to say this, but these rationalizations as to why C cannot
 add a trivial enhancement that takes nothing away and solves most of
 the buffer overflow problems leaves me shaking my head.
 
 (C has added useless enhancements, like VLAs.)


What's the trivial thing that will solve most buffer overflow problems?


T

-- 
Dogs have owners ... cats have staff. -- Krista Casada
Nov 18 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:

 On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d
wrote:

 I'm sorry to say this, but these rationalizations as to why C cannot
 add a trivial enhancement that takes nothing away and solves most of
 the buffer overflow problems leaves me shaking my head.


 What's the trivial thing that will solve most buffer overflow problems?


http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625
Nov 18 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Nov 18, 2014 at 12:44:35PM -0800, Walter Bright via Digitalmars-d wrote:

 On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:

On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d wrote:

I'm sorry to say this, but these rationalizations as to why C cannot
add a trivial enhancement that takes nothing away and solves most of
the buffer overflow problems leaves me shaking my head.


What's the trivial thing that will solve most buffer overflow
problems?


 
 http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625


That's not a trivial change at all -- it will break pretty much every C
program there is out there. Just think of how much existing C code
relies on this conflation between arrays and pointers, and implicit
conversions between them.

Once you start going down that path, you might as well just start over
with a brand new language. Which ultimately leads to D. :-P


T

-- 
Microsoft is to operating systems & security ... what McDonalds is to gourmet
cooking.
Nov 18 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2014 1:12 PM, H. S. Teoh via Digitalmars-d wrote:

 On Tue, Nov 18, 2014 at 12:44:35PM -0800, Walter Bright via Digitalmars-d
wrote:

 On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:

 On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d
wrote:

 I'm sorry to say this, but these rationalizations as to why C cannot
 add a trivial enhancement that takes nothing away and solves most of
 the buffer overflow problems leaves me shaking my head.


 What's the trivial thing that will solve most buffer overflow
 problems?


 http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625


 That's not a trivial change at all -- it will break pretty much every C
 program there is out there. Just think of how much existing C code
 relies on this conflation between arrays and pointers, and implicit
 conversions between them.


No, I proposed a new syntax that would have different behavior:

   void foo(char a[..])
Nov 18 2014
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Tue, Nov 18, 2014 at 02:14:20PM -0800, Walter Bright via Digitalmars-d wrote:

 On 11/18/2014 1:12 PM, H. S. Teoh via Digitalmars-d wrote:

On Tue, Nov 18, 2014 at 12:44:35PM -0800, Walter Bright via Digitalmars-d wrote:

On 11/18/2014 12:10 PM, H. S. Teoh via Digitalmars-d wrote:

On Tue, Nov 18, 2014 at 11:45:13AM -0800, Walter Bright via Digitalmars-d wrote:

I'm sorry to say this, but these rationalizations as to why C
cannot add a trivial enhancement that takes nothing away and
solves most of the buffer overflow problems leaves me shaking my
head.


What's the trivial thing that will solve most buffer overflow
problems?


http://www.drdobbs.com/architecture-and-design/cs-biggest-mistake/228701625


That's not a trivial change at all -- it will break pretty much every
C program there is out there. Just think of how much existing C code
relies on this conflation between arrays and pointers, and implicit
conversions between them.


 
 No, I proposed a new syntax that would have different behavior:
 
   void foo(char a[..])


Ah, I see. How would that be different from just declaring an array
struct and using it pervasively? Existing C code would not benefit from
such an addition without a lot of effort put into refactoring.


T

-- 
If you look at a thing nine hundred and ninety-nine times, you are perfectly
safe; if you look at it the thousandth time, you are in frightful danger of
seeing it for the first time. -- G. K. Chesterton
Nov 18 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2014 2:35 PM, H. S. Teoh via Digitalmars-d wrote:

 On Tue, Nov 18, 2014 at 02:14:20PM -0800, Walter Bright via Digitalmars-d
wrote:

 On 11/18/2014 1:12 PM, H. S. Teoh via Digitalmars-d wrote:
 No, I proposed a new syntax that would have different behavior:

    void foo(char a[..])


 Ah, I see. How would that be different from just declaring an array
 struct and using it pervasively?


   foo("string");

won't work using a struct parameter.



 Existing C code would not benefit from
 such an addition without a lot of effort put into refactoring.


Except that the syntax is not viral and can be done as convenient. And, as 
mentioned in the article, people do make the effort to do other, much more 
complicated, schemes.
Nov 18 2014
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 18 November 2014 at 19:45:12 UTC, Walter Bright wrote:

 On 11/18/2014 3:15 AM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Tuesday, 18 November 2014 at 02:35:41 UTC, Walter Bright 
 wrote:

 C is a brilliant language. That doesn't mean it hasn't made 
 serious mistakes
 in its design. The array decay and 0 strings have proven to 
 be very costly to
 programmers over the decades.


 I'd rather say that it is the industry that has 
 misappropriated C, which in my
 view basically was "typed portable assembly" with very little 
 builtin
 presumptions by design. This is important when getting control 
 over layout, and
 this transparency is a quality that only C gives me. BCPL 
 might be considered to
 have more presumptions (such as string length), being a 
 minimal "bootstrapping
 subset" of CPL.

 You always had the ability in C to implement arrays as a 
 variable sized struct
 with a length and a trailing data section, so I'd say that the 
 C provided type
 safe variable length arrays. Many people don't use it. Many 
 people don't know
 how to use it. Ok, but then they don't understand that they 
 are programming in a
 low level language and are responsible for creating their own 
 environment. I
 think C's standard lib mistakingly created an illusion of high 
 level programming
 that the language only partially supported.

 Adding the ability to transfer structs by value as a parameter 
 was probably not
 worth the implementation cost at the time… Having a "magic 
 struct/tuple" that
 transfer length or end pointer with the head pointer does not 
 fit the C design.
 If added it should have been done as a struct and to make that 
 work you would
 have to add operator overloading. There's an avalanche effect 
 of features and
 additional language design issues there.

 I think K&R deserves credit for being able to say no and stay 
 minimal, I think
 the Go team deserves the same credit. As you've experienced 
 with D, saying no is
 hard because there are often good arguments for features being 
 useful and
 difficult to say in advance with certainty what kind of 
 avalanche effect adding
 features have (in terms of semantics, special casing and new 
 needs for
 additional support/features, time to complete 
 implementation/debugging). So
 saying no until practice shows that a feature is sorely missed 
 is a sign of good
 language design practice.

 The industry wanted portability and high speed and insisted 
 moving as a flock
 after C and BLINDLY after C++. Seriously, the media frenzy 
 around C++ was
 hysterical despite C++ being a bad design from the start. The 
 C++ media noise
 was worse than with Java IIRC. Media are incredibly shallow 
 when they are trying
 to sell mags/books based on the "next big thing" and they can 
 accelerate
 adoption beyond merits. Which both C++ and Java are two good 
 examples of.

 There were alternatives such as Turbo Pascal, Modula-2/3, 
 Simula, Beta, ML,
 Eiffel, Delphi and many more. Yet, programmers thought C was 
 cool because it was
 "portable assembly" and "industry standard" and "fast" and 
 "safe bet". So they
 were happy with it, because C compiler emitted fast code. And 
 fast was more
 important to them than safe. Well, they got what they 
 deserved, right?

 Not adding additional features is not a design mistake if you 
 try hard to stay
 minimal and don't claim to support high level programming. The 
 mistake is in
 using a tool as if it supports something it does not.

 You might be right that K&R set the bar too high for adding 
 extra features. Yet
 others might be right that D has been too willing to add 
 features. As you know,
 the perfect balance is difficult to find and it is dependent 
 on the use context,
 so it materialize after the fact (after implementation). And 
 C's use context has
 expanded way beyond the original use context where people were 
 not afraid to
 write assembly.

 (But the incomprehensible typing notation for function 
 pointers was a design
 mistake since that was a feature of the language.)


 I'm sorry to say this, but these rationalizations as to why C 
 cannot add a trivial enhancement that takes nothing away and 
 solves most of the buffer overflow problems leaves me shaking 
 my head.

 (C has added useless enhancements, like VLAs.)


So useless that it became optional in C11.

https://groups.google.com/forum/#!topic/comp.std.c/AoB6LFHcd88
Nov 18 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2014 12:53 PM, Paulo Pinto wrote:

 On Tuesday, 18 November 2014 at 19:45:12 UTC, Walter Bright wrote:

 (C has added useless enhancements, like VLAs.)


 So useless that it became optional in C11.

 https://groups.google.com/forum/#!topic/comp.std.c/AoB6LFHcd88


Note the Rationale given:

---

- Putting arbitrarily large arrays on the stack causes trouble
in multithreaded programs in implementations where stack growth
is bounded.

- There's no way to recover from an out-of-memory condition when
allocating a VLA.

- Microsoft declines to support them.

- VLAs aren't used much.  There appear to be only three in
Google Code, and no VLA parameters. The Linux kernel had one,
but it was taken out because there was no way to handle an
out of space condition.  (If anyone can find an example of
a VLA parameter in publicly visible production code, please
let me know.)

- The semantics of VLA parameters is painful.  They're
automatically reduced to pointers, with the length information
lost.  "sizeof" returns the size of a pointer.

- Prototypes of functions with VLA parameters do not have
to exactly match the function definition. This is
incompatible with C++ style linkage and C++ function
overloading, preventing the extension of this feature
into C++.

                         John Nagle
Nov 18 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 18 November 2014 at 19:45:12 UTC, Walter Bright wrote:

 I'm sorry to say this, but these rationalizations as to why C 
 cannot add a trivial enhancement that takes nothing away and


They can add whatever they want.

I am arguing against the position that it was a design mistake to 
keep the semantic model simple and with few presumptions. On the 
contrary, it was the design goal. Another goal for a language 
like C is ease of implementation so that you can easily port it 
to new hardware.

The original C was a very simple language. Most decent 
programmers can create their own C-compiler (but not a good 
optimizer).


 (C has added useless enhancements, like VLAs.)


VLAs have been available in gcc for a long time. They are not 
useless, I've used them from time to time.
Nov 18 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2014 1:23 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 I am arguing against the position that it was a design mistake to keep the
 semantic model simple and with few presumptions. On the contrary, it was the
 design goal. Another goal for a language like C is ease of implementation so
 that you can easily port it to new hardware.


The proposals I made do not change that in any way, and if K&R designed C 
without those mistakes, it would have not made C more complex in the slightest.



 VLAs have been available in gcc for a long time. They are not useless, I've
used
 them from time to time.


I know you're simply being argumentative when you defend VLAs, a complex and 
useless feature, and denigrate simple ptr/length pairs as complicated.
Nov 18 2014
parent reply "Alo Miehsof =?UTF-8?B?RGF0c8O4cmci?= writes:
On Tuesday, 18 November 2014 at 23:48:27 UTC, Walter Bright wrote:

 On 11/18/2014 1:23 PM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 I am arguing against the position that it was a design mistake 
 to keep the
 semantic model simple and with few presumptions. On the 
 contrary, it was the
 design goal. Another goal for a language like C is ease of 
 implementation so
 that you can easily port it to new hardware.


 The proposals I made do not change that in any way, and if K&R 
 designed C without those mistakes, it would have not made C 
 more complex in the slightest.



 VLAs have been available in gcc for a long time. They are not 
 useless, I've used
 them from time to time.


 I know you're simply being argumentative when you defend VLAs, 
 a complex and useless feature, and denigrate simple ptr/length 
 pairs as complicated.


Argumentative ?!! More like a fucking gaping fucking asshole. His
posts are the blight of this group.
Nov 18 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 19 November 2014 at 01:35:19 UTC, Alo Miehsof 
Datsørg wrote:

 Argumentative ?!! More like a fucking gaping fucking asshole. 
 His
 posts are the blight of this group.


If you are going ad hominem, please post under your own name. I 
never go ad hominem, and therefore your response will achieve the 
exact opposite of what you are trying to achieve to ensure that 
ad hominem does not become an acceptable line of action.
Nov 19 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/18/2014 5:35 PM, "Alo Miehsof Datsørg" 
<Ola.Fosheim.Grostad sucks.goat.ass>" wrote:

 Argumentative ?!! More like a fucking gaping fucking asshole. His
 posts are the blight of this group.


Rude posts are not welcome here.
Nov 20 2014
prev sibling parent "uri" <uri.grill gmail.com> writes:
On Wednesday, 19 November 2014 at 01:35:19 UTC, Alo Miehsof 
Datsørg wrote:

 On Tuesday, 18 November 2014 at 23:48:27 UTC, Walter Bright 
 wrote:

 On 11/18/2014 1:23 PM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 I am arguing against the position that it was a design 
 mistake to keep the
 semantic model simple and with few presumptions. On the 
 contrary, it was the
 design goal. Another goal for a language like C is ease of 
 implementation so
 that you can easily port it to new hardware.


 The proposals I made do not change that in any way, and if K&R 
 designed C without those mistakes, it would have not made C 
 more complex in the slightest.



 VLAs have been available in gcc for a long time. They are not 
 useless, I've used
 them from time to time.


 I know you're simply being argumentative when you defend VLAs, 
 a complex and useless feature, and denigrate simple ptr/length 
 pairs as complicated.


 Argumentative ?!! More like a fucking gaping fucking asshole. 
 His
 posts are the blight of this group.


Wow that's uncalled for.

I don't always agree with Ola but his posts are rarely uninformed 
and often backed up with actual code examples or links supoprting 
his arguments. They generally lead to very interesting 
discussions on the forum.

Cheers,
uri
Nov 20 2014
prev sibling parent reply "Alo Miehsof =?UTF-8?B?RGF0c8O4cmci?= writes:
On Monday, 17 November 2014 at 19:24:49 UTC, Walter Bright wrote:

 On 11/17/2014 3:00 AM, "Ola Fosheim Grøstad" 
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 I am saying
 that when you have <32KiB RAM total it makes sense to save 
 space by not storing
 the string length.


 I know what you're saying.

 You're saying without evidence that sentinels are faster. They 
 are not.
 You're saying without evidence that 0 terminated strings use 
 less memory. They do not.

 (It does not save space when "filename" and "filename.ext" 
 cannot be overlapped.)


Stop wasting time with the mouth breather.
Nov 17 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Tuesday, 18 November 2014 at 04:58:43 UTC, Anonymous Coward 
wrote:

 Stop wasting time with the mouth breather.


Please write under your full name.
Nov 18 2014
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 16.11.2014 um 20:59 schrieb "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>":

 On Sunday, 16 November 2014 at 19:24:47 UTC, Walter Bright wrote:

 This made C far, far more difficult and buggy to work with than it
 should have been.


 Depends on your view of C, if you view C as step above assembly then it
 makes sense to treat everything as pointers. It is a bit confusing in
 the beginning since it is more or less unique to C.


My view is of a "kind of" portable macro assembler, even MASM and TASM 
were more feature rich back in the day.

Actually I remember reading a DDJ article about a Texas Instruments 
Assembler that looked like C, just with one simple expression per line.

So you could not do

a = b + c * 4;

rather

r0 = b
r1 = c
r1 *= 4
r0 += r1

Just an idea, I don't remember any longer how it actually was.


--
Paulo
Nov 16 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 16 November 2014 at 22:19:16 UTC, Paulo Pinto wrote:

 My view is of a "kind of" portable macro assembler, even MASM 
 and TASM were more feature rich back in the day.

 Actually I remember reading a DDJ article about a Texas 
 Instruments Assembler that looked like C, just with one simple 
 expression per line.

 So you could not do

 a = b + c * 4;

 rather

 r0 = b
 r1 = c
 r1 *= 4
 r0 += r1

 Just an idea, I don't remember any longer how it actually was.


Not such a bad idea if you can blend it with regular assembly 
mnemonics. When I did the course in machine near programming 
university I believe I chose to do the exam in Motorola 68000 
machine language because I found it no harder than C at the 
time…(?) I surely would not have done the same with the x86 
instruction set though.
Nov 16 2014
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 16 November 2014 at 11:30:01 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 16 November 2014 at 03:27:54 UTC, Walter Bright 
 wrote:

 On 11/14/2014 4:32 PM, deadalnix wrote:

 To quote the guy from the PL for video games video serie, a 
 85%
 solution often is preferable.


 Spoken like a true engineer!


 More like a consultant for self-help:

 http://www.amazon.com/85%25-Solution-Personal-Accountability-Guarantees/dp/0470500166


 Real world 85% engineered solutions:

 1. Titanic
 2. Chernobyl
 3. Challenger
 4. C++
 …


Sorry but that is dumb, and the fact you are on the D newsgroup 
rather on 100% solution languages newsgroup (Java is 100% OOP, 
Haskell is 100% functional, Rust is 100% linear types, Javascript 
is 100% callbacks, erlang is 100% concurrent, LISP is 100% meta, 
BASIC is 100% imperative, python is 100% slow, PHP 100% 
inconsistent) tells me that not even you believe in your own 
bullshit.
Nov 16 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Sunday, 16 November 2014 at 22:55:54 UTC, deadalnix wrote:

 Sorry but that is dumb, and the fact you are on the D newsgroup 
 rather on 100% solution languages newsgroup (Java is 100% OOP, 
 Haskell is 100% functional, Rust is 100% linear types, 
 Javascript is 100% callbacks, erlang is 100% concurrent, LISP 
 is 100% meta, BASIC is 100% imperative, python is 100% slow, 
 PHP 100% inconsistent) tells me that not even you believe in 
 your own bullshit.


Define what you mean by 100%? By 100% I mean that you can 
implement your system level design without bending it around 
special cases induced by the language.

The term "85% solution" is used for implying that it only 
provides a solution to 85% of what you want to achieve (like a 
framework) and that you have to change your goals or go down a 
painful path to get the last 15%.

ASM is 100% (or 0%). You can do anything the hardware supports.

C is close to 98%. You can easily get the last 2% by writing asm.



HTML5/JS is 80%. You can do certain things efficiently, but other 
things are plain difficult.

Flash/ActionScript is 60%. …

What Jonathan Blunt apparently wants is a language that is 
tailored to the typical patterns seen in games programming, so 
that might mean that e.g. certain allocation patterns are 
supported, but others not. (Leaving out the 15% that is not used 
in games programming). This is characteristic of programming 
frameworks.

I think it is reasonable to push back when D is moving towards 
becoming a framework. There are at least two factions in the D 
community. One faction is looking for an application framework 
and the other faction is looking for a low level programming 
language.

These two perspectives are not fully compatible.
Nov 16 2014
prev sibling parent reply "Max Samukha" <maxsamukha gmail.com> writes:
On Sunday, 16 November 2014 at 03:27:54 UTC, Walter Bright wrote:

 On 11/14/2014 4:32 PM, deadalnix wrote:

 To quote the guy from the PL for video games video serie, a 85%
 solution often is preferable.


 Spoken like a true engineer!


85% often means being at the bottom of the uncanny valey. 65% or 
95% are more preferable.
Nov 20 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 20 November 2014 at 10:24:30 UTC, Max Samukha wrote:

 On Sunday, 16 November 2014 at 03:27:54 UTC, Walter Bright 
 wrote:

 On 11/14/2014 4:32 PM, deadalnix wrote:

 To quote the guy from the PL for video games video serie, a 
 85%
 solution often is preferable.


 Spoken like a true engineer!


 85% often means being at the bottom of the uncanny valey. 65% 
 or 95% are more preferable.


85% is an image rather than an exact number. The point being,
every construct are good at some thing, and bad at other. Making
them capable of doing everything come at a great complexity cost,
so it is preferable to aim for a solution that cope well with
most use cases, and provide alternative solutions for the
horrible cases.

Many language make the mistake of thinking something is the holly
grail, be it OOP, functional programming or linear types. I do
think that it is a better engineering solution to provide a
decent support for all of theses, and doing so we don't need to
get them handle 100% of the case, as we have other language
construct/paradigm that suit better difficult cases anyway.
Nov 20 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 20 November 2014 at 20:15:03 UTC, deadalnix wrote:

 Many language make the mistake of thinking something is the 
 holly
 grail, be it OOP, functional programming or linear types. I do
 think that it is a better engineering solution to provide a
 decent support for all of theses, and doing so we don't need to
 get them handle 100% of the case, as we have other language
 construct/paradigm that suit better difficult cases anyway.


FWIW, among language designers it is usually considered a 
desirable trait to have orthogonality between constructs and let 
them be combinable in expressive ways. This reduce the burden on 
the user who then only have to truly understand the key concepts 
to build a clear mental image of the semantic model. Then you can 
figure out ways to add syntactical sugar if needed.

Having a smaller set of basic constructs makes it easier to prove 
correctness, which turn is important for optimization (which 
depends on the ability to prove equivalence over the pre/post 
semantics). It makes it easier to prove properties such as 
" (un)safe". It also makes it easier to later extend the language.

Just think about all the areas "fibers" in D affect. It affects 
garbage collection and memory handling. It affects the ability to 
do deep semantic analysis. It affects implementation of fast 
multi-threaded ADTs. One innocent feature can have a great impact.

Providing a 70% solution like Go is fine as they have defined a 
narrow domain for the language, servers, thus as a programmer you 
don't hit the 30% they left out.

But D has not defined narrow use domain, so as a designer you 
cannot make up a good rationale for which 15-30% to leave out. 
Design is always related to a specific use scenario.

(I like the uncanny valley metaphor, had not thought about using 
it outside 3D. Cool association!)
Nov 20 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 20 November 2014 at 21:26:18 UTC, Ola Fosheim
Grøstad wrote:

 On Thursday, 20 November 2014 at 20:15:03 UTC, deadalnix wrote:

 Many language make the mistake of thinking something is the 
 holly
 grail, be it OOP, functional programming or linear types. I do
 think that it is a better engineering solution to provide a
 decent support for all of theses, and doing so we don't need to
 get them handle 100% of the case, as we have other language
 construct/paradigm that suit better difficult cases anyway.


 FWIW, among language designers it is usually considered a 
 desirable trait to have orthogonality between constructs and 
 let them be combinable in expressive ways. This reduce the 
 burden on the user who then only have to truly understand the 
 key concepts to build a clear mental image of the semantic 
 model. Then you can figure out ways to add syntactical sugar if 
 needed.

 Having a smaller set of basic constructs makes it easier to 
 prove correctness, which turn is important for optimization 
 (which depends on the ability to prove equivalence over the 
 pre/post semantics). It makes it easier to prove properties 
 such as " (un)safe". It also makes it easier to later extend 
 the language.

 Just think about all the areas "fibers" in D affect. It affects 
 garbage collection and memory handling. It affects the ability 
 to do deep semantic analysis. It affects implementation of fast 
 multi-threaded ADTs. One innocent feature can have a great 
 impact.

 Providing a 70% solution like Go is fine as they have defined a 
 narrow domain for the language, servers, thus as a programmer 
 you don't hit the 30% they left out.

 But D has not defined narrow use domain, so as a designer you 
 cannot make up a good rationale for which 15-30% to leave out. 
 Design is always related to a specific use scenario.

 (I like the uncanny valley metaphor, had not thought about 
 using it outside 3D. Cool association!)


All of this is beautiful until you try to implement a quicksort
in, haskell.

It is not that functional programming is bad (I actually like it
a lot) but there are problem where it is simply the wrong tool.
Once you acknowledge that, you have 2 road forward :
   - You create bizarre features to implement quicksort in a
functional way. Tge concept become more complex, but some expert
guru will secure their job.
   - Keep your functional feature as they are, but allow for other
styles, which cope better with quicksort.

The situation 2 is the practical one. There is no point in
creating an ackward hammer that can also screw things if I can
have a hammer and a screwdriver.

Obviously, this has a major drawback in the fact you cannot say
to everybody that your favorite style is the one true thing that
everybody must use. That is a real bummer for religious zealot,
but actual engineers understand that this is a feature, not a bug.
Nov 20 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 20 November 2014 at 21:55:16 UTC, deadalnix wrote:

 All of this is beautiful until you try to implement a quicksort
 in, haskell.

 It is not that functional programming is bad (I actually like it
 a lot) but there are problem where it is simply the wrong tool.


Sure, I am not arguing in favour of functional programming. But 
it is possible to define a tight core language (or VM) with the 
understanding that all other "high level" constructs have to be 
expressed within that core language in the compiler internals. 
Then you can do all the analysis on that small critical subset of 
constructs. With this approach you can create/modify all kinds of 
convenience features without affect the core semantics that keeps 
it sounds and clean.

Take for instance the concept of isolates, which I believe we 
both think can be useful. If the concept of an 
isolated-group-of-objects it is taken to the abstract level and 
married to a simple core language (or VM) in a sound way, then 
the more complicated stuff can hopefully be built on top of it. 
So you get a bottom-up approach to the language that meets the 
end user. Rather than what happens now where feature requests 
seem to be piled on top-down, they ought to be "digested" into 
something that can grow bottom-up. I believe this is what you try 
to do with your GC proposal.


 Obviously, this has a major drawback in the fact you cannot say
 to everybody that your favorite style is the one true thing that
 everybody must use. That is a real bummer for religious zealot,
 but actual engineers understand that this is a feature, not a 
 bug.


Well, I think this holds:

1. Good language creation goes bottom-up.
2. Good language evaluation goes top-down.
3. Good language design is a circular process between 1  and 2.

In essence having a tight "engine" is important (the bottom), but 
you also need to understand the use context and how it will be 
used (the top).

In D the bottom-part is not so clear and could need a cleanup, 
but then the community would have to accept the effects of that 
propagate to the top.

Without defining some use contexts for the language I think the 
debates get very long, because without "data" you cannot do 
"analysis" and then you end up with "feels right to me" and that 
is not engineering, it is art or what you are used to. And, there 
are more good engineers in the world than good artists…

If one can define a single use scenario that is demanding enough 
to ensure that an evaluation against that scenario also will work 
for the other less demanding scenarios, then maybe some more 
rational discussions about the direction of D as language could 
be possible and you could leave out say the 10% that are less 
useful. When everybody argues out from their own line of work and 
habits… then they talk past each other.
Nov 20 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
You are a goalspot shifting champion, aren't you ?
Nov 20 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 20 November 2014 at 23:22:40 UTC, deadalnix wrote:

 You are a goalspot shifting champion, aren't you ?


Nope, it follows up your line of argument, but the 
screwdriver/hammer metaphor is not a good one.

You can implement your hammer and your screwdriver at the top if 
you have a lower level screwdriver/hammer-components at the 
bottom. That is the good.

Piling together hammers and screwdrivers and hoping that nobody 
are going to miss the remaining 35% involving glue and tape… That 
is bad.
Nov 20 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2014 1:55 PM, deadalnix wrote:

 All of this is beautiful until you try to implement a quicksort
 in, haskell.

 It is not that functional programming is bad (I actually like it
 a lot) but there are problem where it is simply the wrong tool.
 Once you acknowledge that, you have 2 road forward :
    - You create bizarre features to implement quicksort in a
 functional way. Tge concept become more complex, but some expert
 guru will secure their job.
    - Keep your functional feature as they are, but allow for other
 styles, which cope better with quicksort.

 The situation 2 is the practical one. There is no point in
 creating an ackward hammer that can also screw things if I can
 have a hammer and a screwdriver.

 Obviously, this has a major drawback in the fact you cannot say
 to everybody that your favorite style is the one true thing that
 everybody must use. That is a real bummer for religious zealot,
 but actual engineers understand that this is a feature, not a bug.


Monads!
Nov 20 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 20 November 2014 at 22:47:27 UTC, Walter Bright 
wrote:

 On 11/20/2014 1:55 PM, deadalnix wrote:

 All of this is beautiful until you try to implement a quicksort
 in, haskell.




[…]


 Monads!


I think Deadalnix meant that you cannot do in-place quicksort 
easily in Haskell. Non-mutating quicksort is easy, no need for 
monads:

quicksort []     = []
quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort 
greater)
     where
         lesser  = filter (< p) xs
         greater = filter (>= p) xs

https://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell
Nov 20 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2014 3:10 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 20 November 2014 at 22:47:27 UTC, Walter Bright wrote:

 On 11/20/2014 1:55 PM, deadalnix wrote:

 All of this is beautiful until you try to implement a quicksort
 in, haskell.




 […]


 Monads!


 I think Deadalnix meant that you cannot do in-place quicksort easily in
Haskell.


That's correct.


 Non-mutating quicksort is easy, no need for monads:

 quicksort []     = []
 quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
      where
          lesser  = filter (< p) xs
          greater = filter (>= p) xs

 https://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell


Except that isn't really quicksort. Monads are the workaround functional 
languages use to deal with things that need mutation.
Nov 20 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 21 November 2014 at 01:09:27 UTC, Walter Bright wrote:

 Except that isn't really quicksort. Monads are the workaround 
 functional languages use to deal with things that need mutation.


Yes, at least in Haskell, but I find monads in Haskell harder to 
read than regular imperative code. You can apparently cheat a 
little using libraries, this doesn't look too bad (from slashdot):

import qualified Data.Vector.Generic as V
import qualified Data.Vector.Generic.Mutable as M

qsort :: (V.Vector v a, Ord a) => v a -> v a
qsort = V.modify go where
     go xs | M.length xs < 2 = return ()
           | otherwise = do
             p <- M.read xs (M.length xs `div` 2)
             j <- M.unstablePartition (< p) xs
             let (l, pr) = M.splitAt j xs
             k <- M.unstablePartition (== p) pr
             go l; go $ M.drop k pr


http://stackoverflow.com/questions/7717691/why-is-the-minimalist-example-haskell-quicksort-not-a-true-quicksort
Nov 20 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/20/2014 5:27 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Friday, 21 November 2014 at 01:09:27 UTC, Walter Bright wrote:

 Except that isn't really quicksort. Monads are the workaround functional
 languages use to deal with things that need mutation.


 Yes, at least in Haskell, but I find monads in Haskell harder to read than
 regular imperative code.


Exactly my point (and I presume deadalnix's, too).
Nov 20 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/20/14 5:09 PM, Walter Bright wrote:

 On 11/20/2014 3:10 PM, "Ola Fosheim Grøstad"
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 20 November 2014 at 22:47:27 UTC, Walter Bright wrote:

 On 11/20/2014 1:55 PM, deadalnix wrote:

 All of this is beautiful until you try to implement a quicksort
 in, haskell.




 […]


 Monads!


 I think Deadalnix meant that you cannot do in-place quicksort easily
 in Haskell.


 That's correct.


 Non-mutating quicksort is easy, no need for monads:

 quicksort []     = []
 quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
      where
          lesser  = filter (< p) xs
          greater = filter (>= p) xs

 https://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell


 Except that isn't really quicksort. Monads are the workaround functional
 languages use to deal with things that need mutation.


As I like to say, this troika has inflicted a lot of damage on both FP 
and those beginning to learn it:

* Linear-space factorial
* Doubly exponential Fibonacci
* (Non)Quicksort

These losers appear with depressing frequency in FP introductory texts.


Andrei
Nov 20 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Friday, 21 November 2014 at 02:56:09 UTC, Andrei Alexandrescu 
wrote:

 On 11/20/14 5:09 PM, Walter Bright wrote:

 On 11/20/2014 3:10 PM, "Ola Fosheim Grøstad"
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 20 November 2014 at 22:47:27 UTC, Walter Bright 
 wrote:

 On 11/20/2014 1:55 PM, deadalnix wrote:

 All of this is beautiful until you try to implement a 
 quicksort
 in, haskell.




 […]


 Monads!


 I think Deadalnix meant that you cannot do in-place quicksort 
 easily
 in Haskell.


 That's correct.


 Non-mutating quicksort is easy, no need for monads:

 quicksort []     = []
 quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort 
 greater)
     where
         lesser  = filter (< p) xs
         greater = filter (>= p) xs

 https://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell


 Except that isn't really quicksort. Monads are the workaround 
 functional
 languages use to deal with things that need mutation.


 As I like to say, this troika has inflicted a lot of damage on 
 both FP and those beginning to learn it:

 * Linear-space factorial
 * Doubly exponential Fibonacci
 * (Non)Quicksort

 These losers appear with depressing frequency in FP 
 introductory texts.


 Andrei


Just like the OOP introductory books that still insist in talking 
about Cars and Vehicles, Managers and Employees, Animals and 
Bees, always using inheritance as code reuse.

Barely talking about is-a and has-a, and all the issues about 
fragile base classes.

--
Paulo
Nov 21 2014
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/21/14 12:17 AM, Paulo Pinto wrote:

 On Friday, 21 November 2014 at 02:56:09 UTC, Andrei Alexandrescu wrote:

 On 11/20/14 5:09 PM, Walter Bright wrote:

 On 11/20/2014 3:10 PM, "Ola Fosheim Grøstad"
 <ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Thursday, 20 November 2014 at 22:47:27 UTC, Walter Bright wrote:

 On 11/20/2014 1:55 PM, deadalnix wrote:

 All of this is beautiful until you try to implement a quicksort
 in, haskell.




 […]


 Monads!


 I think Deadalnix meant that you cannot do in-place quicksort easily
 in Haskell.


 That's correct.


 Non-mutating quicksort is easy, no need for monads:

 quicksort []     = []
 quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater)
     where
         lesser  = filter (< p) xs
         greater = filter (>= p) xs

 https://www.haskell.org/haskellwiki/Introduction#Quicksort_in_Haskell


 Except that isn't really quicksort. Monads are the workaround functional
 languages use to deal with things that need mutation.


 As I like to say, this troika has inflicted a lot of damage on both FP
 and those beginning to learn it:

 * Linear-space factorial
 * Doubly exponential Fibonacci
 * (Non)Quicksort

 These losers appear with depressing frequency in FP introductory texts.


 Andrei


 Just like the OOP introductory books that still insist in talking about
 Cars and Vehicles, Managers and Employees, Animals and Bees, always
 using inheritance as code reuse.


The first public example found by google (oop introduction) lists a 
class Student as the first example of a class:

http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-Programming-Concep#Object

and IOException inheriting Exception as the first example of inheritance:

http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-Programming-Concep#Inheritance

First example for overriding is Complex.ToString:

http://www.codeproject.com/Articles/22769/Introduction-to-Object-Oriented-Programming-Concep#Overloading


 Barely talking about is-a and has-a, and all the issues about fragile
 base classes.


Even to the extent those old texts have persisted, they are "only" poor 
style. In contrast, the three FP example I mentioned are computationally 
bankrupt. There is really no excuse for teaching them.


Andrei
Nov 21 2014
prev sibling parent reply "Abdulhaq" <alynch4047 gmail.com> writes:
 Just like the OOP introductory books that still insist in 
 talking about Cars and Vehicles, Managers and Employees, 
 Animals and Bees, always using inheritance as code reuse.

 Barely talking about is-a and has-a, and all the issues about 
 fragile base classes.

 --
 Paulo


Hear, hear. One of the problems with many introductions to 
OOP-paradigmed languages such as C++ is that by having to spend a 
lot of time explaining how to implement inheritance, the novice 
reader thinks that OOP is the 'right' approach to solving many 
problems when in fact other techniques ('prefer composition over 
inheritance' springs to mind) are far more appropriate. This is 
one of the primary problems I find in code of even more 
experienced programmers.
Nov 21 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 21 November 2014 at 16:07:20 UTC, Abdulhaq wrote:

 Hear, hear. One of the problems with many introductions to 
 OOP-paradigmed languages such as C++ is that by having to spend 
 a lot of time explaining how to implement inheritance, the 
 novice reader thinks that OOP is the 'right' approach to 
 solving many problems when in fact other techniques ('prefer 
 composition over inheritance' springs to mind) are far more 
 appropriate. This is one of the primary problems I find in code 
 of even more experienced programmers.


Yes, the problem is that you should not teach OOP, but object 
oriented analysis and object oriented modelling in a language 
agnostic fashion… but you need to touch both structured and 
object oriented programming first to create motivation in the 
student for learning analysis and modelling…

The same goes for performance and complexity. You should only 
cover structured programming/abstraction in the first programming 
course with no hindsight to performance, then touch performance 
and algorithmic complexity in the second course, then do 
complexity proofs in an advanced course.

If a single course cover too much ground students get confused, 
the learning goals become hazy and you loose half your audience.
Nov 22 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 21 November 2014 at 02:56:09 UTC, Andrei Alexandrescu 
wrote:

 As I like to say, this troika has inflicted a lot of damage on 
 both FP and those beginning to learn it:

 * Linear-space factorial
 * Doubly exponential Fibonacci
 * (Non)Quicksort

 These losers appear with depressing frequency in FP 
 introductory texts.


Be careful with that attitude. It is an excellent strategy to 
start with the simple implementation and then move on to other 
techniques in later chapters or more advanced texts.

https://www.haskell.org/haskellwiki/The_Fibonacci_sequence
https://www.haskell.org/haskellwiki/Memoization

Some compilers are even capable of adding memoization/caching 
behind the scenes which brings naive fibonacci down to O(n) with 
no change in the source.

Also, keep in mind that non-mutating quick sort has the same 
space/time complexity as the mutating variant. The non-mutating 
variant is no doubt faster on massively parallel hardware. You 
can do quicksort on GPUs.

The landscape of performance and complexity is not so simple 
these days.
Nov 21 2014
prev sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 Except that isn't really quicksort. Monads are the workaround 
 functional languages use to deal with things that need mutation.


Take also a look at "Clean" language. It doesn't use monads and 
it's a very efficient functional language.

Bye,
bearophile
Nov 21 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via 
Digitalmars-d wrote:

 Are you guys saying you don't feel this proposal is practical?
 http://wiki.dlang.org/User:Schuetzm/scope

 I think it's a very interesting approach, and comes from a 
 practical
 point of view. It solves the long-standings issues, like scope 
 return
 values, in a very creative way.


It is better solved using static analysis and it is part of a 
bigger problem complex where ref counting should be considered. 
Otherwise you end up writing N versions of the same code. You 
want the same interface for GC, shared_ptr, unique_ptr, 
stack_allocated_data etc. Let the compiler do the checking.

What does "shared" tell the compiler? It tells it "retain no 
references after completion of this function". Like with "pure", 
it should be opposite. You should tell the compiler "I transfer 
ownership of this parameter". Then have a generic concept "owned" 
for parameters that is resolved using templates. Types that can 
be owned has to provide release() and move(). That would work for 
GC, shared_ptr, unique_ptr, but not for stack allocated data:

GC ptr: release() and move() are dummies.

shared_ptr: release() decrements, move() just transfers

unique_ptr: release() destroys, move() transfers

D has to stop adding crutches. Generalize!
Nov 13 2014
next sibling parent reply "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 13 November 2014 at 10:00:10 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 13 November 2014 at 09:29:22 UTC, Manu via 
 Digitalmars-d wrote:

 Are you guys saying you don't feel this proposal is practical?
 http://wiki.dlang.org/User:Schuetzm/scope

 I think it's a very interesting approach, and comes from a 
 practical
 point of view. It solves the long-standings issues, like scope 
 return
 values, in a very creative way.


 It is better solved using static analysis


You mean without additional hints by the programmer? That's not 
going to happen, realistically, for many reasons, separate 
compilation being one of them.


 and it is part of a bigger problem complex where ref counting 
 should be considered. Otherwise you end up writing N versions 
 of the same code. You want the same interface for GC, 
 shared_ptr, unique_ptr, stack_allocated_data etc. Let the 
 compiler do the checking.


Huh? That's exactly what _borrowing_ does. Ref-counting OTOH adds 
yet another reference type and thereby makes the situation worse.


 What does "shared" tell the compiler?


I guess you mean "scope"?


 It tells it "retain no references after completion of this 
 function". Like with "pure", it should be opposite. You should 
 tell the compiler "I transfer ownership of this parameter". 
 Then have a generic concept "owned" for parameters that is 
 resolved using templates.


That's what deadalnix's proposal does. Though I don't quite see 
what templates have to do with it.


 Types that can be owned has to provide release() and move(). 
 That would work for GC, shared_ptr, unique_ptr, but not for 
 stack allocated data:

 GC ptr: release() and move() are dummies.

 shared_ptr: release() decrements, move() just transfers

 unique_ptr: release() destroys, move() transfers


For a new language built from scratch, this might make sense. D 
is already existing, and needs to work with what it has.


 D has to stop adding crutches. Generalize!


That's what I'm trying to do with my proposal :-)
Nov 13 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz wrote:

 On Thursday, 13 November 2014 at 10:00:10 UTC, Ola Fosheim 
 Grøstad wrote:

 It is better solved using static analysis


 You mean without additional hints by the programmer? That's not 
 going to happen, realistically, for many reasons, separate 
 compilation being one of them.


I think it can happen. D needs a new intermediate layer where you 
can do global flow analysis.

compile src -> ast -> partial evaluation -> high level IR -> disk

instantiate high level IR -> intermediate IR -> disk

global analysis over  intermediate IR

intermediate IR -> LLVM -> asm


 Huh? That's exactly what _borrowing_ does. Ref-counting OTOH 
 adds yet another reference type and thereby makes the situation 
 worse.


I don't like explicit ref counting, but it is sometimes useful 
and I think Rust-style ownership is pretty close to unique_ptr 
which is ref-counting with a max count of 1… You can also view GC 
as being implicitly ref counted too (it is "counted" during 
collection).


 What does "shared" tell the compiler?


 I guess you mean "scope"?


:)


 It tells it "retain no references after completion of this 
 function". Like with "pure", it should be opposite. You should 
 tell the compiler "I transfer ownership of this parameter". 
 Then have a generic concept "owned" for parameters that is 
 resolved using templates.


 That's what deadalnix's proposal does. Though I don't quite see 
 what templates have to do with it.


My understanding of Deadalnix' proposal is that "owned" objects 
can only reference other "owned" objects. I think region 
allocators do better if you start constraining relations by 
ownership.


 For a new language built from scratch, this might make sense. D 
 is already existing, and needs to work with what it has.


D need to appropriate what C++ has and do it better. Basically it 
means integrating GC pointers with unique_ptr and shared_ptr.

If D is going to be stuck on what it has and "fix" it with addig 
crutches it will go nowhere, and C++ will start to look like a 
better option…
Nov 13 2014
next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 November 2014 20:38, via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz wrote:

 D need to appropriate what C++ has and do it better. Basically it means
 integrating GC pointers with unique_ptr and shared_ptr.

 If D is going to be stuck on what it has and "fix" it with addig crutches it
 will go nowhere, and C++ will start to look like a better option…


I don't follow how you associate that opinion with implementation of
scope. I think it's practical and important, and the point is the
opposite of what you say from my perspective.
scope is the best approach I've heard to address these differences in
allocation patterns without asserting any particular policy on the
user. Escape analysis is the only solution I know to safely allow
pointers to be passed around without having to worry about how they
were allocated.
By contrast, I have no idea what you're suggesting, or how it's not a
'crutch'... but if it's anything to do with C++, I'm dubious, and
kinda frightened.


Incidentally, I've recently started a new C++ job, first C++ I've
written in some years... (after ~18 years, 12 professionally,
full-time C/C++)
After having adapted to D and distancing from C++, trying to go back
is like some form of inhuman torture!
I really don't remember it being as bad as it is... the time away has
given me new perspective on how terrible C++ is, and I can say with
confidence, there is NOTHING C++ could do to make itself a 'better
option' at this point.
Judged on common ground, there is no competition. It's only 'the devil
you know' case that I think can possibly make an argument for C++.
Nov 13 2014
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via 
Digitalmars-d wrote:

 On 13 November 2014 20:38, via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz 
 wrote:

 D need to appropriate what C++ has and do it better. Basically 
 it means
 integrating GC pointers with unique_ptr and shared_ptr.

 If D is going to be stuck on what it has and "fix" it with 
 addig crutches it
 will go nowhere, and C++ will start to look like a better 
 option…


 I don't follow how you associate that opinion with 
 implementation of
 scope. I think it's practical and important, and the point is 
 the
 opposite of what you say from my perspective.
 scope is the best approach I've heard to address these 
 differences in
 allocation patterns without asserting any particular policy on 
 the
 user. Escape analysis is the only solution I know to safely 
 allow
 pointers to be passed around without having to worry about how 
 they
 were allocated.
 By contrast, I have no idea what you're suggesting, or how it's 
 not a
 'crutch'... but if it's anything to do with C++, I'm dubious, 
 and
 kinda frightened.


 Incidentally, I've recently started a new C++ job, first C++ 
 I've
 written in some years... (after ~18 years, 12 professionally,
 full-time C/C++)
 After having adapted to D and distancing from C++, trying to go 
 back
 is like some form of inhuman torture!
 I really don't remember it being as bad as it is... the time 
 away has
 given me new perspective on how terrible C++ is, and I can say 
 with
 confidence, there is NOTHING C++ could do to make itself a 
 'better
 option' at this point.
 Judged on common ground, there is no competition. It's only 
 'the devil
 you know' case that I think can possibly make an argument for 
 C++.


C++14 is quite nice and C++17 will be even better.

Then there is the advantage it is available in all OS vendors 
SDKs, with very nice tooling.

However, the hard reality in most corporations is that code bases 
will be pre-C++98 with its own set of guidelines, if any.


--
Paulo
Nov 13 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Manu via Digitalmars-d"  wrote in message 
news:mailman.1926.1415879071.9932.digitalmars-d puremagic.com...


 Incidentally, I've recently started a new C++ job, first C++ I've
 written in some years... (after ~18 years, 12 professionally,
 full-time C/C++)
 After having adapted to D and distancing from C++, trying to go back
 is like some form of inhuman torture!
 I really don't remember it being as bad as it is... the time away has
 given me new perspective on how terrible C++ is, and I can say with
 confidence, there is NOTHING C++ could do to make itself a 'better
 option' at this point.
 Judged on common ground, there is no competition. It's only 'the devil
 you know' case that I think can possibly make an argument for C++.


I know, it's easy to forget how bad C++ is to work with.  The new versions 
have fixed some of the pain points, but only some.
Nov 13 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 November 2014 21:54, Daniel Murphy via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 "Manu via Digitalmars-d"  wrote in message
 news:mailman.1926.1415879071.9932.digitalmars-d puremagic.com...


 Incidentally, I've recently started a new C++ job, first C++ I've
 written in some years... (after ~18 years, 12 professionally,
 full-time C/C++)
 After having adapted to D and distancing from C++, trying to go back
 is like some form of inhuman torture!
 I really don't remember it being as bad as it is... the time away has
 given me new perspective on how terrible C++ is, and I can say with
 confidence, there is NOTHING C++ could do to make itself a 'better
 option' at this point.
 Judged on common ground, there is no competition. It's only 'the devil
 you know' case that I think can possibly make an argument for C++.



 I know, it's easy to forget how bad C++ is to work with.  The new versions
 have fixed some of the pain points, but only some.


Yeah... nar. Not really. Every line of code is at least 3-4 times as
long as it needs to be. It's virtually impossible to see the code
through the syntactic noise.
I like nullptr, I can get behind that ;)

I realised within minutes that it's almost impossible to live without slices.
On the plus side, I've already made lots of converts in my new office
from my constant ranting :P
Nov 13 2014
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/13/2014 5:55 AM, Manu via Digitalmars-d wrote:

 I realised within minutes that it's almost impossible to live without slices.
 On the plus side, I've already made lots of converts in my new office
 from my constant ranting :P


You should submit a presentation proposal to the O'Reilly Software Architecture 
Conference!

   http://softwarearchitecturecon.com/sa2015
Nov 15 2014
prev sibling next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via 
Digitalmars-d wrote:

 I don't follow how you associate that opinion with 
 implementation of
 scope.


I don't like semantics where I have to state that the parameters 
and the function should be "pure". It should be opposite. Say, if 
you have an array on the stack, then I'd like to take a slice of 
it and send it to a function to compute a sum(). But, I don't 
want the type system to prevent me from doing it because the 
author of sum() forgot to add "scope" to the parameter.

What is the difference between a function that is annotated as 
"pure" and a function where all input is "scope"? This is 
backwards!

Function signatures should not say "I am playing nice…", that 
should be the default. They should say "watch out, I'm stealing 
your stuff!".


 By contrast, I have no idea what you're suggesting, or how it's 
 not a
 'crutch'... but if it's anything to do with C++, I'm dubious, 
 and
 kinda frightened.


C++ is multi-paradigm and backwards compatible focused, and is 
therefore ruled by a mess of conventions and fixes, true.


 After having adapted to D and distancing from C++, trying to go 
 back is like some form of inhuman torture!


C++ is not excellent… Too verbose and grown out of the 
include/macro system (which suits C better than C++). I find C++ 
ok when I use it like C with bells (and leave out the whistles).


 Judged on common ground, there is no competition. It's only 
 'the devil you know' case that I think can possibly make an
 argument for C++.


I don't know. I only use C++ for things that is suitable for C. 
Like DSP/realtime. Fortunately I don't have to deal with other 
people's C++ code.

Many C++ frameworks look really ugly, but with C++14 I think I 
shall be able to make my own code look acceptable (readable).
Nov 13 2014
next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 13 November 2014 at 12:01:33 UTC, Ola Fosheim 
Grøstad wrote:

 I don't like semantics where I have to state that the 
 parameters and the function should be "pure". It should be 
 opposite.


Unfortunately for your sanity, this isn't going to happen.  
Similarly unlikely is multiple pointer types, which Walter has 
repeatedly shot down.  I'd suggest bringing it back up if and 
when discussion of D3 begins in earnest.

-Wyatt
Nov 13 2014
parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 13 November 2014 at 13:29:00 UTC, Wyatt wrote:

 Unfortunately for your sanity, this isn't going to happen.  
 Similarly unlikely is multiple pointer types, which Walter has 
 repeatedly shot down.  I'd suggest bringing it back up if and 
 when discussion of D3 begins in earnest.


D needs to start to focus on providing an assumption free system 
level programming language that supports the kind of modelling 
done for system level programming.

I am not sure if adding templates to D was a good idea, but now 
that you have gone that route to such a large extent, you might 
as well do it wholesale with better support for templated SYSTEM 
programming would make sense. Make it your advantage. (including 
deforesting/common subexpression substitution, constraints 
systems etc)

As an application level programming language D stands no chance. 
More crutches and special casing will not make D a system level 
programming language. Neither does adding features designed for 
other languages geared towards functional programming (which is 
the antithesis of system level programming).

Yes, it can be done using a source to source upgrade tool.

No, attribute inference is not a silver bullet, it means changes 
to libraries would silently break applications.

Yes, function signatures matters. Function signatures are 
contracts, they need to be visually clear and the semantics have 
to be easy to grok.

No, piling up low hanging fruits that are not yet ripe is not a 
great way to do language design.
Nov 14 2014
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 13 November 2014 at 12:01:33 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via 
 Digitalmars-d wrote:

 I don't follow how you associate that opinion with 
 implementation of
 scope.


 I don't like semantics where I have to state that the 
 parameters and the function should be "pure". It should be 
 opposite. Say, if you have an array on the stack, then I'd like 
 to take a slice of it and send it to a function to compute a 
 sum(). But, I don't want the type system to prevent me from 
 doing it because the author of sum() forgot to add "scope" to 
 the parameter.

 What is the difference between a function that is annotated as 
 "pure" and a function where all input is "scope"? This is 
 backwards!

 Function signatures should not say "I am playing nice…", that 
 should be the default. They should say "watch out, I'm stealing 
 your stuff!".


I agree with this in principle, but it is unrealistic for D2. 
This is stuff that can go into a future D3, together with  safe 
by default, pure by default, and maybe immutable by default. But 
that doesn't mean that it shouldn't be introduced in D2 already, 
so that we can gain experience with it.

That said, it might not be so bad with `scope`. The latest 
iteration of the proposal has been simplified a lot; scope 
annotations will mostly be needed for function signatures, and 
explicit owners are only allowed there. There's also some 
potential for inference with templates.
Nov 13 2014
prev sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 November 2014 22:01, via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via Digitalmars-d wrote:

 I don't follow how you associate that opinion with implementation of
 scope.



 I don't like semantics where I have to state that the parameters and the
 function should be "pure". It should be opposite. Say, if you have an array
 on the stack, then I'd like to take a slice of it and send it to a function
 to compute a sum(). But, I don't want the type system to prevent me from
 doing it because the author of sum() forgot to add "scope" to the parameter.

 What is the difference between a function that is annotated as "pure" and a
 function where all input is "scope"? This is backwards!


D has attribute inference, that's like, a thing now.
Theoretically, the compiler may be able to determine that a reference
does not escape, and infer the 'scope' attribute, in many cases. This
would be consistent with other attributes.



 Function signatures should not say "I am playing nice…", that should be the
 default. They should say "watch out, I'm stealing your stuff!".


But that's already a concrete pattern throughout D. To do something
otherwise would be an unexpected deviation from the norm.

For the record, I agree with you, but that boat sailed a very long
time ago. We must now stick to the pattern that's in place.



 Many C++ frameworks look really ugly, but with C++14 I think I shall be able
 to make my own code look acceptable (readable).


I don't see anything in C++11/14/17 that looks like they'll salvage
the language from the sea of barely decipherable template mess and
endless boilerplate. It seems they're getting deeper into that
madness, not less.
I spent the last 2 days doing some string processing in C++...
possibly the least fun I've ever had programming. Somehow I used to
find it tolerable!
Nov 13 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 13 November 2014 at 13:46:20 UTC, Manu via 
Digitalmars-d wrote:

 On 13 November 2014 22:01, via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Thursday, 13 November 2014 at 11:44:31 UTC, Manu via 
 Digitalmars-d wrote:


 D has attribute inference, that's like, a thing now.


Yes, these days D arguments go like this:

A: "I am saying no because it would go against separate 
compilation units."

B: "I am saying yes because we have attribute inference."

A: "But when will it be implemented?"

B: "After we have resolved all issues in the bugtracker."

A: "But C++17 will be out by then!"

B: "Please don't compare D to C++, it is a unique language"

A: "And Rust will be out too!"

B: "Hey, that's a low blow. And unfair! Besides, linear types 
suck."

A: "But 'scope' is a linear type qualifier, kinda?"

B: "Ok, we will only do it as a library type then."

A: "How does that improve anything?"

B: "It changes a lot, it means Walter can focus on ironing out 
bugs and Andrei will implement it after he has fixed the GC".

A: "When will that happen?"

B: "After he is finished with adding ref counters to Phobos"

A: "I thought that was done?"

B: "Don't be unreasonable, Phobos is huge, it takes at least 6 
months! Besides, it is obvious that we need to figure out how to 
do scope before completing ref counting anyway."

A: "I agree…Where were we?"

B: "I'm not sure. I'll try to find time to write a DIP."



 I don't see anything in C++11/14/17 that looks like they'll 
 salvage
 the language from the sea of barely decipherable template mess 
 and
 endless boilerplate. It seems they're getting deeper into that
 madness, not less.


Stuff like auto on return types etc makes it easier and less 
verbose when dealing with templated libraries.

Unfortunately, I guess I can't use it on my next project anyway, 
since I need to support iOS5.1 which probably means XCode… 4? 
Sigh…

That's one of the things that annoy me with C++, the long tail 
for being able to use the new features.


 I spent the last 2 days doing some string processing in C++...
 possibly the least fun I've ever had programming. Somehow I 
 used to
 find it tolerable!


Ack… I try to stick to binary formats. Strings are only fun in 
languages like Python (and possibly Haskell).
Nov 13 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-11-13 23:00, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 Unfortunately, I guess I can't use it on my next project anyway, since I
 need to support iOS5.1 which probably means XCode… 4? Sigh…


Can't you use Xcode 6 and set the minimum deploy target to iOS 5.1? If 
that's not possible it should be possible to use Xcode 4 and replace the 
Clang compiler that Xcode uses with a later version.

-- 
/Jacob Carlborg
Nov 14 2014
parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Friday, 14 November 2014 at 08:10:22 UTC, Jacob Carlborg wrote:

 Can't you use Xcode 6 and set the minimum deploy target to iOS 
 5.1? If that's not possible it should be possible to use Xcode 
 4 and replace the Clang compiler that Xcode uses with a later 
 version.


I don't know yet, but the 5.1 simulator will probably have to run 
on OS-X 10.6.8 from what I've found on the net. Maybe it is 
possible to do as you said with clang… Hm.
Nov 14 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-11-14 15:28, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= 
<ola.fosheim.grostad+dlang gmail.com>" wrote:


 I don't know yet, but the 5.1 simulator will probably have to run on
 OS-X 10.6.8 from what I've found on the net. Maybe it is possible to do
 as you said with clang… Hm.


The simulator bundled with Xcode 5 run on Yosemite but not the one 
bundled with Xcode 4.

-- 
/Jacob Carlborg
Nov 15 2014
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 13 November 2014 at 13:46:20 UTC, Manu via
Digitalmars-d wrote:

 D has attribute inference, that's like, a thing now.
 Theoretically, the compiler may be able to determine that a 
 reference
 does not escape, and infer the 'scope' attribute, in many 
 cases. This
 would be consistent with other attributes.


Yes, that is the only sane road forward.
Nov 13 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/13/2014 3:44 AM, Manu via Digitalmars-d wrote:

 After having adapted to D and distancing from C++, trying to go back
 is like some form of inhuman torture!
 I really don't remember it being as bad as it is... the time away has
 given me new perspective on how terrible C++ is, and I can say with
 confidence, there is NOTHING C++ could do to make itself a 'better
 option' at this point.


What I find odd about the progress of C++ (11, 14, 17, ...) is that there has 
been no concerted effort to make the preprocesser obsolete.
Nov 15 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 16.11.2014 um 05:51 schrieb Walter Bright:

 On 11/13/2014 3:44 AM, Manu via Digitalmars-d wrote:

 After having adapted to D and distancing from C++, trying to go back
 is like some form of inhuman torture!
 I really don't remember it being as bad as it is... the time away has
 given me new perspective on how terrible C++ is, and I can say with
 confidence, there is NOTHING C++ could do to make itself a 'better
 option' at this point.


 What I find odd about the progress of C++ (11, 14, 17, ...) is that
 there has been no concerted effort to make the preprocesser obsolete.


What about templates, compile time reflection, modules and compile time 
code execution?

No need for the pre-processor other than textual inclusion and 
conditional compilation.

--
Paulo
Nov 15 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/15/2014 11:14 PM, Paulo Pinto wrote:

 Am 16.11.2014 um 05:51 schrieb Walter Bright:

 What I find odd about the progress of C++ (11, 14, 17, ...) is that
 there has been no concerted effort to make the preprocesser obsolete.


 What about templates, compile time reflection, modules and compile time code
 execution?


Competent and prominent C++ coding teams still manage to find complex and 
tangled uses for the preprocessor that rely on the most obscure details of how 
the preprocessor works, and then hang their whole codebase on it.

I find it baffling, but there it is. I've made some effort to get rid of 
preprocessor use in the DMD source.



 No need for the pre-processor other than textual inclusion and conditional
 compilation.


Andrei, Herb, and I made a proposal to the C++ committee to introduce 'static 
if'. It was promptly nailed to the wall and executed by firing squad. :-)
Nov 15 2014
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 16.11.2014 um 08:44 schrieb Walter Bright:

 On 11/15/2014 11:14 PM, Paulo Pinto wrote:

 Am 16.11.2014 um 05:51 schrieb Walter Bright:

 What I find odd about the progress of C++ (11, 14, 17, ...) is that
 there has been no concerted effort to make the preprocesser obsolete.


 What about templates, compile time reflection, modules and compile
 time code
 execution?


 Competent and prominent C++ coding teams still manage to find complex
 and tangled uses for the preprocessor that rely on the most obscure
 details of how the preprocessor works, and then hang their whole
 codebase on it.

 I find it baffling, but there it is. I've made some effort to get rid of
 preprocessor use in the DMD source.



 No need for the pre-processor other than textual inclusion and
 conditional
 compilation.


 Andrei, Herb, and I made a proposal to the C++ committee to introduce
 'static if'. It was promptly nailed to the wall and executed by firing
 squad. :-)


That was quite bad how it happened.
Nov 15 2014
prev sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Thursday, 13 November 2014 at 10:38:57 UTC, Ola Fosheim 
Grøstad wrote:

 On Thursday, 13 November 2014 at 10:24:44 UTC, Marc Schütz 
 wrote:

 Huh? That's exactly what _borrowing_ does. Ref-counting OTOH 
 adds yet another reference type and thereby makes the 
 situation worse.


 I don't like explicit ref counting, but it is sometimes useful 
 and I think Rust-style ownership is pretty close to unique_ptr 
 which is ref-counting with a max count of 1… You can also view 
 GC as being implicitly ref counted too (it is "counted" during 
 collection).


I think I understand now how you want to use templates. You 
basically want to make the various reference types implement a 
protocol, and then templatize functions to accept any of those 
reference types, just like we do with ranges.

But this brings with it the downside of templates, namely 
template bloat. And you need to do additional work to eliminate 
all the redundant inc/dec calls if you pass an RC reference. All 
of which is unnecessary for most functions, because a function 
knows in advance whether it needs to retain the reference or just 
borrow it, and can be declared accordingly. This means that 
`scope` acts as an abstraction over the various reference types, 
be it GC, RC, plain pointer, unique pointer, or some more 
complicated user defined scheme.

This also benefits the GC, by the way. A scope reference doesn't 
need to be treated as a root, because there will always be at 
least one other copy of the reference. This means that structures 
containing only scoped references need not be scanned.


 What does "shared" tell the compiler?


 I guess you mean "scope"?


 :)


 It tells it "retain no references after completion of this 
 function". Like with "pure", it should be opposite. You 
 should tell the compiler "I transfer ownership of this 
 parameter". Then have a generic concept "owned" for 
 parameters that is resolved using templates.


 That's what deadalnix's proposal does. Though I don't quite 
 see what templates have to do with it.


 My understanding of Deadalnix' proposal is that "owned" objects 
 can only reference other "owned" objects.


Yes. But they can also be merged into un-owned structures (i.e. 
the various heaps), at which point they lose their owned-ness. 
This allows the creator of these objects to be agnostic about how 
the consumers want to handle them.


 I think region allocators do better if you start constraining 
 relations by ownership.


Not sure what you mean, but I don't think region allocators can 
be used for this. They require the object creator to know in 
advance how long the objects will exist. Or alternatively, the 
creators need to be informed about that by receiving a reference 
to the region allocator, at which point we're most likely back at 
templates.
Nov 13 2014
prev sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 13 November 2014 at 10:00:10 UTC, Ola Fosheim 
Grøstad wrote:

 GC ptr: release() and move() are dummies.


Well, "move()" should obviously not be a dummy, but just a 
regular assignment that requires the object to be GC allocated…

What I am saying is that D needs type-classes for pointers so 
that you can write generic functions can be ignorant to specific 
allocation schemes and specify their minimum requirements. It 
basically means that in  safe code all raw pointers are 
"borrowed" and all owned pointers requires specification tha is 
either concrete (gc,shared,unique) or a templated generalization 
(single ownership, multiple ownership etc).

It seems a perfect for D to extend templates with more power and 
make good use of it now that C++ adds concepts.
Nov 13 2014
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 I agree. This is one of those cases in which a good engineering 
 solution may be a lot better than the "perfect" solution (and 
 linear types are not even perfect...).


I am sure you are aware that the solution you are talking about 
is rather more complex (for both final programmers and language 
implementators) than the Rust solution.

Bye,
bearophile
Nov 13 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/13/14 1:41 AM, bearophile wrote:

 Andrei Alexandrescu:


 I agree. This is one of those cases in which a good engineering
 solution may be a lot better than the "perfect" solution (and linear
 types are not even perfect...).


 I am sure you are aware that the solution you are talking about is
 rather more complex (for both final programmers and language
 implementators) than the Rust solution.


In fact I am not! -- Andrei
Nov 13 2014