www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Stable D version?

reply "Tourist" <gravatar gravatar.com> writes:
Hi guys,

I've been following the forums for a while. I'm interested in 
looking into D, but I understand that currently it changes often, 
and is not very reliable.
I've also read that there's a new release model planned, where a 
stable version of the language is released every year or two. Is 
that so? When would it take place?

What's holding you from releasing a version now and declaring it 
stable for e.g. a year?
Apr 21 2013
next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:

 Hi guys,

 I've been following the forums for a while. I'm interested in 
 looking into D, but I understand that currently it changes 
 often, and is not very reliable.
 I've also read that there's a new release model planned, where 
 a stable version of the language is released every year or two. 
 Is that so? When would it take place?

 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?


The year long support is not going to be put in place at this 
time. Several took issue with that plan considering it to provide 
limited/no benefit.

The core dev team is currently getting use to using a staging 
branch to prepare a release.

Eventually we may see a release get patched up until the point of 
the next release, but this has not yet been adopted by the core 
team or those writing patches. Having a clear understanding of 
what goes where has been a big point of discussion which again no 
one could agree on the specifics.
Apr 21 2013
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:

 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?


What would be the benefit of just declaring one release stable?

This is not a trick question.

David
Apr 22 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:

 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:

 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?


 What would be the benefit of just declaring one release stable?

 This is not a trick question.


That would not be a benefit, maybe. But, however, an answer to 
the question: "will EVER D be finished?" would be more than 
wonderful.

Clean up the doubtful or wrong features and let it as it is. 
Further language improvements should be made after several years 
of use. Much like C++ is evolving with its standards, also C 
(C89, C99 etc.)

Seriously, now, D is in the making for a decade and more. And, 
until it gets stable and Walter STOPS working on D (language) 
and, instead, only works on the COMPILER, things are not done.

D starts looking like the D in _D_uke Nukem Forever (and forever 
it will take...).

I got old looking at D and hoping that it will ever get released.

Imagine that Bjarne Stroustrup would proceed today with changing 
C++ at the same pace as D is. C++ still evolves, albeit less fast 
than D, but also with much more scrutinity and, let's say, 
conservatorism. Which, after a while, it is good.

Will D remain the forever unborn child of the programming 
languages?

Born it. Let it become what is intended to be: a MATURE language. 
Yes, it might not grow perfect, but it will grow. It needs to get 
into childhood, enough with the (pro-)creation.

At my job I went back to C++. With a language contunously in the 
making, the tools will never mature enough, never will get 
Eclipse plugins as good as CDT, never etc.

I have that feeling (correct me if I am wrong) that C++ will 
catch up with D in several years. Look at C++11, it is a nice 
improvement. C++14 will be (hopefully) even better. And, then?...

Radons&Minayev made a good decision to quit D back then and never 
look behind. A toy it was, a toy remained.
Apr 22 2013
next sibling parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
I started a project a month ago, and for the moment my feeling is 
just: D can already be used as it. It's not "finished" but the 
state is stable enough I think.

The compiler is not perfect (not always really explicit messages, 
not able to compile for all architecture like ARM,...), but a lot 
of things can already be done.

I made few games on Nintendo DS console, with a pretty old gcc 
version on which it wasn't recommended to develop in C++ due to 
the lack of support of some core feature of language. Now I can 
just find D more advanced.

C++11 and C++14 aren't really interesting for me, just cause of 
lack of support of some compilers like Visual Studio, it really 
can be the hell to realize portable applications (iOS, Android, 
Windows, Mac OS X, gcc, clang, cl,...). Without talking of 
template meta programming that are pretty hard to compile on 
different compilers.
Because D is pretty well specified, you will never loose your 
time with compilers flags, missing features on a platform or 
macro issues before an include,...

I was surprise how it's easy to progress in D just because it's 
fast to build and test. There is also a lot of advanced features 
like __traits,... that are directly in the core of language/std 
lib.

Any IDE support D perfectly but Visual D and MonoD are just good 
enough for starting.
Apr 22 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:

The problem is not that D is usable or not as it is. The problem 
is that, until officially "handled to the user", it won't be 
taken too serious by the industry.

In other words, you won't find jobs as a D programmer.

C++ will improve more with the pending modules and other features 
that do not even have to wait 2014 for that (a TR will do the 
job). But the point here is not about C++.

The problem with D is that it's never finished. Everybody waits 
for the next version. Everytime I spoke to my boss about D, the 
answer was like: "hmmm... we'll discuss about it when it's ready".

D1 was killed by a under-developed phobos and by the the conflict 
tango-phobos, at least in part. What really killed D1 was the 
announcement of D2. And I have the feeling that after D2 is 
rolled out, people will start working on D3.

That's the wrong approach. If it is usable as it is, then shift 
the main effort on tools for it and on promoting it. Then, let it 
in the market, get feedback from compiler implementors and 
commercial users and formalize that as a proposal for the next D 
standard. Then, after public scrutinize the proposed changes for 
6 months or 1 tear, implement them.

Only recently the focus was placed on implementing those shared 
libraries. Really, who'd have been expected to use D in 
commercial, large applications, without that support? Why did 
people wait for so long?

Keep running circles around Optlink and other specific tools just 
for the sake of them? I agree they *were* valuable, but they 
*were*. Focus on the ldc or gcc/gdc implementation, for example. 
Use that as the official compiler. Do not split effort. There are 
a lot of standard tools that will facilitate adoption, yet the 
effort is misplaced.

Put the current language version on the market, along with a 
document summarizing proposals for the future standard and get 
feedback from users that will start using it for real 
applications, on large scale.

No need, for now, to make Phobos the best of the best. The curse 
of Tango vanished. Ship it as it is, incomplete but cleaned, then 
some libraries will be written and they will find almost 
naturally place in the standard library, just as the C++ standard 
integrates parts from Boost, integrated STL etc.

Pursuing perfection will miss the good.
Apr 22 2013
parent "Tourist" <gravatar gravatar.com> writes:
On Tuesday, 23 April 2013 at 01:06:49 UTC, eles wrote:

 On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:

 The problem is not that D is usable or not as it is. The 
 problem is that, until officially "handled to the user", it 
 won't be taken too serious by the industry.

 In other words, you won't find jobs as a D programmer.

 C++ will improve more with the pending modules and other 
 features that do not even have to wait 2014 for that (a TR will 
 do the job). But the point here is not about C++.

 The problem with D is that it's never finished. Everybody waits 
 for the next version. Everytime I spoke to my boss about D, the 
 answer was like: "hmmm... we'll discuss about it when it's 
 ready".

 D1 was killed by a under-developed phobos and by the the 
 conflict tango-phobos, at least in part. What really killed D1 
 was the announcement of D2. And I have the feeling that after 
 D2 is rolled out, people will start working on D3.

 That's the wrong approach. If it is usable as it is, then shift 
 the main effort on tools for it and on promoting it. Then, let 
 it in the market, get feedback from compiler implementors and 
 commercial users and formalize that as a proposal for the next 
 D standard. Then, after public scrutinize the proposed changes 
 for 6 months or 1 tear, implement them.

 Only recently the focus was placed on implementing those shared 
 libraries. Really, who'd have been expected to use D in 
 commercial, large applications, without that support? Why did 
 people wait for so long?

 Keep running circles around Optlink and other specific tools 
 just for the sake of them? I agree they *were* valuable, but 
 they *were*. Focus on the ldc or gcc/gdc implementation, for 
 example. Use that as the official compiler. Do not split 
 effort. There are a lot of standard tools that will facilitate 
 adoption, yet the effort is misplaced.

 Put the current language version on the market, along with a 
 document summarizing proposals for the future standard and get 
 feedback from users that will start using it for real 
 applications, on large scale.

 No need, for now, to make Phobos the best of the best. The 
 curse of Tango vanished. Ship it as it is, incomplete but 
 cleaned, then some libraries will be written and they will find 
 almost naturally place in the standard library, just as the C++ 
 standard integrates parts from Boost, integrated STL etc.

 Pursuing perfection will miss the good.


I couldn't have said it better!
Apr 22 2013
prev sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:

 I started a project a month ago, and for the moment my feeling 
 is just:
 D can already be used as it.


Input:
	import std.stdio;
	struct S { string a; }
	pragma(msg,           S("x") == S("x".idup));
	void main() { writeln(S("x") == S("x".idup)); }


Output:
	true
	false

