On Saturday, 14 December 2013 at 09:09:21 UTC, Rikki Cattermole wrote:
> Personally for me its going a little far just having enum { with multiple types being used as a value. But hey as long as everyone can understand it, no problems!

I prefer untyped constants as they can be used as different types in different places, like #define'd constants in C. If constants are too strongly typed, it can lead to awkward situations such as in the Rust code where two constants for the same value were used in order to avoid a heap of ugly casts:
static StartRangei : u32 = 15;
static StartRangef : f64 = StartRangei as f64;

On 2013-12-14 03:24, Manu wrote:

> http://en.wikipedia.org/wiki/Bracket
> The big text in the top right says braces. Reading further... seems
> there's a lot of disagreement on the matter. However, the very first
> term; it's unusual the UK and the US both allegedly agree on something.
> I accept that as a sign! ;)

"Tuborg brackets" - best name ever :D. That should be the official name in D :)

-- 
/Jacob Carlborg

On 12/14/2013 7:45 PM, logicchains wrote:
> On Saturday, 14 December 2013 at 09:09:21 UTC, Rikki Cattermole wrote:
>> Personally for me its going a little far just having enum { with
>> multiple types being used as a value. But hey as long as everyone can
>> understand it, no problems!
>
> I prefer untyped constants as they can be used as different types in
> different places, like #define'd constants in C. If constants are too
> strongly typed, it can lead to awkward situations such as in the Rust
> code where two constants for the same value were used in order to avoid
> a heap of ugly casts:
> static StartRangei : u32 = 15;
> static StartRangef : f64 = StartRangei as f64;

There's no such thing as an untyped constant in D. If you don't specify a type, it will auto infer the type of anything you assign it. If there's no value assigned, it defaults to int.

On Saturday, 14 December 2013 at 12:46:43 UTC, Mike Parker wrote:
> There's no such thing as an untyped constant in D. If you don't specify a type, it will auto infer the type of anything you assign it. If there's no value assigned, it defaults to int.

Oh, thanks for clarifying that.

On Saturday, 14 December 2013 at 04:17:16 UTC, Manu wrote:
> It's all good, it's settled now. It's not my fault, or my intent, that the most trivial point in my list of comments is the one that apparently stimulated the most discussion... :/

Oh well, don't feel bad, I wrote tongue-in-cheek and needed motivation to de-lurk. If people can't stand opinions about whitespace they should get off the net. :-) In my opinion you would need an editor with good taste who develops the style guide and enforces it. That's the best way for a volunteer-like project, I think, because enforcing a style you don't enjoy is no fun so it is important that the one responsible for fixing code-layout LOVES the "design".

(I personally suspect that the lots-of-extra-lines styles were developed, not out of taste, but as a strategy to get impressive Lines-Of-Code-counts! Lines of code used as a measure of productivity by clueless managers.)

On another note, now that I am here: I find the D-forums to be very entertaining, lots of fun discussions comparing different languages. So I keep coming back. I once had great hope for D as a better C++, but I have kind of given up, even though I find the other C-family members kind of distasteful too, but their compilers are better (for now). I am also kind of wondering if Dart will replace Javascript and then a more static version of that language eventually will replace C++. It makes little sense to have all these almost-the-same imperative languages…

Regarding using the not-operator for non-not-operations: anything would be better than reusing operators that are commonly used to affect control-flow. It makes it difficult to comprehend control flow when you skim code you are not familiar with. "not" tends to be used for completely changing the flow of a program so those "!" are attention-seekers when trying comprehend unfamiliar code.

What makes me sit on the fence regarding D (I have used it actively a couple of years ago) is:

1. Not enough improvement on syntax (In some areas better than C++, in others worse. In regards to templates it is even worse, and C++ is kind of bad.)

2. No way to get rid of garbage-collection without making the language crippled. This is a show-stopper.

3. No high performing authoritative compiler suite. When the efforts are spread over 3 compilers I just don't expect any of them to improve to a state where it becomes excellent (like having excellent error-messages, analytic features, tight IDE-integration etc). It gives an impression of a lack of direction and leadership, and makes me feel like there is no hope of D ever to catch up. Other languages keep improving too…

So obviously, it is not the semantics that makes me a lurking fence-sitter. The issues that makes me sit on the fence are certainly in areas that could be fixed, but I don't expect it will be. So I stick to the forums, for now… ;-) Though I do really wish you the best, and will certainly use/contribute to D when/if it resolves the issues listed above.

