On Sun, Mar 10, 2013 at 11:50 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:

> The more I deal with this language, the more I love it, and the more
> frustrating it is to deal with other languages (much as I like many of
> them as
> well). What we have isn't perfect, but overall, it's so clean and powerful
> that it's an absolute blast to work with. It's so amazingly easy to do so
> many
> things in it that are often frustratingly difficult in other languages.
> Ranges
> in particular make a huge difference in writing nicely idiomatic and
> straightforward code, but the language design as a whole is great (much as
> it
> still has a few warts - like all languages do).
>
> So, I just felt like saying thanks to everyone who's put work into D and continues to do so. Keep up the good work!
>
> Now, if only I could use it at work... :)
>
> - Jonathan M Davis
>

In order to survive, one must become necessary for others. In case of D, all it takes to become irreplaceable is to have a bunch of libraries in D, that have no alternatives in other languages. Perhaps the uniqueness is not in what those libraries would do, but in how would those libraries do it. I believe the revamping of D's compile-time reflection that Andrei talked about some time ago is extremely important, because that would allow writing truly irreplaceable libraries.

-- 
Bye,
Gor Gyolchanyan.

On Sun, 10 Mar 2013 14:32:42 +0400
Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:

> On Sun, Mar 10, 2013 at 11:50 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
> 
> > The more I deal with this language, the more I love it, and the more
> > frustrating it is to deal with other languages (much as I like many
> > of them as
> > well). What we have isn't perfect, but overall, it's so clean and
> > powerful that it's an absolute blast to work with. It's so
> > amazingly easy to do so many
> > things in it that are often frustratingly difficult in other
> > languages. Ranges
> > in particular make a huge difference in writing nicely idiomatic and
> > straightforward code, but the language design as a whole is great
> > (much as it
> > still has a few warts - like all languages do).
> >
> > So, I just felt like saying thanks to everyone who's put work into D and continues to do so. Keep up the good work!
> >

///ditto


> In order to survive, one must become necessary for others. In case of D, all it takes to become irreplaceable is to have a bunch of libraries in D, that have no alternatives in other languages.
> 

That's a very good point. Take a look at the biggest most common languages out there. For the most part, the merits of the language itself has rarely been as significant a factor in the language's adoption as the ability to do something that other languages didn't offer:

C/C++: The native Unix language.

Obj-C: The native Apple language.

Ruby: Even if you consider the language itself perfect, it still never would have been on the map were it not for Rails and it's at-the-time original approach to web apps.

Java: Sandboxing, safety and promises of "write once run anywhere", at a time when such things were nearly non-existent in the major languages.

bash/sh: How else were you gonna string together CLI commands, usable on virtually any Unix system?

batch: How else were you gonna string together CLI commands, usable on virtually any Windows system?

SQL: What other DB query lang you gonna use?

JavaScript: What other language you gonna use for client-side web?

PHP: Server-side web scripting that can run on any super-cheap shared web host? It's the only option.

C#: It's MS's big push. If you're a Win developer, that alone is a pretty strong case because MS products can safely be assumed to succeed by default and only fail if they're really, really bad. An interesting departure from most software which tends to be the other way around.

Ie, While the merits of the languages themselves DO generally have at
least some relevance, in most cases the really *BIG* factor is
being the only significant choice if you want XXXX lib or platform.
Python is probably about the only one I can think of that might be an
exception to that.

On Sun, Mar 10, 2013 at 08:19:06AM -0400, Nick Sabalausky wrote:
> On Sun, 10 Mar 2013 14:32:42 +0400
> Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
> 
> > On Sun, Mar 10, 2013 at 11:50 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
> > 
> > > The more I deal with this language, the more I love it, and the more frustrating it is to deal with other languages (much as I like many of them as well). What we have isn't perfect, but overall, it's so clean and powerful that it's an absolute blast to work with. It's so amazingly easy to do so many things in it that are often frustratingly difficult in other languages. Ranges in particular make a huge difference in writing nicely idiomatic and straightforward code, but the language design as a whole is great (much as it still has a few warts - like all languages do).
> > >
> > > So, I just felt like saying thanks to everyone who's put work into D and continues to do so. Keep up the good work!
> > >
> 
> ///ditto

///ditto :)

After programming in D, I just find C/C++ (which I have to use at work) really painful. I keep finding myself wishing that some piece of code was written in D, and thinking that if that buggy piece of code were only written in D, things would be a lot different. :)


[...]
> bash/sh: How else were you gonna string together CLI commands, usable on virtually any Unix system?

One word: Perl. ;-) (But I admit I am greatly biased.)


[...]
> JavaScript: What other language you gonna use for client-side web?
[...]

Coming from you, I find that rather funny, and a little disturbing. ;-)


T

-- 
He who laughs last thinks slowest.

On Sun, 10 Mar 2013 13:30:26 -0700
"H. S. Teoh" <hsteoh@quickfur.ath.cx> wrote:

> On Sun, Mar 10, 2013 at 08:19:06AM -0400, Nick Sabalausky wrote:
> > On Sun, 10 Mar 2013 14:32:42 +0400
> > Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:
> > 
> > > On Sun, Mar 10, 2013 at 11:50 AM, Jonathan M Davis <jmdavisProg@gmx.com>wrote:
> > > 
> > > > The more I deal with this language, the more I love it, and the more frustrating it is to deal with other languages (much as I like many of them as well).

D is the only language where I found I liked it *more* the more I used it. Everything else has been the other way around: The more I use them, the more I get frustrated with their downsides and limitations.

> 
> [...]
> > JavaScript: What other language you gonna use for client-side web?
> [...]
> 
> Coming from you, I find that rather funny, and a little disturbing. ;-)
> 

Heh :), well, regardless of my opinions of it though, the biggest reason for JS's (unfortunate) success is not anything inherent about the JS language itself, but simply because: for all the many people who want to do a bunch of DHTML and such, it's the only option. (And yea, Java applets and Flash were client-side, but those didn't actually enable DHTML, AFAIK. Only JS could do that.)

> --
> He who laughs last thinks slowest.

"Hee hee hee hee hee...I don't get it!" -- Scooby Doo

On Sunday, 10 March 2013 at 10:33:10 UTC, Gor Gyolchanyan wrote:
>
> In order to survive, one must become necessary for others. In case of D,
> all it takes to become irreplaceable is to have a bunch of libraries in D,
> that have no alternatives in other languages. Perhaps the uniqueness is not
> in what those libraries would do, but in how would those libraries do it. I
> believe the revamping of D's compile-time reflection that Andrei talked
> about some time ago is extremely important, because that would allow
> writing truly irreplaceable libraries.

A good start is to support a particular industry that no one else is currently catering to in enough detail. If we could figure out who is using D commercially to try and figure out what is seen as being the main strengths, then the language and its libraries could be strengthen further in those areas.

I will suggest that a great way to get that information is through a user survey, where users can specify what they like or dislike, what their main use cases are, what industry they use D in, and so forth.

--rt

On Monday, March 11, 2013 01:47:34 Rob T wrote:
> On Sunday, 10 March 2013 at 10:33:10 UTC, Gor Gyolchanyan wrote:
> > In order to survive, one must become necessary for others. In
> > case of D,
> > all it takes to become irreplaceable is to have a bunch of
> > libraries in D,
> > that have no alternatives in other languages. Perhaps the
> > uniqueness is not
> > in what those libraries would do, but in how would those
> > libraries do it. I
> > believe the revamping of D's compile-time reflection that
> > Andrei talked
> > about some time ago is extremely important, because that would
> > allow
> > writing truly irreplaceable libraries.
> 
> A good start is to support a particular industry that no one else is currently catering to in enough detail. If we could figure out who is using D commercially to try and figure out what is seen as being the main strengths, then the language and its libraries could be strengthen further in those areas.
> 
> I will suggest that a great way to get that information is through a user survey, where users can specify what they like or dislike, what their main use cases are, what industry they use D in, and so forth.

Well, it seems like the game industry might be the place where we could hit it big given the interest that some of those guys have in D, and there's a game company that Walter's been supporting by working on some of the features that they need in order to write their next game in D. But the game industry also seems to be the sort of industry that rolls a lot of its own stuff given their rather insane performance requirements and whatnot. If we could better support them, that would be great, but I have no clue what kinds of libraries they would actually be looking to use, and it wouldn't surprise me at all if the sort of stuff that they would use is stuff that pretty much no one else would have any interest in.

- Jonathan M Davis

On Monday, 11 March 2013 at 00:58:22 UTC, Jonathan M Davis wrote:
> Well, it seems like the game industry might be the place where we could hit it
> big given the interest that some of those guys have in D, and there's a game
> company that Walter's been supporting by working on some of the features that
> they need in order to write their next game in D. But the game industry also
> seems to be the sort of industry that rolls a lot of its own stuff given their
> rather insane performance requirements and whatnot. If we could better support
> them, that would be great, but I have no clue what kinds of libraries they
> would actually be looking to use, and it wouldn't surprise me at all if the
> sort of stuff that they would use is stuff that pretty much no one else would
> have any interest in.
>
> - Jonathan M Davis

The half-float type comes to mind, I think that one may be reusable for game devs.

Yes, they do need insane performance, but even if a library implementation is a bit slower, it can still be used for rapid prototyping and optimized later with a roll your own if not fast enough. I've done that in C++ using the std lib, later replacing what was too slow or used too much memory with a hand crafted version.

No point guessing though, the users will have to indicate what they need.

--rt

On Sun, Mar 10, 2013 at 01:30:26PM -0700, H. S. Teoh wrote: [...]
> After programming in D, I just find C/C++ (which I have to use at work) really painful. I keep finding myself wishing that some piece of code was written in D, and thinking that if that buggy piece of code were only written in D, things would be a lot different. :)
[...]

<anecdote>