...


Nope, still broken.
Apr 22 2013
next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:

 ...


 Nope, still broken.


The behavior isn't too surprising to me. Your code is buggy. 
Defining opEquals gets you the behavior you might want:

import std.stdio, std.algorithm;
struct S {
     string a;
     bool opEquals(S rhs) { return a.equal(rhs.a); }
}
pragma(msg,  S("x") == S("x".idup));
void main() {
     writeln(S("x") == S("x".idup));
}

outputs:
true
true
Apr 22 2013
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:26:59 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:

 ...


 Nope, still broken.


 The behavior isn't too surprising to me. Your code is buggy.



?!??!
Apr 22 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:

 ?!??!


I'm confused by why you might be confused by this. opEquals by 
default is simply a bit-level value check.

"x" and "x".idup are two different things.

"x" might be:
   ptr = 0xDEADBEEF
   length = 1

and "x".idup might be:
   ptr = 0xDEADBEEE
   length = 1

Clearly they are not equal. If you have a particular definition 
that isn't the same as the the bit-level basic equality, you have 
a method of defining it.

For why the compiler treats them the same... well, it simply 
doesn't create a new place for "x".idup. Simple optimization that 
doesn't matter unless you're comparing their identity.
Apr 22 2013
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:

 ?!??!


 I'm confused by why you might be confused by this. opEquals by 
 default is simply a bit-level value check.



Yeah, hence it's broken.
Apr 22 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 04:33:50 UTC, Mehrdad wrote:

 Yeah, hence it's broken.


Um... I don't see the problem. Do you expect the compiler to 
treat strings/arrays special and look up the equal method in the 
standard library? Wouldn't that confuse you when it doesn't apply 
to your structures? Furthermore, requiring the compiler to know 
about the standard library doesn't sound broken to you?
Apr 22 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:37:12 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 04:33:50 UTC, Mehrdad wrote:

 Yeah, hence it's broken.


 Um... I don't see the problem. Do you expect the compiler to 
 treat strings/arrays special and look up the equal method in 
 the standard library? Wouldn't that confuse you when it doesn't 
 apply to your structures? Furthermore, requiring the compiler 
 to know about the standard library doesn't sound broken to you?




It has nothing to do with the standard library.
It should do whatever operator == does.
Apr 22 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 04:43:04 UTC, Mehrdad wrote:

 It has nothing to do with the standard library.
 It should do whatever operator == does.


Sounds slow. We really need a way for you to choose to have it 
your way and the way it is now.

Oh, there's opEquals. Now we can both be happy. :)
Apr 22 2013
parent reply "anonymous" <anonymous example.com> writes:
On Tuesday, 23 April 2013 at 04:48:05 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 04:43:04 UTC, Mehrdad wrote:

 It has nothing to do with the standard library.
 It should do whatever operator == does.


 Sounds slow. We really need a way for you to choose to have it 
 your way and the way it is now.

 Oh, there's opEquals. Now we can both be happy. :)


For fast bitwise comparison there's the "is" operator.
The "==" operator should be "slow".
See also http://d.puremagic.com/issues/show_bug.cgi?id=3789
Apr 22 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 04:58:30 UTC, anonymous wrote:

 For fast bitwise comparison there's the "is" operator.
 The "==" operator should be "slow".
 See also http://d.puremagic.com/issues/show_bug.cgi?id=3789


Well okay. The docs will have to be updated for this issue if 
it's "fixed".

For instance:
http://dlang.org/ctod.html#structcmp

In any case, I stand by that if you have a particular definition 
of behavior, you should provide it instead of expecting it to 
"just work." But I suppose using "is" is more appropriate for 
this type of behavior. But calling it "broken" is a bit too 
strong.
Apr 22 2013
next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:

 In any case, I stand by that if you have a particular 
 definition of behavior, you should provide it instead of 
 expecting it to "just work." But I suppose using "is" is more 
 appropriate for this type of behavior. But calling it "broken" 
 is a bit too strong.


Actually, I'm going to strengthen this a bit more. I'd _still_ 
think it's a good idea to keep structs the way they are. I expect 
(as I think many would) structs to be very bare metal. Very 
little auto-magic should touch them because they are used so 
often for low-level tasks and you really ought to be very precise 
when you're defining them and their behavior. In that context, 
"==" being the same as "is" makes sense from my perspective and I 
wouldn't expect anything else unless I explicitly told it 
otherwise.

If you want some of that type of automatic "just works" behavior, 
you're probably using structs as more higher level concepts. 
Maybe consider using a tuple instead?


import std.stdio, std.typecons;
void main() { writeln(tuple("a") == tuple("a".idup)); }


Outputs:
true

And it's shorter and simpler than the struct example.
Apr 22 2013
parent "anonymous" <anonymous example.com> writes:
On Tuesday, 23 April 2013 at 05:16:35 UTC, Chris Cain wrote:

 Actually, I'm going to strengthen this a bit more. I'd _still_ 
 think it's a good idea to keep structs the way they are. I 
 expect (as I think many would) structs to be very bare metal. 
 Very little auto-magic should touch them because they are used 
 so often for low-level tasks and you really ought to be very 
 precise when you're defining them and their behavior. In that 
 context, "==" being the same as "is" makes sense from my 
 perspective and I wouldn't expect anything else unless I 
 explicitly told it otherwise.


I don't feel strongly about which path is right. But (as Mehrdad 
has shown) the current behaviour is not consistent either way: 
strings are compared bitwise, floats are compared logically.
Apr 22 2013
prev sibling next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:

 I suppose using "is" is more appropriate for this type of 
 behavior.



If when you see a == b you think,
	Hey, that's equivalent to (a.d is b.d)
I suppose that when you see (a is b) you think,
	Hey, that's equivalent to a.d == b.d
?



 But calling it "broken" is a bit too strong.



If it doesn't make sense, it's broken.


Implementing == as 'is' by default doesn't make sense when there 
is already an 'is' operator that could do the same, hence it's 
broken.
Apr 22 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 05:28:54 UTC, Mehrdad wrote:

 If when you see a == b you think,
 	Hey, that's equivalent to (a.d is b.d)
 I suppose that when you see (a is b) you think,
 	Hey, that's equivalent to a.d == b.d
 ?


Incorrect. When I see a == b, I don't think anything. Thanks to 
encapsulation, typeof(a) and typeof(b) gets to decide what "==" 
means. If they happen to be structs, then if the author defined 
opEquals, then that's what it means. Otherwise, it's just a 
simple bitwise comparison (or should be).


 If it doesn't make sense, it's broken.


 Implementing == as 'is' by default doesn't make sense when 
 there is already an 'is' operator that could do the same, hence 
 it's broken.


It doesn't make sense to _you_. It's a purely subjective matter. 
And considering I've explained the way to think about it so it 
should be cleared up now. It's a minor stumbling block at best.

Define opEquals and everything will work how you want. Very 
simple solution to a problem you seem to be blowing out of 
proportion. My very first post fixed your bug.

Is there something stopping you from defining opEquals for the 
behavior you want?
Apr 22 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 05:48:08 UTC, Chris Cain wrote:

 Incorrect. When I see a == b, I don't think anything.


I stand corrected I guess. I'll stop thinking as well.



 It doesn't make sense to _you_.



Okay sure, have fun watching people use languages that make more 
sense to them than D I guess.



 Is there something stopping you from defining opEquals for the 
 behavior you want?


yes, unnecessary waste of time/effort
Apr 22 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 05:57:16 UTC, Mehrdad wrote:

 I stand corrected I guess. I'll stop thinking as well.
 ...
 Okay sure, have fun watching people use languages that make 
 more sense to them than D I guess.


*sigh*

I really wish you'd be more cooperative in this conversation. I 
certainly don't want to drive anyone away from D. I really don't 
understand why someone would say "If you don't do what I want, 
I'm leaving!" expecting to get their way, though.

I'm trying to explain to you what's going on so that you can 
understand what is happening so that it will "make sense to you."


 yes, unnecessary waste of time/effort


Maybe use a tuple or Tuple instead then? Even easier and less 
time consuming than defining a struct.
Apr 22 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:07:55 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 05:57:16 UTC, Mehrdad wrote:

 I stand corrected I guess. I'll stop thinking as well.
 ...
 Okay sure, have fun watching people use languages that make 
 more sense to them than D I guess.


 *sigh*

 I really wish you'd be more cooperative in this conversation.
 I certainly don't want to drive anyone away from D.
 I really don't understand why someone would say "If you don't 
 do what I want, I'm leaving!" expecting to get their way, 
 though.