Ola.

Am 14.12.2013 00:08, schrieb Jonathan M Davis:
> On Friday, December 13, 2013 13:04:13 Andrei Alexandrescu wrote:
>> Facebook uses Egyptian braces in its D code.
>
> My condolences. ;)
>
> - Jonathan M Davis
>

I love them and it always an headache when using other styles.

Anyway if you want to start a programmer civil war, you just need to ask for what is the right style in any given language. :)

--
Paulo

On 14/12/13 17:22, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>"@puremagic.com wrote:
> What makes me sit on the fence regarding D (I have used it actively a couple of
> years ago) is:
>
> 1. Not enough improvement on syntax (In some areas better than C++, in others
> worse. In regards to templates it is even worse, and C++ is kind of bad.)

Very curious about what you mean here -- I think most of us find that D's template syntax is much superior to C++, so I'd really like to understand what you find problematic.

> 2. No way to get rid of garbage-collection without making the language crippled.
> This is a show-stopper.

Out of curiosity, is this a show-stopper for theoretical reasons, or did you actually run into practical problems with the GC?  I ask because despite having fairly stiff performance requirements, I've not generally had any problems getting C/C++-like speed while using the GC.  Then again, I don't rely on any kind of real-time performance, only overall speed.

> 3. No high performing authoritative compiler suite. When the efforts are spread
> over 3 compilers I just don't expect any of them to improve to a state where it
> becomes excellent (like having excellent error-messages, analytic features,
> tight IDE-integration etc). It gives an impression of a lack of direction and
> leadership, and makes me feel like there is no hope of D ever to catch up. Other
> languages keep improving too…

I don't think things are actually as spread out as you think.  In reality, there is one compiler frontend that everyone collaborates on.  That frontend is ported to different backends, which each have different advantages in terms of speed and optimizations.  But most of the things you are concerned with seem to be things that depend only on the frontend.

> So obviously, it is not the semantics that makes me a lurking fence-sitter. The
> issues that makes me sit on the fence are certainly in areas that could be
> fixed, but I don't expect it will be. So I stick to the forums, for now… ;-)
> Though I do really wish you the best, and will certainly use/contribute to D
> when/if it resolves the issues listed above.

I think it might be worth giving things another spin.  If the last time you tried using D was a couple of years ago, you will find that things have changed a great deal in terms of performance, features and general quality.

And, if you're up for contributing, why not see if you can address some of the issues you raise?  For example, as you want to avoid the GC, one area that could use some input is going through Phobos working out what allocates when it doesn't need to, and fixing it.

On Saturday, 14 December 2013 at 16:22:41 UTC, Ola Fosheim Grøstad wrote:
> Regarding using the not-operator for non-not-operations: anything would be better than reusing operators that are commonly used to affect control-flow. It makes it difficult to comprehend control flow when you skim code you are not familiar with. "not" tends to be used for completely changing the flow of a program so those "!" are attention-seekers when trying comprehend unfamiliar code.

But still, _what exactly_ should be used instead of the "not-operator"? "Anything" is too vague and not true. You probably can't use these: ][+=-_,.|`\/"'><;:}{%^&*

("Can't" is a strong word. <>s are used by C++, for instance, but we already know of the challenges and issues caused by that)

You might could _just_ use ()s but it'd lead to some parsing difficulties for both the programmer and the computer.

I'm just curious, not trying to say you're wrong. I do think it's a huge step up from C++'s templates and, personally, I love the new syntax with an infix ! for instantiating templates. But if something better could be used, I'm interested in hearing the ideas too.

On Saturday, 14 December 2013 at 18:46:50 UTC, Joseph Rushton Wakeling wrote:
> Very curious about what you mean here -- I think most of us find that D's template syntax is much superior to C++, so I'd really like to understand what you find problematic.

I dislike the syntax. :-) And well, as far as I can tell I also dislike the semantics, but it is no worse than C++. I would like to see a modern language with templates to do it well. That is to be more in the direction of readable term-rewriting, pattern-matching with constraints that will make it possible to do clean operator-overloading etc.  More in the direction of legible Pure, Haskell etc.

> Out of curiosity, is this a show-stopper for theoretical reasons, or did you actually run into practical problems with the GC?

