On Sunday, 15 March 2015 at 14:01:00 UTC, bearophile wrote:
> Walter Bright:
>
>> I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful than they are.
>
> I prefer to get rid of /* */ instead :-) Because /++/ can do things /**/ can't.

+1

And on my keyboard, /++/ is easier than /**/ :-)

On Sunday, 15 March 2015 at 14:01:00 UTC, bearophile wrote:
> Walter Bright:
>
>> I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful than they are.
>
> I prefer to get rid of /* */ instead :-) Because /++/ can do things /**/ can't.
>
> Bye,
> bearophile

/*

...

/*/

...

//*/

Is really hard to get with /+ and porting C code would become much more of a pain in the ass. It don't think we have a problem with comment as they are thrown away at the lexer stage, so they do not contribute by much to the language complexity.

On Sunday, 15 March 2015 at 14:59:22 UTC, Sativa wrote:
> On Sunday, 15 March 2015 at 14:15:18 UTC, disme wrote:
>> do you people really want to see this language be more popular? do you? doesnt look like it at all to me, the only few people in those 18+ pages that are actually telling you the real problems are mostly being ignored for futile python, go and rust talk, seriously?
>>
>> let me go ahead and say that no i dont use D, ive found it awhile ago and came back to look at it from time to time which puts me in a perfect spot to tell you that the fundamental problems for new comers are right here, in those posts:
>>
>> page 7 - Leandro Motta Barros' post
>> page 10 - Almighty Bob's first post
>> page 11 - Almighty Bob's post (again)
>> page 14 - rumbu's first post
>> page 17 - Xavier Bigand's post
>> page XX - many of Chris' posts
>> (may have missed a few but those are the ones that jumped out at me where i really went "THIS MAN GETS IT!")
>>
>> yes, those are fundamental problems FOR A NEW COMER! 90% of the posts i see in this thread are a bunch of... i dont even know? advanced "problems" that new comers would have no clue what they are about, only those few posts i mentioned are seeing the real problems.
>>
>> this community seems to be filled with really intelligent, dedicated people capable of solving some of the hardest challenges but you fail to see the tiny little bitty small things that are stopping the new comers and instead you worry about things that are far beyond their scope people...
>>
>> i guess ill find out in a few months when i visit the language again if those posts have been paid attention to, with that said i wonder how many people will reply to this because they havent read until the end (tiny little bitty detail slipping by again?)
>
> Why do you believe that something has to be dumbed down for your sake instead of stepping up and learning learning something that will prove to be more powerful in the end?
>
> I don't think D or anything should kowtow to "KISS". Of course the lazy ignorant masses want this but humanity ultimate suffers... and there is enough simple programming languages for simple people. Do we really want another Python, Go, Java, perl, php, asp, JS, lua, Ruby, Rust... Oh, wait, instead of listing hundreds of languages, just look here:
>
> https://en.wikipedia.org/wiki/List_of_programming_languages
>
> Most of those damn languages are essentially just syntactically different. Python vs Perl vs php? Who cares, it's all the same crap. If all the energy went in to creating a better languages with more power(power != complex) instead of just duplicating the stone wheel then maybe we can get somewhere?
>
> I really find it odd when someone complains about a "feature" but never uses it. e.g., "I don't like /++/", How often do you use it? "Never, I don't like it!"... then whats the problem, if you don't use it then how is it getting in the way of your progress? "Well, because other people use it and I get confused when I see it in their code!". So, instead of allowing them to program the way they want, you want to control them so you don't have to think as hard?
>
> Wouldn't you agree: "The best language is the one that gets out of the way and lets you do exactly what you need to do in the most efficient way(which isn't just about time).

Thank you for this excellent demonstration of what a good strawman is.

On 3/15/2015 4:02 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> 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.

It's not an onerous limitation.


>> 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.

It's the drip-drip-drip of a thousand features that adds up.

Anyhow, it obviously isn't going anywhere.