That's not quite what I'm saying.
I'm just trying to make a point, which I'll repeat below.



 I'm trying to explain to you what's going on so that you can 
 understand what is happening so that it will "make sense to 
 you."



The trouble is that you've already failed before you started.


People hate C++ because it's unintuitive. I can spend all day 
telling you about why C++'s behavior in e.g. the Abrahams-Dimov 
example (look it up) is _TECHNICALLY_ the correct/expected 
behavior.

But in the end of the day it just doesn't make sense.
I might win the battle, but C++ has already lost the war.


So my point is, whether or not you can convince me this behavior 
is correct (and you probably won't), it's not going to change 
whether people find D easy to use.


There's a reason why no other popular language (that I know of) 
translates "==" into a bitwise comparison of structs. What do you 
think the reason might be?
Apr 22 2013
next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:

 There's a reason why no other popular language (that I know of) 
 translates "==" into a bitwise comparison of structs. What do 
 you think the reason might be?


I'm intrigued. Mind listing the languages? As far as popular 

most languages don't have structs.
Apr 22 2013
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:26:55 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:

 There's a reason why no other popular language (that I know 
 of) translates "==" into a bitwise comparison of structs. What 
 do you think the reason might be?


 I'm intrigued. Mind listing the languages? As far as popular 

 but most languages don't have structs.


I guess C and C++ aren't even considered languages anymore.
Apr 22 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:31:44 UTC, Mehrdad wrote:

 I guess C and C++ aren't even considered languages anymore.


?

main.c:13:10: error: invalid operands to binary == (have ‘struct 
S’ and ‘struct S’)
      if(a == b)

You can't use == in C on structs ... ?
Apr 22 2013
parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:50:08 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 06:31:44 UTC, Mehrdad wrote:

 I guess C and C++ aren't even considered languages anymore.


 ?

 main.c:13:10: error: invalid operands to binary == (have 
 ‘struct S’ and ‘struct S’)
      if(a == b)

 You can't use == in C on structs ... ?


Exactly -- when there is no correct behavior, they didn't try 
implementing one.
Apr 22 2013
prev sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:26:55 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:

 There's a reason why no other popular language (that I know 
 of) translates "==" into a bitwise comparison of structs. What 
 do you think the reason might be?


 I'm intrigued. Mind listing the languages? As far as popular 

 but most languages don't have structs.



And don't forget Objective-C, Visual Basic (.NET), Matlab...
Apr 22 2013
prev sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:

 The trouble is that you've already failed before you started.


Also, I'm assuming that this means that you had no intention of 
learning. That's kind of a poor position to be in, IMO. That 
means that I can't help you because you don't want to be helped.

So, I can give you appropriate alternatives (such as tuple) but 
you won't look at it and see "Oh, jeez, that's actually what I've 
been using structs for." (Or not, but I can't ever know that's 
not what you're looking for if you're not going to even try).

And I can't suggest snippets like:

     bool opEquals(T rhs) {
         foreach(i, e; this.tupleof) {
             if(!(e == rhs.tupleof[i]))
                 return false;
         }
         return true;
     }

... Which you could use in a mixin to start building a framework 
of behaviors you can add to _any_ struct to automatically get the 
behavior you want. We also can't discuss adding this as an 
attribute using the new attribute system and adding it to the 
standard library which might be something cool.

No, we have to do it _your_ way and using _your_ understanding, 
instead of cooperating and getting a better result that we can 
both agree on.

All I'm saying is that structs are really basic for a reason. 
They're something you _build_ on. If you don't want to build on 
it (and you want something already somewhat built), you might be 
better served using something that _is_ prebuilt. Or make your 
own platform based on a struct (kinda like how tuples are 
implemented) and solve it that way.

So many solutions to your problem, yet you've already decided 
that changing the language is the only "right" way.
Apr 22 2013
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:41:36 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 06:24:24 UTC, Mehrdad wrote:

 The trouble is that you've already failed before you started.


 Also, I'm assuming that this means that you had no intention of 
 learning.


I could tell you the same thing, but it wouldn't get me anywhere.



 All I'm saying is that structs are really basic for a reason. 
 They're something you _build_ on.


Then they shouldn't define a behavior for == in the first place.


No behavior is better than wrong behavior.
Apr 22 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:46:49 UTC, Mehrdad wrote:

 I could tell you the same thing, but it wouldn't get me 
 anywhere.


Alrighty, that's my sign to leave. Good luck Mehrdad.
Apr 22 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:52:03 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 06:46:49 UTC, Mehrdad wrote:

 I could tell you the same thing, but it wouldn't get me 
 anywhere.


 Good luck Mehrdad.


Same to you.
Apr 22 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:54:07 UTC, Mehrdad wrote:

 Same to you.


I'm going to just be a little frank with you here.

I've _never_ had even a slightly productive conversation with 
you. You're hostile to work with. I know you have some valuable 
things to say and contribute to the community, but its just too 
difficult to work with you.

If you'd make some effort at being less antagonistic, you'd find 
you'd get much further. Like I said in my previous large post, 
there are solutions out there we could talk about, but you won't 
hear it. Heck, you essentially didn't even acknowledge the vast 
majority of what I had to say in my last large post. I had plenty 
of neat potential solutions, but they don't even get a slight 
consideration on your part. What a waste of time.

I half-way expect a quick backhanded reply in less than 30 
seconds yet again, but I hope you consider thinking about it over 
night.
Apr 23 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 07:09:41 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 06:54:07 UTC, Mehrdad wrote:

 Same to you.


 I'm going to just be a little frank with you here.

 I've _never_ had even a slightly productive conversation with 
 you. You're hostile to work with. I know you have some valuable 
 things to say and contribute to the community, but its just too 
 difficult to work with you.



Sorry, most of my responses are really short because I'm working 
on other things at the moment.

I'm just trying to say a few sentences to make a point and go 
back to what I'm doing, but it's not going as well as I would 
have hoped.



 If you'd make some effort at being less antagonistic, you'd 
 find you'd get much further.




 Like I said in my previous large post, there are solutions out 
 there we could talk about, but you won't hear it.



It's because you're solving a different problem than the one I'm 
mentioning.
I'm telling you the problem (struct == behavior is wrong), you're 
telling me there is a workaround (tuples).


I'm not looking for a workaround, I already know enough 
workarounds for it.

I'm just trying to tell you it's a _workaround_ to a _problem_.
The fact that it exists doesn't make the problem go away.



 Heck, you essentially didn't even acknowledge the vast majority 
 of what I had to say in my last large post.



Honestly, out of all the things I said, you also picked and chose 
single one to give nonsensical replies to.

I said C and C++ and VB.NET and Matlab etc., and you just replied 
with "C struct doesn't even have ==".

Not only did you completely miss my first point there (why aren't 
other languages doing the same thing?), you also missed my second 
point:
If == doesn't make sense, it shouldn't be defined at all.



 I had plenty of neat potential solutions, but they don't even 
 get a slight consideration on your part. What a waste of time.


Again, my purpose in mentioning this wasn't to look for a 
workaround, but to point out the problem itself, see above.


I'm not having trouble finding workarounds, I'm just pointing out 
examples of why people aren't finding D usable (or why they 
consider it broken).
Apr 23 2013
next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:

 I'm not having trouble finding workarounds, I'm just pointing 
 out examples of why people aren't finding D usable (or why they 
 consider it broken).


And I know no one likes to hear something is broken.
I'm not doing that to be mean or something like that, I'm doing 
it because when I see people forget there are usability issues in 
D, I think it's beneficial for me to point out [you can correct 
me if I'm wrong] the flaws, rather than pretend that the language 
is very usable and people are just too slow in adopting it.
Apr 23 2013
prev sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:

 Sorry, most of my responses are really short because I'm 
 working on other things at the moment.

 I'm just trying to say a few sentences to make a point and go 
 back to what I'm doing, but it's not going as well as I would 
 have hoped.


OK.

On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:

 Honestly, out of all the things I said, you also picked and 
 chose single one to give nonsensical replies to.

 I said C and C++ and VB.NET and Matlab etc., and you just 
 replied with "C struct doesn't even have ==".


I'm just replying to this because I wanted to make it clear what 
I did:

