>> I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful than they are.
>
> I use them all the time, and cringe whenever I code in something else because i don't have them. Once you have /* comments */ in some piece of code, you can't comment blocks without going through hoops. that is very annoying./+ comments +/ are one of the simple thing that makes coding in D much more pleasant.

I have opened a fascinated behavior of /+ +/ not so long, and it is really cool. If you want to rid them, then /* */ have to get this behavior. And it doesn't broke anything, because they pass for examle principle "C code works properly, when it compiles".

On Saturday, March 14, 2015 21:31:46 Walter Bright via Digitalmars-d wrote:
> I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful than they are.

Really? I love those. They're _way_ better than /* */. The fact that /* */ don't nest is _very_ annoying, and I think that /+ +/ is a big improvement. If anything, I wouldn't mind it if /* */ were removed from the language. They're just plain inferior to /+ +/. The only advantage of /* */ is that they exist in other languages.

- Jonathan M Davis

On 3/14/2015 10:28 PM, deadalnix wrote:
> I use them all the time, and cringe whenever I code in something else because i
> don't have them. Once you have /* comments */ in some piece of code, you can't
> comment blocks without going through hoops. that is very annoying./+ comments +/
> are one of the simple thing that makes coding in D much more pleasant.

Use:

   version (none)
   {
      ...
   }

instead of:

   /+
      ...
    +/

On a related note, see how difficult it is to remove a feature? Every time I propose one, someone pops up and says they built their life around it :-)

On 3/14/2015 10:28 PM, deadalnix wrote:
> Not one precisely, but I'm sure we don't need as many as we have. ", `, q", q{,
> r", x". I've never used several of theses and I'm sure most people here would
> say the same.

The HexStrings http://dlang.org/lex.html#HexString can be easily replaced with a user defined literal. That's probably a good idea. The others, not so.

On Sunday, 15 March 2015 at 03:26:01 UTC, Laeeth Isharc wrote:
> Hi.
>
> Some points I think are important follow.  I can't do much on these myself for now as computer use limited by a spinal injury.

That sounds bad. I hope you'll get better!

> 3. I have said so before (the GroupBy docs) - standard library documentation is 'perfectly clear' if you have a technical mindset and are used to reading formalisms, but it is horrendously intimidating if not (which applies to many people).  We need more examples, and they should put the use in context rather than just being tiny fragments - ie show how to do something useful with the function (cf python docs).  There should also be a guide to functions writing from point of what one wants to achieve.  toLower in std.string, but I need to go to std.ascii for doing the same thing to a character.  Eminently logical, but not obvious if you don't know where to look.

It seems the accessibility/discoverability of string handling is a common complaint. People expect certain functions to be available for strings, like startsWith, trim/ltrim/rtrim, repeat, maybe even regex matching. Now, these things are all available in other parts of Phobos, or easily implementable using components from all over the standard library, but a beginner won't know this, and even if, it's inconvenient.

Maybe we should add the most common functions to `std.string`? Either as aliases or re-exports, or even (re)implement them there with the appropriate semantics if necessary. For example, people would expect a hypothetical `std.string.repeat` to be eager, whereas `std.range.repeat("hello").take(5)` is lazy. Some operations may also decay to ranges of `dchar`, but we'd want to preserve the string type.

On Sunday, 15 March 2015 at 09:13:19 UTC, Walter Bright wrote:
> On 3/14/2015 10:28 PM, deadalnix wrote:
>> I use them all the time, and cringe whenever I code in something else because i
>> don't have them. Once you have /* comments */ in some piece of code, you can't
>> comment blocks without going through hoops. that is very annoying./+ comments +/
>> are one of the simple thing that makes coding in D much more pleasant.
>
> Use:
>
>    version (none)
>    {
>       ...
>    }
>
> instead of:
>
>    /+
>       ...
>     +/
>

Nope, that requires the commented-out part to be syntactically correct. My primary use-case for /+ +/ is during development, when I quickly need to disable specific parts of code. These frequently don't coincide with syntactic boundaries.

> On a related note, see how difficult it is to remove a feature? Every time I propose one, someone pops up and says they built their life around it :-)