Case in point: just today, I wanted to add some simple caching to a compute-intensive C++ program in order to improve performance on large data sets. I needed to map a particular combination of indices (in this case, 3 ints) to a cached value, so I thought, this is the perfect use case for unordered_map, so I'll just make a struct of the 3 ints to serve as key. Easy, right?  I immediately ran into a series of obstacles:

- First, unordered_map instantly gave me a compile error: "you didn't
  specify -std=c++11", said the compiler, "which is still 'experimental'
  so we didn't enable that for you by default, and so this header called
  unordered_map that you #included can't be compiled". Right, now I
  remember. STL before C++11 was so ridiculous as to NOT have a standard
  hash type. And now it's 2013 and g++ is still defaulting to the *old*
  C++?! Sigh. OK, no problem, they finally got their act together, so
  stick -std=c++11 into the build script. No problem, right?

- Ahem. Next, the compiler complains, "you wrote a template name with no
  parameters; that's illegal!" Perfectly legal complaint, but the line
  concerned read:

	std::unordered_map::iterator it = fcache.find(key);

  Fixing the compiler error required me to change this already-verbose
  line to:

	std::unordered_map<cache_key_type, vertex_set>::iterator it = fcache.find(key);

  Argh! What is this, Java?! How I miss D's type inference... The only
  way to make this *not* painful was to use a typedef. I feel like
  applying layers of bandages just to fix an underlying, deeply wrong
  language maldesign.

- Next problem: due to the lack of a GC, vertex_set was originally
  implemented to automatically deallocate its memory upon destruction,
  so the only way I could return the cached value was to copy it, which
  offset some of the benefit of caching in the first place. Since this
  was very old code which I'm slating for replacement with a D version
  anyway (yay!), I wasn't going to bother with implementing reference
  counting, etc.. So I said, let's leave it for now, even if we're
  wasting cycles/memory to copy the cached value, it should still be
  faster than recomputing it from scratch every time.

- And then another roadblock: the compiler says, "hey, buddy, std::hash
  hasn't been specialized for cache_key_type yet, so it doesn't know how
  to compute the hash value of the key, and so I can't instantiate that
  template for you!".

At this point, I threw up my hands and said, forget it, I'm done with this nonsense. I had intended this to be a quick fix, to fix a performance issue with the old program until the new D version is ready for general use. But now I have to write my own hash function just to use a struct of ints as key?! Seriously, in D, this change would have taken just a few lines of code. For all their bugs and flaws, even D's current broken built-in AA's could handle structs as keys without requiring additional user effort. In C++, I have to do the above baroque dance, only to get an inferior solution (copying of vertex_set because of no GC). What a total waste of time! I'd rather be spending all that effort to work on the D replacement instead!!

Sigh. D may have its warts, but it's already so awesome that it has totally spoiled me for other languages.

</anecdote>


T

-- 
Doubtless it is a good thing to have an open mind, but a truly open mind should be open at both ends, like the food-pipe, with the capacity for excretion as well as absorption. -- Northrop Frye

On Monday, 11 March 2013 at 05:24:34 UTC, H. S. Teoh wrote:
> - Ahem. Next, the compiler complains, "you wrote a template name with no
>   parameters; that's illegal!" Perfectly legal complaint, but the line
>   concerned read:
>
> 	std::unordered_map::iterator it = fcache.find(key);
>
>   Fixing the compiler error required me to change this already-verbose
>   line to:
>
> 	std::unordered_map<cache_key_type, vertex_set>::iterator it = fcache.find(key);
>
>   Argh! What is this, Java?! How I miss D's type inference... The only
>   way to make this *not* painful was to use a typedef.

Tip: Since you've already enabled C++11 extensions, you could just do:

    auto it = fcache.find(key);

It... it... almost looks like D? :)

IMO, the redefinition of 'auto' to mean type inference is the biggest improvement in C++11.

Lars

On 2013-03-11 06:22, H. S. Teoh wrote:
>    And now it's 2013 and g++ is still defaulting to the *old* C++?!

I don't mind having to add -std=c++11 as much as dealing with its incomplete implementation. Still have to use the pcre library for regular expressions.
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.200x
Waiting gets me nervous, so in the mean time I'll rather write more D.

> - And then another roadblock: the compiler says, "hey, buddy, std::hash
>    hasn't been specialized for cache_key_type yet, so it doesn't know how
>    to compute the hash value of the key, and so I can't instantiate that
>    template for you!".

Oh, yes, been through this. Why is there no hash function for const char*?
The second thing is that not everything has a string representation that can be output on screen without doing extra processing. to_string just barely started working in newest MinGW. If you don't have that available and ask for a different but still _simple_ way to convert a number to string, you are shown the good old stream code:

    std::stringstream ss; ss << number; out = ss.str();

Seriously? If I could at least chain that...

    out = std::stringstream(number).str();

Unfortunately, no. So I end up adding my own functions in every project for many trivial tasks, which should be doable out-of-the-box with minimal effort. Yep, to_string helps, but C++11 and its complete support are coming much too late. Therefore, being quite impatient, I'd also like to say thanks for D. :)