I booted up a Linux VM and wrote a quick program to try to 
understand where you were coming from, taking a painstaking 
effort to try to understand you and the context of what you're 
trying to say. I didn't respond to all of the other languages 
because I was immediately confused by the result of the first 
and, additionally, trying all of the above languages would be 
fairly time consuming. My apologies for not trying all of them.

My intention was for good when I did it, so I hope that's enough 
to earn forgiveness for "picking and choosing a single one to 
give nonsensical replies to". :-\


 Not only did you completely miss my first point there (why 
 aren't other languages doing the same thing?), you also missed 
 my second point:
 If == doesn't make sense, it shouldn't be defined at all.


Also, your second point wasn't missed. It simply didn't exist 
before I had started trying the C code.

TBH, I think this would be a better solution. But I'd bet it'd 
break way too much code now.
Apr 23 2013
parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 07:37:29 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:

 Sorry, most of my responses are really short because I'm 
 working on other things at the moment.

 I'm just trying to say a few sentences to make a point and go 
 back to what I'm doing, but it's not going as well as I would 
 have hoped.


 OK.

 On Tuesday, 23 April 2013 at 07:19:47 UTC, Mehrdad wrote:

 Honestly, out of all the things I said, you also picked and 
 chose single one to give nonsensical replies to.

 I said C and C++ and VB.NET and Matlab etc., and you just 
 replied with "C struct doesn't even have ==".


 I'm just replying to this because I wanted to make it clear 
 what I did:

 I booted up a Linux VM and wrote a quick program to try to 
 understand where you were coming from, taking a painstaking 
 effort to try to understand you and the context of what you're 
 trying to say. I didn't respond to all of the other languages 
 because I was immediately confused by the result of the first 
 and, additionally, trying all of the above languages would be 
 fairly time consuming. My apologies for not trying all of them.

 My intention was for good when I did it, so I hope that's 
 enough to earn forgiveness for "picking and choosing a single 
 one to give nonsensical replies to". :-\



Haha okay no worries, sorry my replies weren't terribly friendly.
Btw there's www.ideone.com, you can also try some things there.


 Not only did you completely miss my first point there (why 
 aren't other languages doing the same thing?), you also missed 
 my second point:
 If == doesn't make sense, it shouldn't be defined at all.


 Also, your second point wasn't missed. It simply didn't exist 
 before I had started trying the C code.



Sorry I didn't realize that. :( Hope it makes sense now.


 TBH, I think this would be a better solution. But I'd bet it'd 
 break way too much code now.



I think if D wants to go anywhere, code will have to be broken, 
lots of it.

No one's going to like it, but when it has broken features to 
begin with then it's not going to go very far in terms of 
usability.
Apr 23 2013
prev sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 06:41:36 UTC, Chris Cain wrote:

 So many solutions to your problem, yet you've already decided 
 that changing the language is the only "right" way.




I'm just telling you that if no other language has done it, 
there's a reason behind it.
Apr 22 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 April 2013 at 05:05:29 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 04:58:30 UTC, anonymous wrote:

 For fast bitwise comparison there's the "is" operator.
 The "==" operator should be "slow".
 See also http://d.puremagic.com/issues/show_bug.cgi?id=3789


 Well okay. The docs will have to be updated for this issue if 
 it's "fixed".

 For instance:
 http://dlang.org/ctod.html#structcmp

 In any case, I stand by that if you have a particular 
 definition of behavior, you should provide it instead of 
 expecting it to "just work." But I suppose using "is" is more 
 appropriate for this type of behavior. But calling it "broken" 
 is a bit too strong.


OK let me sum this up, as you seem confused.

Whatever you think == should do, it is broken. If we assume that 
== should check for equality, then :
pragma(msg, S("a") == S("a".idup));
writeln(S("a") == S("a".idup));
writeln(S(+0.0) == S(-0.0));

Should all evaluate to true.

If == stand for identity, then they must all be false.

You see that whatever is the semantic of ==, it is not properly 
implemented right now.

Now, as we use == for equality and "is" for identity in other 
places (slices and objects for instance) it make sense to use the 
same for struct. But that another topic, as the demonstrated 
behavior is wrong, whatever is the semantic of ==.
Apr 22 2013
prev sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:

 ?!??!


 opEquals by default is simply a bit-level value check.




In fact, it's _doubly_ broken...

	import std.stdio;
	struct S { float d; }
	void main()
	{
	    writeln(+0.0);
	    writeln(-0.0);
	    writeln(S(+0.0) == S(-0.0));
	}


Output:
	0
	-0
	true
Apr 22 2013
parent kenji hara <k.hara.pg gmail.com> writes:
In floating point value comparison, +0.0 is equal to -0.0.

    auto x = +0.0;
    auto y = -0.0;
    assert(x == y);

Kenji Hara


2013/4/23 Mehrdad <wfunction hotmail.com>


 On Tuesday, 23 April 2013 at 04:33:24 UTC, Chris Cain wrote:


 On Tuesday, 23 April 2013 at 04:27:45 UTC, Mehrdad wrote:


 ?!??!


 opEquals by default is simply a bit-level value check.




 In fact, it's _doubly_ broken...

         import std.stdio;
         struct S { float d; }
         void main()
         {
             writeln(+0.0);
             writeln(-0.0);
             writeln(S(+0.0) == S(-0.0));
         }


 Output:
         0
         -0
         true
Apr 22 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 April 2013 at 04:26:59 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 03:46:30 UTC, Mehrdad wrote:

 ...


 Nope, still broken.


 The behavior isn't too surprising to me. Your code is buggy.


You want to explain why the code is bugguy.
Apr 22 2013
parent reply "Chris Cain" <clcain uncg.edu> writes:
On Tuesday, 23 April 2013 at 06:10:00 UTC, deadalnix wrote:

 You want to explain why the code is bugguy.


Sure. He didn't know the behavior of "==" on structs and didn't 
realize it tests for identity by default. Structs require an 
opEquals defined to differ from this behavior.
Apr 22 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 April 2013 at 06:23:56 UTC, Chris Cain wrote:

 On Tuesday, 23 April 2013 at 06:10:00 UTC, deadalnix wrote:

 You want to explain why the code is bugguy.


 Sure. He didn't know the behavior of "==" on structs and didn't 
 realize it tests for identity by default. Structs require an 
 opEquals defined to differ from this behavior.


Ho yes, so please explain what is this behavior, I'd be pleased 
to know.
Apr 22 2013
prev sibling parent reply kenji hara <k.hara.pg gmail.com> writes:
2013/4/23 Mehrdad <wfunction hotmail.com>


 On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:


 I started a project a month ago, and for the moment my feeling is just:
 D can already be used as it.


 Input:
         import std.stdio;
         struct S { string a; }
         pragma(msg,           S("x") == S("x".idup));
         void main() { writeln(S("x") == S("x".idup)); }

 Output:
         true
         false

 Nope, still broken.


This is mostly expected behavior. During compilation value identities are
not guaranteed.
Because compile time evaluation is always done after constant folding, and
constant folding would fold "x".idup to "x", then S("x") == S("x") is
evaluated to true.

Kenji Hara
Apr 22 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:

 2013/4/23 Mehrdad <wfunction hotmail.com>


 On Monday, 22 April 2013 at 23:35:56 UTC, Flamaros wrote:


 I started a project a month ago, and for the moment my 
 feeling is just:
 D can already be used as it.


 Input:
         import std.stdio;
         struct S { string a; }
         pragma(msg,           S("x") == S("x".idup));
         void main() { writeln(S("x") == S("x".idup)); }

 Output:
         true
         false

 Nope, still broken.


 This is mostly expected behavior. During compilation value 
 identities are
 not guaranteed.
 Because compile time evaluation is always done after constant 
 folding, and
 constant folding would fold "x".idup to "x", then S("x") == 
 S("x") is
 evaluated to true.

 Kenji Hara




I'm not saying the 'true' is broken, I'm saying the 'false' is 
broken.


And don't miss this one, which contradicts the behavior above
http://forum.dlang.org/thread/uqkslzjnosrsnyqnhzes forum.dlang.org?page=2#post-zdmtaeycpomrhjdeanlw:40forum.dlang.org
Apr 22 2013
parent reply kenji hara <k.hara.pg gmail.com> writes:
2013/4/23 Mehrdad <wfunction hotmail.com>


 On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:


 This is mostly expected behavior. During compilation value identities are
 not guaranteed.
 Because compile time evaluation is always done after constant folding, and
 constant folding would fold "x".idup to "x", then S("x") == S("x") is

 evaluated to true.

 Kenji Hara


 I'm not saying the 'true' is broken, I'm saying the 'false' is broken.


 And don't miss this one, which contradicts the behavior above
 http://forum.dlang.org/thread/**uqkslzjnosrsnyqnhzes forum.**
 dlang.org?page=2#post-**zdmtaeycpomrhjdeanlw:40forum.**dlang.org<http://forum.dlang.org/thread/uqkslzjnosrsnyqnhzes forum.dlang.org?page=2#post-zdmtaeycpomrhjdeanlw:40forum.dlang.org>


Ah, OK. Surely that is a compiler bug which still not fixed.

Kenji Hara
Apr 22 2013
parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 04:56:13 UTC, kenji hara wrote:

 2013/4/23 Mehrdad <wfunction hotmail.com>


 On Tuesday, 23 April 2013 at 04:44:52 UTC, kenji hara wrote:


 This is mostly expected behavior. During compilation value 
 identities are
 not guaranteed.
 Because compile time evaluation is always done after constant 
 folding, and
 constant folding would fold "x".idup to "x", then S("x") == 
 S("x") is

 evaluated to true.

 Kenji Hara


 I'm not saying the 'true' is broken, I'm saying the 'false' is 
 broken.


 And don't miss this one, which contradicts the behavior above
 http://forum.dlang.org/thread/**uqkslzjnosrsnyqnhzes forum.**
 dlang.org?page=2#post-**zdmtaeycpomrhjdeanlw:40forum.**dlang.org<http://forum.dlang.org/thread/uqkslzjnosrsnyqnhzes forum.dlang.org?page=2#post-zdmtaeycpomrhjdeanlw:40forum.dlang.org>


 Ah, OK. Surely that is a compiler bug which still not fixed.



Well, I think the float behavior is correct and the string 
example is broken, but that wasn't my point anyway.

The point was that it's still broken.
Apr 22 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, April 23, 2013 07:02:39 Mehrdad wrote:

 Well, I think the float behavior is correct and the string
 example is broken, but that wasn't my point anyway.
 
 The point was that it's still broken.


According to TDPL (section 7.1.5.2, p. 258 - 259), == on structs should be 
equivalent to using == on each of the struct's members:

http://d.puremagic.com/issues/show_bug.cgi?id=3789

Doing anything else would be inconsistent, and the way that it is has 
definitely been causing problems and forces people to overload opEquals way 
more often than strictly speaking should be necessary.

- Jonathan M Davis
Apr 23 2013
prev sibling next sibling parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote:

 On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:

 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:

 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?


 What would be the benefit of just declaring one release stable?

 This is not a trick question.


 That would not be a benefit, maybe. But, however, an answer to 
 the question: "will EVER D be finished?" would be more than 
 wonderful.

 Clean up the doubtful or wrong features and let it as it is. 
 Further language improvements should be made after several 
 years of use. Much like C++ is evolving with its standards, 
 also C (C89, C99 etc.)

 Seriously, now, D is in the making for a decade and more. And, 
 until it gets stable and Walter STOPS working on D (language) 
 and, instead, only works on the COMPILER, things are not done.

 D starts looking like the D in _D_uke Nukem Forever (and 
 forever it will take...).

 I got old looking at D and hoping that it will ever get 
 released.

 Imagine that Bjarne Stroustrup would proceed today with 
 changing C++ at the same pace as D is. C++ still evolves, 
 albeit less fast than D, but also with much more scrutinity 
 and, let's say, conservatorism. Which, after a while, it is 
 good.

 Will D remain the forever unborn child of the programming 
 languages?

 Born it. Let it become what is intended to be: a MATURE 
 language. Yes, it might not grow perfect, but it will grow. It 
 needs to get into childhood, enough with the (pro-)creation.

 At my job I went back to C++. With a language contunously in 
 the making, the tools will never mature enough, never will get 
 Eclipse plugins as good as CDT, never etc.

 I have that feeling (correct me if I am wrong) that C++ will 
 catch up with D in several years. Look at C++11, it is a nice 
 improvement. C++14 will be (hopefully) even better. And, 
 then?...

 Radons&Minayev made a good decision to quit D back then and 
 never look behind. A toy it was, a toy remained.


I don't think my boss I have to know if D is finished to let us
adopt it for future products, he only want to know we'll able to
create our next product with D with the same requirement and if
the delay will be the same or better.

For the moment due to our target platform the response is no. But
if we target only Desktops the answer seems to be really close to
a yes. Some libraries are missing, but there is nothing we aren't
capable to write. The major issue for a boss is to accept to move
"old" c++ code to trash, that was his investment, actually
because there is no D developers on job market, D code isn't
valuable for him.

To break the vicious circle some companies have to take the risk
to migrate to D and let the world know it.

The easier way for a language to be inserted in companies is
certainly as scripting language, just like python. Because
companies doesn't consider script as really pieces of software
and let developers send it to trash. It's a mistake to not
considering scripts as valuable just because they are not sell.
Apr 23 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Tuesday, 23 April 2013 at 07:43:21 UTC, Flamaros wrote:

 On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote:

 On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger 
 wrote:

 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:

 What's holding you from releasing a version now and 
 declaring it stable for e.g. a year?


 What would be the benefit of just declaring one release 
 stable?

 This is not a trick question.


 That would not be a benefit, maybe. But, however, an answer to 
 the question: "will EVER D be finished?" would be more than 
 wonderful.

 Clean up the doubtful or wrong features and let it as it is. 
 Further language improvements should be made after several 
 years of use. Much like C++ is evolving with its standards, 
 also C (C89, C99 etc.)

 Seriously, now, D is in the making for a decade and more. And, 
 until it gets stable and Walter STOPS working on D (language) 
 and, instead, only works on the COMPILER, things are not done.

 D starts looking like the D in _D_uke Nukem Forever (and 
 forever it will take...).

 I got old looking at D and hoping that it will ever get 
 released.

 Imagine that Bjarne Stroustrup would proceed today with 
 changing C++ at the same pace as D is. C++ still evolves, 
 albeit less fast than D, but also with much more scrutinity 
 and, let's say, conservatorism. Which, after a while, it is 
 good.

 Will D remain the forever unborn child of the programming 
 languages?

 Born it. Let it become what is intended to be: a MATURE 
 language. Yes, it might not grow perfect, but it will grow. It 
 needs to get into childhood, enough with the (pro-)creation.

 At my job I went back to C++. With a language contunously in 
 the making, the tools will never mature enough, never will get 
 Eclipse plugins as good as CDT, never etc.

 I have that feeling (correct me if I am wrong) that C++ will 
 catch up with D in several years. Look at C++11, it is a nice 
 improvement. C++14 will be (hopefully) even better. And, 
 then?...

 Radons&Minayev made a good decision to quit D back then and 
 never look behind. A toy it was, a toy remained.


 I don't think my boss I have to know if D is finished to let us
 adopt it for future products, he only want to know we'll able to
 create our next product with D with the same requirement and if
 the delay will be the same or better.

 For the moment due to our target platform the response is no. 
 But
 if we target only Desktops the answer seems to be really close 
 to
 a yes. Some libraries are missing, but there is nothing we 
 aren't
 capable to write. The major issue for a boss is to accept to 
 move
 "old" c++ code to trash, that was his investment, actually
 because there is no D developers on job market, D code isn't
 valuable for him.

 To break the vicious circle some companies have to take the risk
 to migrate to D and let the world know it.

 The easier way for a language to be inserted in companies is
 certainly as scripting language, just like python. Because
 companies doesn't consider script as really pieces of software
 and let developers send it to trash. It's a mistake to not
 considering scripts as valuable just because they are not sell.


The hardest selling point for systems programming languages is to 
get them adopted by an OS vendor, until then they are just 
another tool for business applications, a field already too 
crowded nowadays.

Look at C++, only in the last decade did OS vendors start coding 
operating systems in C++, instead of plain C, to the point that C 
is now considered legacy at Microsoft.

Who knows how long it will take for another vendor to pick up D 
for such use cases, even if it was 100% stable today?

These things take a long time, even programmer generations.

--
Paulo
Apr 23 2013
prev sibling parent "eles" <eles eles.com> writes:
On Monday, 22 April 2013 at 22:17:33 UTC, eles wrote:

 On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:

 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:




Sorry, I was rude here and I apologize. Finally, D is (at least) 
a wonderful place to discuss and test new ideas and, while I 
would like it to take off faster, a too early rush won't make any 
good.
Apr 26 2013
prev sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:

 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:

 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?


 What would be the benefit of just declaring one release stable?

 This is not a trick question.

 David


I have raised this topic several times already. Stable version 
that is guaranteed to never break user code but still receives 
non-breaking bug-fixes is important for corporate adoption - 
those will never agree to spend some tome in the middle of 
running project to fix some unknown breakage created by a tool.
Apr 23 2013
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:

 I have raised this topic several times already. Stable version 
 that is guaranteed to never break user code



So what happens when a flaw in the language is fixed?

Do you fix it and break code, or do you leave it broken?
Apr 23 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:

 On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:

 I have raised this topic several times already. Stable version 
 that is guaranteed to never break user code



 So what happens when a flaw in the language is fixed?

 Do you fix it and break code, or do you leave it broken?


Well we have 2.062 . Let's decide this is stable version.

2.062.1 will go out then 2.062.2, etc . . . They contains only 
fixes with really small (I mean almost non existent) breakage, no 
new feature, only fix of ICE, codegen bugs, etc . . .

And 2.063 can still be pushed in the meantime. The thing that 
with D, you hit compiler bugs and so on, and you can't get fixes 
without getting the new version that break half of your code.
Apr 23 2013
prev sibling next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:

 On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:

 I have raised this topic several times already. Stable version 
 that is guaranteed to never break user code



 So what happens when a flaw in the language is fixed?

 Do you fix it and break code, or do you leave it broken?


Fix it in latest version. Leave it broken in stable.
Apr 23 2013
parent "Mehrdad" <wfunction hotmail.com> writes:
On Tuesday, 23 April 2013 at 08:18:08 UTC, Dicebot wrote:

 On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:

 On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:

 I have raised this topic several times already. Stable 
 version that is guaranteed to never break user code



 So what happens when a flaw in the language is fixed?

 Do you fix it and break code, or do you leave it broken?


 Fix it in latest version. Leave it broken in stable.


I'm not convinced that's terribly useful but if you think so then 
ok...
Apr 23 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:

 On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:

 I have raised this topic several times already. Stable version 
 that is guaranteed to never break user code



 So what happens when a flaw in the language is fixed?

 Do you fix it and break code, or do you leave it broken?


I am more for following the C/C++ solution: periodical revise the 
language, but not every two months. Several years and once that 
the compiler infrastructure is already in place and tested, 
publish (officially) the new version.

During the meantime, users could live with workarounds and 
"forbidden to do that!". Look at C and MISRA-C.

It won't help to declare a stable version of D, while keep adding 
new things. What would really help is to stop adding new things, 
remove those that we are in doubt if they are good or no 
(properties?) or, at least, leave them as they are, then move 
towards improving the tools.

A cleaner language with better tools will allow D to take off, 
while still leaving room for possible improvements in future 
revisions.

C++ did not start as a perfect language, nor it has become, still 
there are tools for it, people are using it, companies are hiring 
C++ developers.

Being predictable does matter sometimes. Tools matter too.
Apr 23 2013
next sibling parent reply "Dicebot" <m.strashun gmail.com> writes:
It is simply impossible for D. Defining trait for C/C++ is very 
strict and formal standard paper which completely defines the 
language. Revise of standard is decoupled with compiler releases. 
Standard can be revised once in a 10 years but compilers keep 
evolving having this paper in mind.

D has reference compiler and thus you technically suggest to stop 
releasing any compiler version for 1-2 years. Ugh.

On Tuesday, 23 April 2013 at 08:33:05 UTC, eles wrote:

 I am more for following the C/C++ solution: periodical revise 
 the language, but not every two months. Several years and once 
 that the compiler infrastructure is already in place and 
 tested, publish (officially) the new version.

 During the meantime, users could live with workarounds and 
 "forbidden to do that!". Look at C and MISRA-C.

 It won't help to declare a stable version of D, while keep 
 adding new things. What would really help is to stop adding new 
 things, remove those that we are in doubt if they are good or 
 no (properties?) or, at least, leave them as they are, then 
 move towards improving the tools.

 A cleaner language with better tools will allow D to take off, 
 while still leaving room for possible improvements in future 
 revisions.

 C++ did not start as a perfect language, nor it has become, 
 still there are tools for it, people are using it, companies 
 are hiring C++ developers.

 Being predictable does matter sometimes. Tools matter too.
Apr 23 2013
parent reply "eles" <eles eles.com> writes:
On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:

 D has reference compiler and thus you technically suggest to 
 stop releasing any compiler version for 1-2 years. Ugh.


No. Stop adding things.

Besides that, what's the alternative?
Apr 23 2013
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 23 April 2013 09:56, eles <eles eles.com> wrote:


 On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:


 D has reference compiler and thus you technically suggest to stop
 releasing any compiler version for 1-2 years. Ugh.


 No. Stop adding things.

 Besides that, what's the alternative?


Adding things isn't a problem and does not affect already existing code.
Perhaps you meant changing behaviours and removing things?

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Apr 23 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 23 April 2013 at 09:23:50 UTC, Iain Buclaw wrote:

 On 23 April 2013 09:56, eles <eles eles.com> wrote:


 On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:


 D has reference compiler and thus you technically suggest to 
 stop
 releasing any compiler version for 1-2 years. Ugh.


 No. Stop adding things.

 Besides that, what's the alternative?


 Adding things isn't a problem and does not affect already 
 existing code.
 Perhaps you meant changing behaviours and removing things?


Any addition in D can be breaking wconsidering feature like 
is(typeof(blah))
Apr 23 2013
prev sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 23 April 2013 at 08:56:37 UTC, eles wrote:

 On Tuesday, 23 April 2013 at 08:40:16 UTC, Dicebot wrote:

 D has reference compiler and thus you technically suggest to 
 stop releasing any compiler version for 1-2 years. Ugh.


 No. Stop adding things.

 Besides that, what's the alternative?


We don't have formal spec. Bug-fixing changes can't be 
differentiated from "new" changes.  My ancient proposal is still 
in the newsgroup : 
http://forum.dlang.org/post/nchvayzsbrzevvucmmmi forum.dlang.org
Apr 23 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/13 4:33 AM, eles wrote:

 On Tuesday, 23 April 2013 at 07:52:20 UTC, Mehrdad wrote:

 On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:

 I have raised this topic several times already. Stable version that
 is guaranteed to never break user code



 So what happens when a flaw in the language is fixed?

 Do you fix it and break code, or do you leave it broken?


 I am more for following the C/C++ solution: periodical revise the
 language, but not every two months. Several years and once that the
 compiler infrastructure is already in place and tested, publish
 (officially) the new version.

 During the meantime, users could live with workarounds and "forbidden to
 do that!". Look at C and MISRA-C.

 It won't help to declare a stable version of D, while keep adding new
 things. What would really help is to stop adding new things, remove
 those that we are in doubt if they are good or no (properties?) or, at
 least, leave them as they are, then move towards improving the tools.

 A cleaner language with better tools will allow D to take off, while
 still leaving room for possible improvements in future revisions.

 C++ did not start as a perfect language, nor it has become, still there
 are tools for it, people are using it, companies are hiring C++ developers.

 Being predictable does matter sometimes. Tools matter too.


I think we shouldn't follow the C++ model. Whatever made C++ successful 
is not what'll make D successful. The context and expectations are very 
different now.

Andrei
Apr 23 2013
parent reply "eles" <eles eles.com> writes:
On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu 
wrote:

 I think we shouldn't follow the C++ model. Whatever made C++ 
 successful is not what'll make D successful. The context and 
 expectations are very different now.

 Andrei


That's a pretty vague assertion. Please define the model that you 
have in mind for D.

OK. Don't follow the C++ model. But, then, what is the model that 
D follows? Is there any such model?
Apr 23 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/23/13 2:42 PM, eles wrote:

 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu wrote:

 I think we shouldn't follow the C++ model. Whatever made C++
 successful is not what'll make D successful. The context and
 expectations are very different now.

 Andrei


 That's a pretty vague assertion. Please define the model that you have
 in mind for D.

 OK. Don't follow the C++ model. But, then, what is the model that D
 follows? Is there any such model?


I was mainly referring to the fact that C++ succeeded in spite of having 
initially an incomplete specification. Nowadays the expectations are 
much higher.

Andrei
Apr 23 2013
parent reply "eles" <eles eles.com> writes:
On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu 
wrote:

 On 4/23/13 2:42 PM, eles wrote:

 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu


 I was mainly referring to the fact that C++ succeeded in spite 
 of having initially an incomplete specification. Nowadays the 
 expectations are much higher.

 Andrei


As long as you keep changing the language, no specification will 
ever be complete.

C++ will long advance. D must be out and living before C++14. 
Then, it will be too late. My view.
Apr 23 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04/23/2013 10:21 PM, eles wrote:

 On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote:

 On 4/23/13 2:42 PM, eles wrote:

 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu


 I was mainly referring to the fact that C++ succeeded in spite of
 having initially an incomplete specification. Nowadays the
 expectations are much higher.

 Andrei


 As long as you keep changing the language, no specification will ever be
 complete.


It is the other way round. As long as there is no specification, there 
are no language changes, as everything can be cast as a bug fix towards 
implementing some imaginary specification that is different for each dev.


 C++ will long advance. D must be out and living before C++14. Then, it
 will be too late.


I think there is no reason to assume that C++ can be fixed.


 My view.


Obviously.
Apr 23 2013
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 23.04.2013 22:21, schrieb eles:

 On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu wrote:

 On 4/23/13 2:42 PM, eles wrote:

 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu


 I was mainly referring to the fact that C++ succeeded in spite of
 having initially an incomplete specification. Nowadays the
 expectations are much higher.

 Andrei


 As long as you keep changing the language, no specification will ever be
 complete.

 C++ will long advance. D must be out and living before C++14. Then, it
 will be too late. My view.


C++ was created around 1985, that is 28 years as of today.

I remember going through the ARM (Annotated Reference Manual) around
1995 and not finding a C++ compiler that was able to compile all examples.

Following "The C Users Journal", shortly thereafter renamed "The C/C++ 
Users Journal" and "C++ Report" and seeing the language change each 
month, with each C++ compiler offering a different view what the 
language meant.

C++ will be with us for many years to come, but you should not forget 
that it has a few years in the industry already, and as I mentioned in a 
separate post, systems programming languages require support from OS 
vendors.

As a supporter for stronger typed languages I look forward not only D, 
but Rust and Go as well, even with its issues, to gain wider support, 
but it takes time.

--
Paulo
Apr 23 2013
prev sibling next sibling parent "Flamaros" <flamaros.xavier gmail.com> writes:
On Tuesday, 23 April 2013 at 20:21:55 UTC, eles wrote:

 On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu 
 wrote:

 On 4/23/13 2:42 PM, eles wrote:

 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu


 I was mainly referring to the fact that C++ succeeded in spite 
 of having initially an incomplete specification. Nowadays the 
 expectations are much higher.

 Andrei


 As long as you keep changing the language, no specification 
 will ever be complete.

 C++ will long advance. D must be out and living before C++14. 
 Then, it will be too late. My view.


I don't see on what C++14 will really change the current state of 
C++? Changes aren't import for every day developments, C++14, 
won't import fast build, safe language specifications (removal of 
multiple inheritance, no removal of error prone syntaxes, 
specified initialization values, mandatory override keyword, 
...),...

D don't have to compete C++, let D maturate.

If you are hurry to see D in the industry maybe you can 
contribute on tools, libraries,...
Apr 23 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
On Tuesday, 23 April 2013 at 20:21:55 UTC, eles wrote:

 On Tuesday, 23 April 2013 at 18:57:46 UTC, Andrei Alexandrescu 
 wrote:

 On 4/23/13 2:42 PM, eles wrote:

 On Tuesday, 23 April 2013 at 14:26:33 UTC, Andrei Alexandrescu


 I was mainly referring to the fact that C++ succeeded in spite 
 of having initially an incomplete specification. Nowadays the 
 expectations are much higher.

 Andrei


 As long as you keep changing the language, no specification 
 will ever be complete.

 C++ will long advance. D must be out and living before C++14. 
 Then, it will be too late. My view.


I also think when modules are integrated into the C++ standard, 
for most developers, there won't be any case left for D. Even 
though D technically is superior in almost every way, 
conservatism is strong enough.
Apr 28 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote:

 I also think when modules are integrated into the C++ standard, 
 for most developers, there won't be any case left for D. Even 
 though D technically is superior in almost every way, 
 conservatism is strong enough.


C++ will never be sufficiently changed to leave no chance for 
other native languages. It is doomed because of mandatory 
backwards compatibility with huge legacy package. Main issues of 
C++ are not lack of advanced features but inconvenient design of 
basic features.

Well, D is trying to have its own share of those issues too :P
Apr 28 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 28.04.2013 12:03, schrieb Dicebot:

 On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote:

 I also think when modules are integrated into the C++ standard, for
 most developers, there won't be any case left for D. Even though D
 technically is superior in almost every way, conservatism is strong
 enough.


 C++ will never be sufficiently changed to leave no chance for other
 native languages. It is doomed because of mandatory backwards
 compatibility with huge legacy package. Main issues of C++ are not lack
 of advanced features but inconvenient design of basic features.

 Well, D is trying to have its own share of those issues too :P


True, but only now the major OS vendors are switching from C to C++ as 
their main systems programming language.

How long will take until they replace it with something else?

--
Paulo
Apr 28 2013
next sibling parent reply "Mehrdad" <wfunction hotmail.com> writes:
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:

 True, but only now the major OS vendors are switching from C to 
 C++ as their main systems programming language.


Curious, which ones are you referring to?

Windows uses C for the kernel, for many reasons, one of which is 
that C (unlike C++) discourages storing large objects on the 
stack.

Linux uses C for the kernel too, mainly because Walter hates C++ 
(and C++ programmers).

Which vendors have switched to C++ for systems programming?
Apr 28 2013
next sibling parent reply "Oleg Kuporosov" <Oleg.Kuporosov gmail.com> writes:
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:

 On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:

 Which vendors have switched to C++ for systems programming?


Paolo probably had MS in mind which didn't release WinRT for C.
Apr 28 2013
parent "Mehrdad" <wfunction hotmail.com> writes:
On Monday, 29 April 2013 at 04:19:06 UTC, Oleg Kuporosov wrote:

 On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:

 On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:

 Which vendors have switched to C++ for systems programming?


 Paolo probably had MS in mind which didn't release WinRT for C.


Ah ok... but that's not really "systems programming", it's pretty 
high-level.
Apr 28 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-04-29 01:11, Mehrdad wrote:


 Curious, which ones are you referring to?

 Windows uses C for the kernel, for many reasons, one of which is that C
 (unlike C++) discourages storing large objects on the stack.

 Linux uses C for the kernel too, mainly because Walter hates C++ (and
 C++ programmers).

 Which vendors have switched to C++ for systems programming?


The kernel in Mac OS X is written in a subset of C++.

-- 
/Jacob Carlborg
Apr 28 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:

 On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:

 True, but only now the major OS vendors are switching from C 
 to C++ as their main systems programming language.


 Curious, which ones are you referring to?

 Windows uses C for the kernel, for many reasons, one of which 
 is that C (unlike C++) discourages storing large objects on the 
 stack.

 Linux uses C for the kernel too, mainly because Walter hates 
 C++ (and C++ programmers).

 Which vendors have switched to C++ for systems programming?


BeOS/Haiku - C++

Symbian - C++

MacOS X - Device Drivers are written in a C++ subset (IOKit)

z/OS - Original code was Modula-2/Assembly, with new code being 
C++

Windows - WinRT is C++, C is considered legacy, Herb Sutter 
stated at BUILD 2012 that Windows team is making kernel code C++ 
compatible. I can search for the exact minute in the videos if 
you wish.
Apr 29 2013
prev sibling parent "eles" <eles eles.com> writes:
On Sunday, 28 April 2013 at 23:11:30 UTC, Mehrdad wrote:

 On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:



 Linux uses C for the kernel too, mainly because Walter hates 
 C++ (and C++ programmers).


err, Linus
Apr 29 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Sunday, 28 April 2013 at 12:01:58 UTC, Paulo Pinto wrote:

 Am 28.04.2013 12:03, schrieb Dicebot:

 On Sunday, 28 April 2013 at 09:24:13 UTC, SomeDude wrote:

 I also think when modules are integrated into the C++




 True, but only now the major OS vendors are switching from C to 
 C++ as their main systems programming language.


I think that exactly because it is a switch *in the happening*, 
it is the moment for D to be involve in that switch. Because 
project managers are considering switching and they look for 
alternatives. Maybe some of them will tell themselves: "well, if 
we switch, why do not take that D in consideration? at least, for 
experimenting and see what it gives".

It is useless to be a good alternative if nobody wants to switch.

If they go down on the C++ path, then two things will happen:
-they will be even more reluctant to do another switch, while 
their code base matures (and, do not forget, interoperability or 
portability from C to D is one thing; form C++ to D is a 
different, huge, beast).
-C++ will get more traction and more pressure to improve itself, 
from vendors and community at large. it will advance faster.

In the end, we should not be sorry, as programmers we will win 
better language, better tools. But I am afraid that D will not 
win as much.
Apr 28 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:

 ...


D is simply in no shape to compete for kernels for same reasons 
it is rather painful to use in embedded (fat runtime, language 
features relying on hidden gc allocations etc.) It is hardly 
practical to discuss the moment to compete when it is not an 
option from technical point of view.
Apr 29 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote:

 On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:
 D is simply in no shape to compete for kernels for same reasons 
 it is rather painful to use in embedded (fat runtime, language 
 features relying on hidden gc allocations etc.) It is hardly 
 practical to discuss the moment to compete when it is not an 
 option from technical point of view.


Well, then a list of what's still missing should be compiled (in 
terms of features and language changes, not in terms of bugs). An 
rush to complete it.

