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. Same goes with cloud computing, which, as Nick likes to say, is just marketing propaganda for "the internet".

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.

Then there's the lack of generics until the n'th revision, and when it finally came, it was lackluster (google for issues caused by type erasure in Java sometime). D totally beats Java in this area IMO.

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. Well, except with the help of automated tools like IDEs and what-not, which makes one wonder, if we need a machine to help us communicate with a machine, why not just write assembly language instead? But I digress. :-P


[...]
> Mind you, D is a hindsight language, which makes it wiser. Does it have flaws? Yes. I come across them sometimes. Is there a language without flaws? If there is, tell me about it.

When I was still using C/C++ for my personal projects, the problems I keep running into drove me to dream about what I'd like in an ideal language. I tried writing my own, but didn't get very far -- not everyone is a Walter Bright, after all. ;-) So I searched online instead -- and found that D is the one language that's closest to my idea of what an ideal language should be. There are some things about it that aren't quite up to my ideals, but there are also many other areas where it *exceeded* my ideals. So in spite of whatever warts or wrinkles D may have, it's still the best language out there IMO.


> I'm very pragmatic, D is a good tool and, being community driven, there is a real chance of making it a fantastic tool.  Individual features are not everything.

Agreed, it's the synergy of multiple complementary features coming together, that really makes the language shine. Templates + CTFE + static if, is one example I can think of. Together, they make a total killer combination in the world of metaprogramming IMO. I'm sure you can think of several other synergistic combinations in D.


T

-- 
Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine

On Fri, Jul 11, 2014 at 05:39:30PM +0000, Chris via Digitalmars-d wrote: [...]
> Thanks. That's a nice list. This is what I was talking about, the experience with D, what you can achieve with it and how it compares with other languages. We need more of this. I have the feeling sometimes that to an outsider D might look like an eternally unfinished business. A nice playground for programmers, but not for production, which is absolutely not true. The GC issue is sometimes presented as "the language will stand or fall with this". As you noted and which is also my experience, the GC issue ain't that big. 90-95% of all applications can live with it.

Oh, and how did I forget UFCS? I think some of us were a bit hesitant about this at first, but coupled with ranges, it has opened up a whole new way of writing (and thinking about) your program:

	// UFCS FTW! ;-)
	auto formatYear(int year, int monthsPerRow)
	{
		return datesInYear(year)
			.byMonth()
			.chunks(monthsPerRow)
			.map!(row => row.formatMonths()
					.array()
					.pasteBlocks(colSpacing)
					.join("\n"))
			.join("\n\n");
	}

(Shamelessly quoted from my article:

	http://wiki.dlang.org/Component_programming_with_ranges

;-))


T

-- 
Don't modify spaghetti code unless you can eat the consequences.

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.

It is true though. I have only been keeping up with D for like the last year or so and have found that its missing many things that i would like it to do by itself, without the help of C/C++. Multimedia and graphics for example. D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an exception because...well...every OS out there has OpenGL...

Apart from that GC is a concern to many. I can see why GC would not be needed for a systems language but i see D primarily as a General Software Programming language where GC is most needed.

On Friday, 11 July 2014 at 17:54:38 UTC, Israel Rodriguez wrote:
> Lol, this one made me laugh.
>
> It is true though. I have only been keeping up with D for like the last year or so and have found that its missing many things that i would like it to do by itself, without the help of C/C++. Multimedia and graphics for example. D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an exception because...well...every OS out there has OpenGL...
>
> Apart from that GC is a concern to many. I can see why GC would not be needed for a systems language but i see D primarily as a General Software Programming language where GC is most needed.


Right not i use C# are my primary language where i can do everything and anything i need but thats only because the .NET framework provides nearly everything i need without the help of C/C++. The only thing i need is win32 APIs.

On Friday, 11 July 2014 at 17:41:41 UTC, H. S. Teoh via Digitalmars-d wrote:
> [...]
>> Mind you, D is a hindsight language, which makes it wiser. Does it
>> have flaws? Yes. I come across them sometimes. Is there a language
>> without flaws? If there is, tell me about it.
>
> When I was still using C/C++ for my personal projects, the problems I
> keep running into drove me to dream about what I'd like in an ideal
> language. I tried writing my own, but didn't get very far -- not
> everyone is a Walter Bright, after all. ;-) So I searched online instead
> -- and found that D is the one language that's closest to my idea of
> what an ideal language should be. There are some things about it that
> aren't quite up to my ideals, but there are also many other areas where
> it *exceeded* my ideals. So in spite of whatever warts or wrinkles D may
> have, it's still the best language out there IMO.
>

I went down a similar path. Always frustrated with existing languages. Then I accidentally discovered D and I knew that was it! It killed so many birds with one stone. Unicode, C-interfaceable (if that's a word), native compilation to begin with, then I discovered all the nice features and I've become a better programmer simply by trying to understand D. It gives me more freedom to put human thought into a computer, to model our world in terms a computer can understand, and not the other way around.

I still don't get why people who put up with other languages like Java and C++, and patiently wait years for simple improvements, say, when they see D, "it doesn't have xyz*, it's shit!" I just don't get it.

*(usually GC or thread related)

On Friday, 11 July 2014 at 17:54:38 UTC, 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.
>
> It is true though. I have only been keeping up with D for like the last year or so and have found that its missing many things that i would like it to do by itself, without the help of C/C++. Multimedia and graphics for example.

> D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an exception because...well...every OS out there has OpenGL...

Why reinvent the wheel, when D can interface to the wheel. A lot of things are programmed in C/C++. Other languages use modules (Python, Java) to access existing C libraries. D can do it straight away. I cannot tell you how much it has helped me. I depend on C libraries not because I use D, but because the libraries are useful and well established / tested / sound.

> Apart from that GC is a concern to many. I can see why GC would not be needed for a systems language but i see D primarily as a General Software Programming language where GC is most needed.

I forgot to mention that the fact that D implements the Thompson algorithm for regular expressions made me smile. All other languages insist on inefficient algorithms.

On Friday, 11 July 2014 at 18:13:52 UTC, Chris wrote:
> On Friday, 11 July 2014 at 17:54:38 UTC, 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.
>>
>> It is true though. I have only been keeping up with D for like the last year or so and have found that its missing many things that i would like it to do by itself, without the help of C/C++. Multimedia and graphics for example.
>
>> D ALWAYS has to rely on C/C++ libraries for this. OpenGL is an exception because...well...every OS out there has OpenGL...
>
> Why reinvent the wheel, when D can interface to the wheel. A lot of things are programmed in C/C++. Other languages use modules (Python, Java) to access existing C libraries. D can do it straight away. I cannot tell you how much it has helped me. I depend on C libraries not because I use D, but because the libraries are useful and well established / tested / sound.
>
>> Apart from that GC is a concern to many. I can see why GC would not be needed for a systems language but i see D primarily as a General Software Programming language where GC is most needed.

This is true, but theoretically i feel this is wrong because its like putting training wheels on your bike. Know what i mean?

Anyways thats just how "Feel" but maybe youre right, in that, maybe that isnt the right way to go...

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

Great description! Even if I do not agree to everything especially C++ related :)

I think all this advantages should visible for everyone why is new to D!
For example here:

http://www.slant.co/topics/25/viewpoints/11/~what-is-the-best-programming-language-to-learn-first~d

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.

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.