On Sunday, 3 July 2016 at 07:21:15 UTC, Charles Hixson wrote:
> portable. And I really like having garbage collection, and especially the syntax that it enables.  I was just considering a hash table (associative array) in C++, and realized that I had to either allocate on the heap, or I couldn't easily do an increment of a struct variable.  (Well, I'm thinking about QHash, because walking the files of a directory path in standard C++ is unpleasant, and Qt makes both that and unicode tests [the ones I need to do] pretty simple.)  But if I allocate structs on the heap I have to make sure that everything gets released when I'm through, so I need to use an enhanced pointer construct, so....  It's a lot simpler in D.
>
> I do wish that phobos included a D wrapper around SQLite, something object oriented.  I'd also like to be able to depend on class finalizers being called.  Sometimes I wrap a class in a struct just so I can depend on the finalizer.

[...]

> Most of my needs are for run time flexibility rather than for more compile time flexibility.  E.g., I'd like to be able to declare a statically sized array from a parameter.  I do appreciate D's speed, but complex templates aren't something I ever use.   (Truth is, I was pretty well satisfied with D1, though perhaps I'm forgetting some limitations, but even then I'm pretty much sure that I felt the main limitation was a lack of well interfaced libraries.)
>
> Too many of D's libraries seem to try to re-invent the wheel. When a library is working well and has been debugged, the best think if to create a wrapper around it.  The wrapper *does* need to adapt the library to the syntax of the language, but that's not a huge problem.  A major part of Python's success is "batteries included".

Included after 20 years of massive adoption. Something that would never have happened if it had a more solid competitor than Perl... Anyway, writing a library for a dynamic scripting language with no performance requirements is a different challenge. Python2 has major issues with its "batteries included" approach, just look at the fragmentation in Python's HTTP support libraries.

Java, C# and C++ have massive libraries as a result of massive adoption over a long period of time and massive backing.

If you are looking for GC, more runtime flexibility and libraries then it sounds like something like the recently released C# Core (Linux, OS-X, Windows) is going to be the best fit.

https://blogs.msdn.microsoft.com/dotnet/2016/06/27/announcing-net-core-1-0/

There are currently many smaller languages that are very interesting and increasingly competitive:

golang.org
rust.org
loci-lang.org
ponylang.org
whiley.org

So D better focusing at doing better at what it is already doing well (compile time) rather than expanding even more.  And even then a language like Whiley is more advanced.  Whiley has a floating type system with static typing where you can write functions that return either strings or integers and a builtin prover.  But Whiley is currently in phase (1)... so no adoption.

I agree that a production ready D1 in 2010 would have cut into what is now the market of Go. But that train has passed.

On Sunday, 3 July 2016 at 07:48:39 UTC, ketmar wrote:
> On Sunday, 3 July 2016 at 07:04:58 UTC, Ola Fosheim Grøstad wrote:
>> 3. Improve on it for 3-10 years without changing the functionality.
>
> if i want to use "stable language", i know where to download C89 compiler.

That's ok for spare time use, but when developer time and maintenance matters then stable is more important than features.

Without a stable branch any development platform becomes much less attractive.

On 7/3/2016 12:21 AM, Charles Hixson via Digitalmars-d wrote:
> I do wish that phobos included a D wrapper around SQLite,

There was one recently announced.


> I'd also like to be able to depend on class finalizers being called.
> Sometimes I wrap a class in a struct just so I can depend on the finalizer.

That's the way to do it.


> The last time I checked DDoc stopped working after encountering an extern "C"
> block in a file.

I'm not aware of this. Is there a bug report filed?


> DDoc could use considerable work in formatting. I'd like to be able to globally control the font attributes
> of classes, structs, aliases, enums.

DDoc relies on having a user-supplied xxx.ddoc file to provide the formatting, css, etc.


> I'd like to be able to document private
> routines or not depending on a (compiler) switch.

I'm not sure what the point of that would be. Private functions shouldn't be called by anything outside of the file, and you already have the file open in the editor when working on it. But you can always submit an enhancement request for it on bugzilla.


> Most of my needs are for run time flexibility rather than for more compile time
> flexibility.  E.g., I'd like to be able to declare a statically sized array from
> a parameter.

