On 7/11/2014 1:40 PM, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Jul 11, 2014 at 04:54:39PM +0000, Chris via Digitalmars-d wrote:
> [...]
>> I remember Java used to be "theeee" best thing ever. After years of
>> using it, however, I found out how restricted the language was / is.
>> Still, it's been a success, because people believed all the
>> propaganda. What matters to me is not so much the odd fancy feature,
>> it's how well the language performs in general purpose programming.
> [...]
>
> I remember how I was skeptical of Java from day 1. Call me a cynic, but
> everytime I hear something being overhyped, I immediately assign
> whatever it is being hyped about as a second class product, and regard
> it with suspicion.

I tend to be like that even for non-computer stuff too, viewing whatever's popular with skepticism. Once in a while it'll backfire and keep me away from something I later realize is actually pretty decent, but I've found *usually* it serves me well. But then, my tastes tend to be uncommon *anyway*, so maybe that's why it works for me ;)

> Same goes with cloud computing, which, as Nick likes
> to say, is just marketing propaganda for "the internet".
>

Yes!!

"Cloud" drives me crazy more than any other word! It's the hipster word for "Internet", and it's EVERYWHERE.

> When I finally got past the hype and tried out the language for myself,
> I found the same thing you did: it's totally straitjacketed, and shoves
> the OO idealogy down your throat even when it obviously doesn't fit. The
> infamous long-winded "class MyLousyApp { public static void main(blah
> blah blah) ... }" is a prime example of shoehorning something obviously
> non-OO into an OO paradigm, just because we want to.  Not to mention
> Java's verbosity, which is only tolerable with IDE support -- total
> fail, in my book. I mean, hello, we're talking about a *language*
> intended for *humans* to communicate with the computer? If we need
> *another* program to help us elucidate this communication, something's
> gone very, very wrong with the language. A language that needs a machine
> to help you write, is by definition a language for communication between
> *machines*, not between humans and machines.
>

While I agree with all of that, there are two things I've always had to give Java credit for: It's classes and module system are what originally taught me that C/C++ aren't ideal and...umm...have some notable downsides...

> That's not to say that Java, the language, (as opposed to the class
> library or the marketing hype) isn't a pretty good language. In fact,
> it's quite a beautiful language -- in the idealistic, ivory tower,
> detached-from-real-life sense of being a perfect specimen suitable for a
> museum piece. Its disconnect from the messy real world, unfortunately,
> makes it rather painful to use in real-life.

Yea, that's one of the things that drew me to D. It came around saying (quite literally) "pragmatic language design" at exactly the time I was noticing how much of a pain ideology-driven and minimalist languages can be.

On Fri, Jul 11, 2014 at 03:08:39PM -0400, Nick Sabalausky via Digitalmars-d wrote:
> On 7/11/2014 1:40 PM, H. S. Teoh via Digitalmars-d wrote:
[...]
> >That's not to say that Java, the language, (as opposed to the class library or the marketing hype) isn't a pretty good language. In fact, it's quite a beautiful language -- in the idealistic, ivory tower, detached-from-real-life sense of being a perfect specimen suitable for a museum piece. Its disconnect from the messy real world, unfortunately, makes it rather painful to use in real-life.
> 
> Yea, that's one of the things that drew me to D. It came around saying (quite literally) "pragmatic language design" at exactly the time I was noticing how much of a pain ideology-driven and minimalist languages can be.

If you really wanna go minimalist, there's BF... :-P

On the other extreme of pragmatism, Larry Wall claims that the reason Perl is useful is because it's a mess, which maps well to the problem space, which is also a mess, which we call reality. :-P  I *will* say that at one point I was quite enamored of Perl, but nowadays I think it goes a little *too* far in the pragmatism, and as a result is rather messy to work with.

One of the big advantages of D was that it's so easy to use when what you need is something simple, so I've been writing quite a lot of little script-like helper programs nowadays in D where in the past I would have used Perl. Unlike Perl, though, D also scales up nicely when what was initially a simple problem grows into a more complex problem. In Perl, there's this threshold of complexity below which it's pretty comfortable to use, but once you pass that point, the seams start to burst and the potholes start to appear, a common sign of which is the appearance of deeply-nested data structures that leads to riddle-like code such as:

	${a{b}{c}}->{$d->{e}}->{f} = ${g[h]{i}->{j}}->{k}[l]->{m};