Some of the issues were discussed since many months, and no 
definitive decision has been taken (see the  property).

I am rather in favor of taking a decision, good or bad, than to 
prolonge ambiguity. Also for several minor issues (ie: double[$] 
static arrays and __MODULE__ identifier and so on).

For those, I would like to see a more accelerated pace.

I even start thinking that is better to release a new feature 
after a relative short, preliminary discussion, and be prepared 
to change it during a time frame, if it is not as practical as 
desired, instead of prolonging a discussion for centuries in the 
search of the perfect implementation.
Apr 29 2013
parent "Mr. Anonymous" <mailnew4ster gmail.com> writes:
On Monday, 29 April 2013 at 08:07:05 UTC, eles wrote:

 I even start thinking that is better to release a new feature 
 after a relative short, preliminary discussion, and be prepared 
 to change it during a time frame, if it is not as practical as 
 desired, instead of prolonging a discussion for centuries in 
 the search of the perfect implementation.


That brings us back to the "Stable D" subject, and the separation 
between stable and unstable.
Those preliminary features should be included in the unstable 
releases, where changes can be made without the fear of breaking 
things.
Then, after some actual usage, they would be merged to the stable 
branch.
Apr 29 2013
prev sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 29 April 2013 at 07:44:15 UTC, Dicebot wrote:

 On Monday, 29 April 2013 at 06:45:32 UTC, eles wrote:

 ...


 D is simply in no shape to compete for kernels for same reasons 
 it is rather painful to use in embedded (fat runtime, language 
 features relying on hidden gc allocations etc.) It is hardly 
 practical to discuss the moment to compete when it is not an 
 option from technical point of view.