You can do it more or less with alloca(). I know C99 has this feature, and some people swear by it, but I just don't think it pulls its weight.


> I feel sort of guilty for "complaining" this way when I've been devoting all my
> efforts to my own projects, but you did, essentially, invite comments.

If something good can come from it, it's good.

On Sunday, 3 July 2016 at 04:37:02 UTC, D is crap wrote:
> Sorry, I've spend the last month trying my best to get simple shit done. At every turn there is some problem that has to be dealt with that is unrelated to my actual work.  Be it the IDE, debugging, the library, or user shared code, it is just crap. D cannot be used successfully for semi-large projects without significant man hours invested in getting everything to work.


couldn't agree more all the points in that post!
reactions are as expected - dumb.


+100

> reactions are as expected - dumb.
nice signature.

On Sunday, 3 July 2016 at 04:37:02 UTC, D is crap wrote:
>
> I'm sorry but it seems too much focus on enhancements while there are too many bugs and lack of tools to actually do anything useful.
>
> I'm sorry if this hurts some of you guys feelings but it is fact that D sucks as a whole. A modern programming language should be modern, and D is not one of those languages. It is built as from cobbling together disparate parts that don't work together. The more it is used and added on to the worse it gets.
>

That was an entertaining rant, dare I say well written and with a few actionnable points maybe.

I fear that your perception of problems are worse that the problems themselves in most cases though, perhaps to make a stronger point. For example choosing the 1970s compilation model with object files was probably the only possible decision.

Windows support isn't that bad -except- for the occasional sc.ini tweak when you don't use VS and DMD installers in the right order, and VisualD works well. I don't really see what is missing when compared to the C++ experience.

You are right about documentation but there are efforts in this very direction
The fact is that rants about D complain about more and more elaborated and "end-userish" issues. People now expects

D is 10 years old, perhaps more, but refining the end-user experience is much more recent than that. It all is coming together recently so your expectations went up at the same time.

I feel the heart of the argument is that D is something that you have to get into to use it, it's not really something that you can almost avoid learning and just use (like say, you could write bad python scripts pretty quickly). In other words D has high interest rates but there is an initial entry cost.

On Sunday, 3 July 2016 at 09:42:35 UTC, Guillaume Piolat wrote:
> People now expects

an experience without surprise.

On Sunday, 3 July 2016 at 09:42:35 UTC, Guillaume Piolat wrote:
> The fact is that rants about D complain about more and more elaborated and "end-userish" issues.


For example, if we look back to the "Angry Emo D Rant" from 2010.

http://dlang.group.iteye.com/group/topic/20404

Of the 17 bullet-point complaints the author made, 12 have been addressed since.

On Sunday, 3 July 2016 at 04:37:02 UTC, D is crap wrote:
> I'm sorry many of you have spent your lives working on something that won't amount to much in the real world. It was a valiant effort. Maybe it will seed new languages that will actually work and have the tooling to be useful. D itself is not a practical tool for general real world software development.

What is "real world software development"? Of course it is exactly what I happen to do and it is done exactly the way I do it. Nobody uses scripting languages, nobody uses Python, all programming is web development, real development is done in an IDE, real development is done in a corporate setting as part of a team of at least 15 software engineers and involves automated testing and dependency checking and code reviews. Nobody uses garbage collection. Real developers don't use a compiler.

I have nothing useful to add to this discussion. It's Sunday morning and this lecture about how I'm not a real programmer annoyed me.

On Sunday, 3 July 2016 at 11:20:14 UTC, bachmeier wrote:
>
> What is "real world software development"? Of course it is exactly what I happen to do and it is done exactly the way I do it. Nobody uses scripting languages, nobody uses Python, all programming is web development, real development is done in an IDE, real development is done in a corporate setting as part of a team of at least 15 software engineers and involves automated testing and dependency checking and code reviews. Nobody uses garbage collection. Real developers don't use a compiler.
>
> I have nothing useful to add to this discussion. It's Sunday morning and this lecture about how I'm not a real programmer annoyed me.

Time to quote DHH in his book Rework:
http://e-venue.org/wp/ignore-the-real-world/