It is a showstopper because I only do C++ like stuff that is realtime,  like graphics and audio. I use Python for things that can be done as batch.

I once wrote a D-program to sort my email archives in memory, it took a while for the GC to kick in, but it got kind of slow… Still, this was a couple of years ago.

What I want is a programming language that I can write clean code in and that allows me to have a mental map of how it maps onto the hardware. C does this, except it does not allow for clean programming.

> I don't think things are actually as spread out as you think.  In reality, there is one compiler frontend that everyone collaborates on.

You could be right, I am only talking about the impression I am getting. "The smoke-signals being received from a distance". When you don't have one excellent compiler, but three in-the-works, it sends signals of a lack of direction and implies a lack of a leader that can rally everyone into something cohesive. This is not a critique of anyone, most programmers want to be creative and argumentative, not to "nurture", "manipulate" and "wave the whip" ( I am not even sure I like people who are "great leaders" ;^).

> I think it might be worth giving things another spin.  If the last time you tried using D was a couple of years ago, you will find that things have changed a great deal in terms of performance, features and general quality.

Let me rephrase what I am perceiving like this: for me D is currently a solution without a problem.

D is probably a better language than Dart, but Dart is addressing a real problem: writing programs for browsers that are longer than 1000 lines without javascript. And it does so by compiling to javascript. So I am using Dart now. Dart is currently the only sane solution for web-app programming.

D is probably a better language than Python, but Python has many great libraries (like importing excel), is available for AppEngine with fast spin-up, and have a nice interpreter for experimenting with text-manipulation and code-snippets. So I am using Python, even though a dynamic language is crap on a server (runtime errors).

D is probably a better language than Go, but it isn't available on AppEngine and the Go team is making it work well for web servers so while it is still in experimental status it probably will be support fully on AppEngine. So I am spending some time with Go.

D is probably a better language than C++ in many areas (like header files!), but I cannot easily and effortlessly get rid of the GC and I will probably have performance problems with real time program code (audio is hard realtime, if you don't fill the buffer you get "pops").

D is certainly a much better language than Objective-C/Objective-C++, but it won't run on iOS. So when doing app-programming I'd use Objective-C++ (and do as much as possible in the C++ part).

The only hobbyist project I have that I would like to use D for is to do a little bit of experimenting with creating a tiny hobbyist OS in 64-bit mode, but I have no idea what it takes to do that with D.

My personal opinion is that D would get much more traction if it was a true C/C++ replacement. That is to have the same level of minimal runtime-system/mental-mapping-to-hardware. So, if there was a tar-ball with a small mini-OS/D-compiler that I could dabble with I most certainly would give D a spin, but as of today I see D as a solution with no obvious problem to solve. There is no "best-application-area" for D, which in turns leads it to not being the first choice for any given problem even though it probably is a better language in many areas than the languages that "win" in their respective areas.

I think the ideal direction for D would be to take clang, rip out the c++ parser and allow D to interface with (llvm based) C++ seamlessly and to add the ability to generate c++ code from D code. That way programmers could start integrating D into their C++ projects with no risk. As of today, I feel that it is better to just stick to C++ without D, because the risks of using D does not outweigh the advantages it may provide for me.

Do you think I am unfair?

Ola.

On Saturday, 14 December 2013 at 19:32:45 UTC, Chris Cain wrote:
> On Saturday, 14 December 2013 at 16:22:41 UTC, Ola Fosheim Grøstad wrote:
>> Regarding using the not-operator for non-not-operations: anything would be better than reusing operators that are commonly used to affect control-flow. It makes it difficult to comprehend control flow when you skim code you are not familiar with. "not" tends to be used for completely changing the flow of a program so those "!" are attention-seekers when trying comprehend unfamiliar code.
>
> But still, _what exactly_ should be used instead of the "not-operator"? "Anything" is too vague and not true. You probably can't use these: ][+=-_,.|`\/"'><;:}{%^&*

Composite brackets, a-la the SPECS 'C++ Resyntaxed' ** proposal, would work. <[]>, <[<[]>]> may be a bit heavy but not too bad.

I haven't found the !() syntax for D templates to be a problem though and prefer it to <> from C++ and Java. If I were searching for D blemishes, I wouldn't look there first.

-- Brian

** http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProposal.html