This guys don't have any issues selling Oberon compilers for 
embedded use.

http://www.oberonday2011.ethz.ch/talks/armembedded.pdf

http://www.astrobe.com/default.htm

A GC enabled systems programming language.

Oracle with their Spots  and the new Keil board support (Java)

http://www.sunspotworld.com/

http://docs.oracle.com/javame/config/cldc/rel/3.3/keil/gs/html/getstart_rtx/running.htm



http://netduino.com/

Or course this is a very limited subset of what embedded is all 
about, but I think D could also be usable in such types of boards.
Apr 29 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote:

 This guys don't have any issues selling Oberon compilers for 
 embedded use.
 ...


That is simple, "embedded" is a buzzword often understood as 
"something like PC but small". Such definition is quite useless 
because it implies no specific requirements. Like, calling modern 
ARM smartphone an embedded system? No way. You can even afford to 
have something as inefficient as kernel in Java on those 
machines, why not.

Much more practical definition of "embedded" is all about 
specific requirements. Real-time systems, systems with hard 
memory restrictions (imagine coding in environment where malloc 
is prohibited because every single byte of physical memory is 
pre-allocated). Those can vary from microchips to monstrous 
servers and I don't see anything but C or C++ with lot of custom 
policies used there.
Apr 29 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 29 April 2013 at 10:38:32 UTC, Dicebot wrote:

 On Monday, 29 April 2013 at 09:54:29 UTC, Paulo Pinto wrote:

 This guys don't have any issues selling Oberon compilers for 
 embedded use.
 ...


 That is simple, "embedded" is a buzzword often understood as 
 "something like PC but small". Such definition is quite useless 
 because it implies no specific requirements. Like, calling 
 modern ARM smartphone an embedded system? No way. You can even 
 afford to have something as inefficient as kernel in Java on 
 those machines, why not.

 Much more practical definition of "embedded" is all about 
 specific requirements. Real-time systems, systems with hard 
 memory restrictions (imagine coding in environment where malloc 
 is prohibited because every single byte of physical memory is 
 pre-allocated). Those can vary from microchips to monstrous 
 servers and I don't see anything but C or C++ with lot of 
 custom policies used there.