At least in this case, it's because they are actually useful, and there is no convenient replacement. Besides, why would you want to remove them again? Just so we can say, "Look, we removed a feature!"? They're so trivial to implement and support, and so easy to learn, that their presence does not add a significant cost.

On Sunday, 15 March 2015 at 09:24:36 UTC, Walter Bright wrote:
> On 3/14/2015 10:28 PM, deadalnix wrote:
>> Not one precisely, but I'm sure we don't need as many as we have. ", `, q", q{,
>> r", x". I've never used several of theses and I'm sure most people here would
>> say the same.
>
> The HexStrings http://dlang.org/lex.html#HexString can be easily replaced with a user defined literal. That's probably a good idea. The others, not so.

This I agree with. Their usefulness is also greatly diminished by them being strings, instead of byte (ubyte?) arrays. When would you actually want to write a string (= text) using hex notation?

On Sunday, 15 March 2015 at 00:14:44 UTC, engnieer wrote:
>
>> Unfortunately, for speech and language processing (synthesis, speech recognition etc) Python is too slow. Everybody uses Python at first, but the serious code that is later put into real world applications is usually written in C or C++. This is a fact. I know people who developed speech analysis frameworks in Python and are now thinking of rewriting it in C++ for commercial purposes.
>>
>> Python is good for protoyping, but if you need fast applications, it is usually C/C++ (or D).
>
>
> What you are saying is not wrong, except for the generalizations to "everybody".
>
> Obviously you are not aware of the other people/industries who use python for non-performane critical applications (not prototype, but real large applications), there are several reasons, but don't want to bore you with details (one of which is the "super structure").
>
> I do wish we were using D everywhere, and I do use it for personal and small tools at the job.
>
> - engineer

Of course, we all can only talk about our own experiences.

Apart from performance issues, for language processing, string handling etc., Python quickly becomes a nightmare (UTF-8). Then there are issues like the one that classes cannot really have private variables.

Sometimes advocacy of Python seems a bit absurd to me when it is along the lines of "Use Python, because it's easy. But don't use real Python, use Cython or Numba (and whatnot), Python is too slow". I.e. "Use it, but don't use it!" This shows that there is something wrong. You don't have this problem with D. You too wish you were using D everywhere, which tells me that the Python + C(++) solution is not optimal.

All I'm saying is that when people start a new project, I advise them to use D instead of Python. But there is no way to win against the cult of Python in scientific programming. It's too easy, too tempting at the start. Instant gratification and the feeling that you're on safe ground. D can't compete with this easily.

Maybe we should invent (or continue with existing efforts) to write a scripting language based on D (or a Python interpreter or something that serves as a bridge to existing technologies (other than C)).

If I have time, I might also put together some code snippets with the most common tasks in programming, like startsWith and so on.

On Sat, 2015-03-14 at 22:12 +0000, deadalnix via Digitalmars-d wrote: […]
> 
> When it come to concurrency, Rust is. None of the other are.

That would imply Rust has the possibility of replacing Spark Ada then?

> Now you can double down on trying to make me prove a negative, but that only makes you sound like a religious zealot.

I am an atheist, religiously so.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Friday, 13 March 2015 at 02:00:08 UTC, Vladimir Panteleev wrote:
> On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu wrote:
>> I'd love us to derive a few action items from this and other feedback.
>
> I think the front page focuses too much on the language itself at the moment. Perhaps we should continue with the direction with forum integration, and devote a good piece of real estate for the ecosystem (e.g. latest code.dlang.org updates) and maybe an IDE screenshot carousel, OSLT. Making it up-front that we have three compilers, a built-in profiler, and tight GDB integration might also be worthwhile.

this and reading the rest of the comments here, i have another suggestion:

let's have four tabbed examples in the front page.

1) simple example
2) vibe.d example
3) advanced example
4) concurrency example