On 3/15/2015 4:06 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> 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?

1. test data
2. strings that aren't in UTF format
3. strings with other data embedded in them

On Monday, 16 March 2015 at 00:11:37 UTC, Walter Bright wrote:
> It's the drip-drip-drip of a thousand features that adds up.
>
> Anyhow, it obviously isn't going anywhere.

It mostly a problem when features are not orthogonals.

On 3/15/2015 7:46 AM, Sativa wrote:
> Um, This is wrong. You already have simple languages. People are not going to
> choose D no matter how much you dumb it down. What sets D apart is it's advanced
> features... remove them or stop such enhancements and it won't be able to
> compete with any other language.
>
>
> In fact, the opposite thinking should be true. Add the most advanced feature
> rich set to D and then nothing will be able to compete with it. If, on top of
> that, you don't force someone to use them then you have the best of both
> words(power when you need it and simple when you don't).
>

What I mean is anyone can invent something complicated. It takes genius to find the underlying simplicity that is just as (or more) powerful. We should always be looking for the latter.


> There's reasons why people by luxury cars. D is like an Cadillac and Go is like
> a volt. If you turn D in a volt then what will people buy that like Cadillac's?
> (Someone will create a new language trying to make a Cadillac and the whole
> process starts over...)

I like the analogy of D being a fully equipped machine shop, as opposed to a collection of basic hand tools.

When I was younger it was hard working on my car, because I could not afford the right tools. So I made do with whatever was available. The results were lots of scrapes and bruises, much time invested, and rather crappy repairs. Now I can buy the right tools, and boy what a difference that makes! I can get professional quality results with little effort.

(Ever try to install an engine without a proper hoist? Yowsa!)

On Sun, Mar 15, 2015 at 05:12:55PM -0700, Walter Bright via Digitalmars-d wrote:
> On 3/15/2015 4:06 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm@gmx.net>" wrote:
> >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?
> 
> 1. test data

This is about the only valid use case I can think of. And it's really only useful in druntime/Phobos test cases. I can't imagine users would go out of their way to use generate binary test data where string input is desired.


> 2. strings that aren't in UTF format

Uhm... strings that aren't in UTF format really ought to be ubyte[]
(resp. ushort[], uint[]), not string, because pretty much everything in
D that takes a (|w|d)string argument expects UTF encoding.

(Or, in an ideal world where std.encoding is actually sane, we'd use suitable wrapper types for ubyte[] that represent their respective encoding.)


> 3. strings with other data embedded in them

Again, shouldn't these be ubyte[]? Calling them string (i.e.
immutable(char)[]) is a wrong conflation of ubyte with char, that has
led to so much headache in C/C++. D should not repeat this mistake.


T

-- 
English has the lovely word "defenestrate", meaning "to execute by throwing someone out a window", or more recently "to remove Windows from a computer and replace it with something useful". :-) -- John Cowan

On Sunday, 15 March 2015 at 13:45:28 UTC, ponce wrote:
> On Sunday, 15 March 2015 at 04:32:25 UTC, Walter Bright wrote:
>>
>> I'd also prefer to get rid of /+ +/ comments, I thought they'd be more useful than they are.
>
> Using /+ +/ regularly.
> Very useful to comment out large areas of code.

I like /+ +/ myself. It's great for temporarily disabling parts of code.

If stories are wanted, I might as well tell mine.

It is not a success story but as a newcommer to D I feel like writing it down somewhere before forgetting my first impressions. But first, a bit of background.

I'm a CS student and an autodidact before that. I grew up with GNU/Linux and never worked with a Windows environment. My first languages were bash with which I discovered programming, a Scheme/Lisp (SICP) for which I did not really found it any useful use at the time and python in this order. I had later to learn C, C++, java, D and many others but bash, Scheme and python defined my vision of programming.