along with the programming-by-convention that comes along with it. Abstractions in Perl tend to be quite leaky, which is OK with write-once throwaway-after scripts, but as the complexity of the program increases, it becomes a source of frustration and hiding places for bugs.

In D, you simply leave the original script-like core as-is, then bring in the proverbial big guns on top of it to deal with the growing complexity, and the miracle is that the result is all nicely integrated and water-tight. It's quite unlike any other programming language that I've used before, in this respect.


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius

Thanks for posting this. You're right that it is easy to lose perspective.

I agree that the GC phobia is way, WAY, overblown for practical programming. For example, Warp uses the GC, but only for things like initialization, where perf doesn't matter, and for permanent data structures. It doesn't use it on the fast path, and so Warp keeps the convenience and safety of GC without the perf hit.

This was not hard to do.

I understand that Sociomantic does something similar to good effect.

GC phobia is a convenient excuse for people to not use D, people who may have different actual reasons that they don't express for various reasons or may not even realize.

For example, in the 80's, a friend of mine talked with a C++ programmer who fervently and passionately argued that compiler speed was the most important attribute. My friend says no, compile speed is at the bottom of the list of what the programmer care about. Shocked, the programmer asked WTF was he talking about? My friend said "You use Microsoft C++, which is the slowest compiler by a factor of 4. What you actually care about is branding, not speed." And the programmer eventually admitted he was right.

But we still need an answer to the people who believe that GC is the touch of death, that the GC is a troll hiding under a bridge that will pop out at any moment and destroy their program.

On 7/11/2014 10:54 AM, Israel Rodriguez wrote:
> On Friday, 11 July 2014 at 15:30:18 UTC, Chris wrote:
> Let's not
>> forget that zeolots and professional posters will always point out the flaws
>> of D, and blow them out of proportion. "D doesn't have xyz, so it's shit!"
>> Divide et impera (divide and rule).
> Lol, this one made me laugh.


Speaking of inventing reasons to not use D, years ago the reason was "D has only one implementation, so it's too risky to use." Lately, the reason is "D has 3 implementations, so it's too risky to use, there should be only one".

We have to be careful to filter out real reasons from people just pulling our chains.

This is an awesome list, it's almost exactly what I would have written!

On Friday, 11 July 2014 at 19:00:30 UTC, Joakim wrote:
> On Friday, 11 July 2014 at 15:42:04 UTC, simendsjo wrote:
>> On 07/11/2014 05:30 PM, Chris wrote:
>> (...)
>>> Believe me, D's supposed sluggishness as regards GC is
>>> not so important for most applications. I dare say 90% of all
>>> applications are fine with the current GC.
>> (...)
>>
>> I agree with this. The bottlenecks i my applications are MySQL and
>> Microsoft Office (Excel, Powerpoint, or even just plain COM). The same
>> bottlenecks as I get when using C#. Of course, it depends a lot on what
>> you do, but for my use (and yours, and probably many others), the GC
>> performance is something you can probably safely ignore.
>
> Ah, but that's because you're comparing it to C#, not languages that don't use GC.  The big problem for D is that the market for programming languages has bifurcated since D was created, with the performant native-compiled languages like C/C++/Obj-C on one side and the much larger market for easier to use but much less performant, what used to be called "scripting," languages like ruby/python/java on the other.  Trying to be a better C++, by borrowing some ease of use features like GC or reflection from the scripting languages, leaves D stuck in the middle right now, neither here nor there.
>
> Who still uses native-compiled languages?  Performance-sensitive games, server applications that squeeze out performance, like number-crunching or search engines, and desktop apps that need the performance, that's about it.  Everything else has either gone to the web with a scripting language backend or mobile.  I hear that even enterprise LOB desktop apps are mostly written in Java/C# these days, because they just don't need the speed of a native language and can crank the code out quicker that way.
>
> However, mobile could be D's saving grace, as native development is back on iOS and even Android is moving to Ahead-Of-Time compiling with the next release.  Too bad D doesn't work on mobile, even though some of us are working on getting it there.

I agree. This is a big pain for me too.


> D should focus on the native end of the market, by trying to be the easier way to get most of the performance.  You're not going to get the scripting guys now, because native is just too hard for them.  If D can assert itself in that smaller niche of native languages, it might have enough juice to go after the other end later.  I don't think either happens without a commercial implementation, community development doesn't cut it.  Linux didn't take off till long after it got commercial vendors on board, the same will be true here.
>
> I don't mean to be pessimistic about D's goal of being usable by all, from scripting to systems, as D may actually be good enough to get there one day.  I just think you're not going to get there without focusing on taking over a niche at a time, particularly the niche best suited to D right now, mobile.