Quoting myself

"Or course this is a very limited subset of what embedded is all
about, but I think D could also be usable in such types of 
boards."
Apr 29 2013
parent reply "Dicebot" <m.strashun gmail.com> writes:
On Monday, 29 April 2013 at 11:15:20 UTC, Paulo Pinto wrote:

 Quoting myself

 "Or course this is a very limited subset of what embedded is all
 about, but I think D could also be usable in such types of 
 boards."


Okay, pardon me, may be I have not highlighted my point clear 
enough: there is no real market for D in that limited subset 

based on their virtual machines. And, similar to desktop usage, 
lot of selling points for D are lost then, because, well, why 
bother?

Contrary to this, any language who can make it into real embedded 
domain will be almost uncontested, because this industry is still 
stuck with 40-year obsolete tools. But that is not something that 
may happen on its own.
Apr 29 2013
parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 29 April 2013 at 11:24:02 UTC, Dicebot wrote:

 On Monday, 29 April 2013 at 11:15:20 UTC, Paulo Pinto wrote:

 Quoting myself

 "Or course this is a very limited subset of what embedded is 
 all
 about, but I think D could also be usable in such types of 
 boards."


 Okay, pardon me, may be I have not highlighted my point clear 
 enough: there is no real market for D in that limited subset 

 based on their virtual machines. And, similar to desktop usage, 
 lot of selling points for D are lost then, because, well, why 
 bother?

 Contrary to this, any language who can make it into real 
 embedded domain will be almost uncontested, because this 
 industry is still stuck with 40-year obsolete tools. But that 
 is not something that may happen on its own.