From bash I got the Unix philosophy (simple bricks that combine well) and a taste for interactivity and incremental development. SICP gave me the mental framework needed to tackle real programming and a taste for functional programming. Python gave me a language that combined almost anything I liked from bash and scheme (well... I still miss my pipes) and the access to the best ecosystem I know about. Great and very specialized libraries, a mostly FOSS-oriented community, great package management (pip), great online docs (always clear, good search functions, examples), virtualenv, many repls and a *lot* of articles and videos on the internet. Most of all it achieved its supreme goal of readability.

I've been using python for many years now, mostly on little projects because I feel like it.

Today my time is mainly divided between teaching, software auditing and reverse-engineering. In the field of offensive security only two languages count: C for understanding low-level code and manipulating library structures directly and python for everything else. Its dev speed and *really really good* libraries (scapy...) make it the way to go for many.

So why use D? Well, one day I grew tired of python and almost at the same time I had a project that had a need for performance. I had tried calling python in C before and it is such a ugly mess that I wanted to do anything to avoid that. There are other ways to link the two (FFI...) but mixing python and C in the same files didn't feel very comfortable. Python's strength is its readability, putting C in it would defeat the purpose.

I had a look at Go, Rust and such but they didn't impress me at the time. Frankly, the one thing that sold D to me was that snippet on the wikipedia page:

import std.stdio : writeln;
import std.range : iota;
import std.parallelism : parallel;

void main()
{
    foreach (i; iota(10).parallel) {
        // The body of the foreach loop is executed in parallel for each i
        writeln("processing ", i);
    }
}

It is funny because I didn't actually have any opportunity to use yet it but it just felt so much like python and yet was so much better (python's multiprocessing is not its best point).

It is anecdotic but after reading everywhere about how fast is compiling D, I was very surprised to see it taking 2s for a regular "Hello World". I understand it better now but at the time I was disapointed.

Porting my python code was interesting. I could basically get quite the same expressiveness but getting to it was harder. At first I couldn't use the D documentation at all, because all the constraints on functions were really frightening, so my first documentation was actually the site http://rosettacode.org/wiki/Rosetta_Code where I learned many basic constructs.

HINT 1: this site is great, either link to and nurture it or do something similar on dlang.org

HINT 2: it took me about a month and a good tutorial on templates (btw, thanks G.Willoughby) to start understanding the full prototypes of standard functions. I really recommend putting the constraint part in slight grey so that it is still here and readable but the immediatly useful part of the prototype stands out.

HINT 3: no beginner cares about how exactly it is compiled or advanced metaprogramming options. This should not be more than mentionned in a "getting started" page. It is cool stuff, it should be said, but it definitely does not fit in an introduction to any language.

The more I used D, the better I liked its functional side (UCFS <3) and its safety. And the fact that it has ranges everywhere is great, but I still wonder why in a language that wants to use ranges everywhere they are so complicated to build... Not everybody wants to build a struct for everything. Python has generators everywhere, why is that? Because the syntax is easy and simple. Either use yield like you would use a return, either build one on the fly with generator expansion:

for i in (2*x for x in range(100) if x%3==0):
    print(x)

The closest I could find is foreach over a function, which is cool but not as easy as yield. InputRange can do more than simple generators but a "real" yield would cover the 90% case IMO.

But right now the real reason why I hesitate advising it to my friends is because of its stability. I mean, come on! I've only been here for something like 5 month and I've seen many propositions to add new features and change others. Right now is discussed the possibility of changing the default constness of variables which would most likely break a lot of code. I can't see how a company could think about investing into a project in D if they can't have any vision of how long it will be before they have to change theyre whole code because "such commenting syntax is better" or anything like that.

HINT 4: D is great. It is a good language already. Stop mutating it! Fix bugs, improve the standard library, work on the ecosystem, reduce compile-time, but do not try breaking things all the time. Don't even think of improving yield as I suggested before, I'd prefer a standard library based solution at this point.

Here is my feeling after some month of D. I know I'm not the typical target so don't take it too seriously but I felt like it wasn't totally pointless to report my experience.