A niche for a general purpose language?

On Friday, 11 July 2014 at 19:56:20 UTC, Chris wrote:
>> I don't mean to be pessimistic about D's goal of being usable by all, from scripting to systems, as D may actually be good enough to get there one day.  I just think you're not going to get there without focusing on taking over a niche at a time, particularly the niche best suited to D right now, mobile.
>
> A niche for a general purpose language?

Name one "general purpose language" that currently crosses the native->scripting divide and has good usage on both ends of the market.  It doesn't exist, because it's almost impossible to do.  Even if your goal is to be general purpose, you have to do it by taking on one niche at a time, which is even harder because you have to have your eye on staying general purpose the whole time.  It's an extremely difficult balancing act, with one hand tied behind your back.

I think D could do it someday, but not the way the market is today.  Right now, it's too easy for many developers to slap together a webapp on rails or django and then simply scale up their hardware when necessary.  Maybe that all changes in the future and efficiency becomes more of a concern on the server, perhaps when the market matures, but we're not there yet.

In the meantime, mobile is where most new native development has moved, so D has to really hit that fertile ground.  I also think big data could be big for D, Don mentioned D brought their costs down a lot in his DConf talk.

On Friday, 11 July 2014 at 19:46:25 UTC, Walter Bright wrote:
> I agree that the GC phobia is way, WAY, overblown for practical programming.

I agree with this, as well, but it's a generalization.

There are some applications that the current GC is not suitable for, but D provides a plethora of features for disabling the GC or managing memory in other ways (very cool), so I don't see a reason to not use D even for the most demanding problem.  I love the GC for some things I do, but can't use it for other things I do.  For the vast majority of applications I see people using D for, however, I see no reason why there should be any worry about the GC.

The problem, however, when managing one's own memory is that one cannot use some of the built-in types, like Exceptions, that are instantiated deep within the runtime.  A solution to this would likely quiet some of the clamoring, IMO.

I would be interested in hearing any suggestions for disabling the GC and still making use of Exceptions, dynamic arrays, etc... using a user-supplied memory manager.  Maybe something like this already exists, and people like me just aren't aware of it.

Being a novice still, I don't know what the solution is.  At the moment I exploring region-based memory management (nice example at http://en.wikipedia.org/wiki/Region-based_memory_management).  I also saw some proposals for something like gc.pushAllocator(myAllocator)/gc.popAllocator(), which would be nice.

Mike

On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via Digitalmars-d wrote:

> - Metaprogramming. Templates in C++ scarred many for life. Templates in
>   D are actually a pleasure to use.
>
> - CTFE. Coupled with metaprogramming, this is a total killer combination
>   that I've yet to see another language beat.
>
> - Slices. Finally, a systems-level language whose string support isn't
>   crippled (C), maimed (C++), or otherwise handicapped (Java). And this
>   extends to arrays in general. While there *are* other language with
>   nice string/array manipulation support, D is the only one I know of
>   that does it without sacrificing performance.
>
> - Ranges. It can totally revolutionize the way you approach programming.
>   And, with metaprogramming/CTFE, they can still perform as fast as
>   non-range-based code. Total win!
>
> - Extended meaning of purity: IMO it's a total stroke of genius to
>   define "weak purity" that allows you to implement pure functions (in
>   the Haskell sense) using mutating primitives (loops and assignments,
>   etc.). While the current compilers don't really do that much with this
>   presently, there is a lot of potential here that may turn this into a
>   killer feature.
>
> - Built-in unittests. Sounds trivial, but I can testify to its value in
>   dramatically improving the quality of my code. I've worked with large
>   C/C++ codebases, and most of them don't even bother with any kind of
>   unit testing -- it's up to the programmer to test everything, and we
>   just take his word for it -- and simply accept the countless stream of
>   bugs that come thereafter as a fact of life. Of the rare few that
>   actually do have tests, the tests are usually (1) outdated, (2)
>   commented out 'cos nobody cares to update them, (3) ignored by the
>   coders anyway 'cos they can't be bothered to switch to another
>   language in another framework just to write tests that nobody will run
>   while having their hands tied behind their back. D's built-in unittest
>   blocks is a total game changer in this area, in spite of its
>   simplicity (which some people have complained about).
>
>    - Along these lines, static assert totally rawkz. It ensures, at
>      *compile-time*, that assumptions in your code haven't been violated
>      by a careless code change, forcing the person who made the change
>      to fix it (rather than introducing a possibly subtle error that
>      will only be uncovered months down the road on the customer's
>      production site).
>
> - The fastest regex library known on the planet (thanks to, guess what?
>   metaprogramming and CTFE!). I'm a regex aficionado, and this is a
>   total big deal in my book.
>
> - Built-in Unicode support. Compiler-level support for Unicode is
>   something C/C++ sorely lacks, and that immediately puts them in the
>   "legacy" category. LibICU is a nightmare to use. D, however, lets you
>   treat Unicode directly in the language. (Full Unicode compliance isn't
>   quite there yet, but we're getting pretty close.) Modern languages
>   like Java/C# also have built-in Unicode support, so D is at least on
>   par with them. C/C++ is definitely behind in this category, though.
>
> These are just language-level cool stuff. At a higher level, we also
> have:
>
> - rdmd: run your D programs like scripts, yet with native compiled
>   performance. Rawkage!
>
> - Dustmite: a totally revolutionary tool IMO, that changes finding
>   heisenbugs from an impossible game of chance to something that
>   actually has hope of being fixed within reasonable amounts of time.
>
> - vibe.d: I haven't used it myself, but from what I hear, it's extremely
>   awesome.
>

Great list,  I'll add a couple more:

 - GDC & LDC - D on ARM and other platforms is possible thanks to talent donated to these efforts.

 - D is universal -  I don't know how to articulate this, but I'm sick of learning so many languages for different purposes and different platforms.  I'm beginning to use D for just about everything, and I don't have to worry so much about whether I'm on Windows or Linux.  I'm even using D to write low-level drivers for my micrcontroller.  I use it for my build scripts, automating my builds in the same language I'm building.  D, one language to rule them all.


Mike

On Friday, 11 July 2014 at 17:15:36 UTC, H. S. Teoh via Digitalmars-d wrote:
> On Fri, Jul 11, 2014 at 03:30:15PM +0000, Chris via Digitalmars-d wrote:
>> I have followed the recent discussions about D and I can see the usual
>> pattern, to wit GC, Go (or whatever) is so much better, everyone
>> blaming each other for not contributing, not being allowed to
>> contribute blah.
>
> Well, this forum *is* for discussing ways of improving D, so it
> shouldn't be surprising that we constantly find things to nitpick about.
> :-) It doesn't mean at all that D is lousy or the community is bad, 'cos
> if it were so, we wouldn't even be here to begin with. We're here 'cos
> we care, and we complain 'cos we care enough to want things to improve.
>
>
>> First of all, I am in no position to criticize anyone who is
>> contributing to the language. I don't contribute, because I don't have
>> the time to do so.  Indeed I have huge, massive respect for everyone
>> who contributes to D. The only thing I do is to actually use the
>> language and tell everyone about it.  I have developed a screen reader
>> plug in in D (using C libraries) that was ridiculously easy to
>> integrate on Windows as a DLL. I used vibe.d to create a lightning
>> fast online version of the screen reader. Believe me, D's supposed
>> sluggishness as regards GC is not so important for most applications.
>> I dare say 90% of all applications are fine with the current GC. I
>> compiled both applications with dmd (testing phase) not with ldc or
>> gdc and they are very fast.
>
> I agree. I'm still convinced that GC phobia is blown out of proportion
> -- I used to be in that camp, so I totally sympathize with where they're
> coming from -- but as you say, only a small percentage of applications
> actually need to squeeze every last cycle out of the CPU such that the
> GC actually starts to make a significant difference in performance. Most
> applications work just fine with the GC, and in fact, I'd argue that
> they work *better* with the GC, because manual memory management is
> *hard* (just look at how many security exploits are caused by memory
> management mistakes) and tedious (look at how often the same memory bugs
> are repeated over and over).  GC-supported code is cleaner to read,
> easier to write, and in many cases, the simpler design of the code
> reduces the likelihood of bugs and eliminates a whole class of bugs.
> Sure you pay for that by short pauses every now and then, but seriously,
> 90% of applications don't even *care* about such pauses.
>
> For applications with slightly higher performance demands, gdc -O3 (or
> whatever the LDC equivalent is) generally improves performance by about
> 20% or so above dmd. In my own compute-intensive projects, I have
> consistently noted about a 20-30% performance improvement when compiling
> with gdc, compared to dmd. That's pretty significant, because GC pauses
> are generally nowhere near that percentage, so just by recompiling with
> gdc already eliminates the perceived GC performance issue for 95% of
> applications. Besides, avoiding frequent small allocations also reduces
> most of the workload of the GC, so you can still get pretty far without
> totally turning it off.
>
> So it's really only the remaining 5% of applications that really,
> absolutely, *have* to go GC-less (or control it very tightly). They do
> happen to have supporters of the rather vocal kind, so we tend to hear
> from them a lot more, but that by no means is representative of the
> grand scheme of things as far as the GC is concerned!
>
>
> [...]
>> Let's first make a list of things that have been achieved with D and
>> that are on a par with or even bettar than in other languages (C, C++,
>> C#, Go, Rust ...).
>
> I don't know C#, Go, or Rust, so I can't really say much on that front,
> but at least as far as C/C++ are concerned, D totally beats them flat in
> the following points IMO:
>
> - Metaprogramming. Templates in C++ scarred many for life. Templates in
>   D are actually a pleasure to use.
>
> - CTFE. Coupled with metaprogramming, this is a total killer combination
>   that I've yet to see another language beat.
>
> - Slices. Finally, a systems-level language whose string support isn't
>   crippled (C), maimed (C++), or otherwise handicapped (Java). And this
>   extends to arrays in general. While there *are* other language with
>   nice string/array manipulation support, D is the only one I know of
>   that does it without sacrificing performance.
>
> - Ranges. It can totally revolutionize the way you approach programming.
>   And, with metaprogramming/CTFE, they can still perform as fast as
>   non-range-based code. Total win!
>
> - Extended meaning of purity: IMO it's a total stroke of genius to
>   define "weak purity" that allows you to implement pure functions (in
>   the Haskell sense) using mutating primitives (loops and assignments,
>   etc.). While the current compilers don't really do that much with this
>   presently, there is a lot of potential here that may turn this into a
>   killer feature.
>
> - Built-in unittests. Sounds trivial, but I can testify to its value in
>   dramatically improving the quality of my code. I've worked with large
>   C/C++ codebases, and most of them don't even bother with any kind of
>   unit testing -- it's up to the programmer to test everything, and we
>   just take his word for it -- and simply accept the countless stream of
>   bugs that come thereafter as a fact of life. Of the rare few that
>   actually do have tests, the tests are usually (1) outdated, (2)
>   commented out 'cos nobody cares to update them, (3) ignored by the
>   coders anyway 'cos they can't be bothered to switch to another
>   language in another framework just to write tests that nobody will run
>   while having their hands tied behind their back. D's built-in unittest
>   blocks is a total game changer in this area, in spite of its
>   simplicity (which some people have complained about).
>
>    - Along these lines, static assert totally rawkz. It ensures, at
>      *compile-time*, that assumptions in your code haven't been violated
>      by a careless code change, forcing the person who made the change
>      to fix it (rather than introducing a possibly subtle error that
>      will only be uncovered months down the road on the customer's
>      production site).
>
> - The fastest regex library known on the planet (thanks to, guess what?
>   metaprogramming and CTFE!). I'm a regex aficionado, and this is a
>   total big deal in my book.
>
> - Built-in Unicode support. Compiler-level support for Unicode is
>   something C/C++ sorely lacks, and that immediately puts them in the
>   "legacy" category. LibICU is a nightmare to use. D, however, lets you
>   treat Unicode directly in the language. (Full Unicode compliance isn't
>   quite there yet, but we're getting pretty close.) Modern languages
>   like Java/C# also have built-in Unicode support, so D is at least on
>   par with them. C/C++ is definitely behind in this category, though.
>
> These are just language-level cool stuff. At a higher level, we also
> have:
>
> - rdmd: run your D programs like scripts, yet with native compiled
>   performance. Rawkage!
>
> - Dustmite: a totally revolutionary tool IMO, that changes finding
>   heisenbugs from an impossible game of chance to something that
>   actually has hope of being fixed within reasonable amounts of time.
>
> - vibe.d: I haven't used it myself, but from what I hear, it's extremely
>   awesome.
>
> I'm sure there are many other items that can be added, but this should
> be a good start. :)
>
>
> T

I think you could write an article of kind "why use D"