Fair enough, I agree with you there.
Apr 29 2013
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 23 April 2013 at 07:50:44 UTC, Dicebot wrote:

 On Monday, 22 April 2013 at 14:25:21 UTC, David Nadlinger wrote:

 On Sunday, 21 April 2013 at 19:58:14 UTC, Tourist wrote:

 What's holding you from releasing a version now and declaring 
 it stable for e.g. a year?


 What would be the benefit of just declaring one release stable?

 This is not a trick question.

 David


 I have raised this topic several times already. Stable version 
 that is guaranteed to never break user code but still receives 
 non-breaking bug-fixes is important for corporate adoption - 
 those will never agree to spend some tome in the middle of 
 running project to fix some unknown breakage created by a tool.


Okay, maybe it was somewhat of a trick question after all: 
"Tourist" put it as if all that was required was to mark a 
certain version stable, and I wanted to hint at the fact that 
this alone wouldn't help anybody at all.

David
Apr 23 2013
parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 23 April 2013 at 08:23:34 UTC, David Nadlinger wrote:

 Okay, maybe it was somewhat of a trick question after all: 
 "Tourist" put it as if all that was required was to mark a 
 certain version stable, and I wanted to hint at the fact that 
 this alone wouldn't help anybody at all.

 David


Sure. If "naming" is only thing required, than anyone can name it 
and no D team effort is needed :) Unfortunately, it is not that 
simple.
Apr 23 2013