On 24/09/14 06:31, Walter Bright wrote:

> But it is a bit unreasonable to expect
> large project maintainers to rebuild and check for bugs every day. It's
> why we have a beta test program.

The solution is to make it automatic.

-- 
/Jacob Carlborg

On Wednesday, 24 September 2014 at 04:46:01 UTC, Sean Kelly wrote:
> Yes, the inference is very nice.  And I do see the use for each attribute.  It's just... when I look at a function and there's a line of attributes before the function declaration that have nothing to do with what the function actually does but rather with how it's implemented, it's just syntactic noise.  It's information for the compiler, not me as a user.  I hope we'll eventually get to the point where everything is inferred and the attributes disappear entirely.

What is the problem with complete automatic inference?
Wouldn't it be possible to deduce the flags in the bottom up direction of a function call hierarchy?
I guess it is possible for the compiler to see the right choice of flags for a function, which doesn't call other functions. E.g. make it @safe if possible, @nogc if possible and so on.
Then it should process function after function until all functions are done.

Thomas

On 24/09/14 05:59, Walter Bright wrote:

> No, that's not the problem. The problem is what to do when the "larger
> project" fails.
>
> Currently, it is the submitter's job to adjust the test suite, fix
> phobos code, whatever is necessary to get the suite running again.
> Sometimes, in the more convoluted Phobos code, this can be a real
> challenge.
>
> Now replace that with somewhere in a large project, which our poor
> submitter knows absolutely nothing about, it fails. You're asking him to
> go in, understand this large project, determine if it's a problem with
> his submission or a problem with the large project, and fix it.

If it worked before and now it doesn't, then it sounds like a regression to me.

> At some level, then WE become the maintainers of that large project.
>
> This is completely unworkable.

The author of the library could at least get a notification.

-- 
/Jacob Carlborg

On 20 September 2014 22:39, Tofu Ninja via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> There was a recent video[1] by Jonathan Blow about what he would want in a programming language designed specifically for game development. Go, Rust, and D were mentioned and his reason for not wanting to use D is is that it is "too much like C++" although he does not really go into it much and it was a very small part of the video it still brings up some questions.
>
> What I am curious is what are the worst parts of D? What sort of things would be done differently if we could start over or if we were designing a D3? I am not asking to try and bash D but because it is helpful to know what's bad as well as good.
>
> I will start off...
> GC by default is a big sore point that everyone brings up
> "is" expressions are pretty wonky
> Libraries could definitely be split up better
>
> What do you think are the worst parts of D?
>
> [1] https://www.youtube.com/watch?v=TH9VCN6UkyQ

Personally, after years of use, my focus on things that really annoy
me has shifted away from problems with the language, and firmly
towards basic practicality and productivity concerns.
I'm for addressing things that bother the hell out of me every single
day. I should by all reason be more productive in D, but after 6 years
of experience, I find I definitely remain less productive, thanks
mostly to tooling and infrastructure.

1. Constant rejection of improvements because "OMG breaking change!". Meanwhile, D has been breaking my code on practically every release for years. I don't get this, reject changes that are deliberately breaking changes which would make significant improvements, but allow breaking changes anyway because they are bug fixes? If the release breaks code, then accept that fact and make some real proper breaking changes that make D substantially better! It is my opinion that D adopters don't adopt D because it's perfect just how it is and they don't want it to improve with time, they adopt D *because they want it to improve with time*! That implies an acceptance (even a welcoming) of breaking changes.

2. Tooling is still insufficient. I use Visual Studio, and while VisualD is good, it's not great. Like almost all tooling projects, there is only one contributor, and I think this trend presents huge friction to adoption. Tooling is always factored outside of the D community and their perceived realm of responsibility. I'd like to see tooling taken into the core community and issues/bugs treated just as seriously as issues in the compiler/language itself.

3. Debugging is barely ever considered important. I'd love to see a concerted focus on making the debug experience excellent. Iain had a go at GDB, I understand there is great improvement there. Sadly, we recently lost the developer of Mago (a Windows debugger). There's lots of work we could do here, and I think it's of gigantic impact.

4. 'ref' drives me absolutely insane. It seems so trivial, but 6 years later, I still can't pass an rvalue->ref (been discussed endlessly), create a ref local, and the separation from the type system makes it a nightmare in generic code. This was a nuisance for me on day-1, and has been grinding me down endlessly for years. It has now far eclipsed my grudges with the GC/RC, or literally anything else about the language on account of frequency of occurrence; almost daily.

On 9/20/2014 3:53 PM, Brian Schott wrote:
> On Saturday, 20 September 2014 at 12:39:23 UTC, Tofu Ninja wrote:
>> What do you think are the worst parts of D?
>
> This compiles.
>
> https://github.com/Hackerpilot/Idiotmatic-D/blob/master/idiotmatic.d

https://github.com/D-Programming-Language/dmd/pull/4021

produces:

test.d(7): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax
test.d(8): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax
test.d(11): Warning: instead of C-style 'T id[exp]' syntax, use D-style 'T[exp] id' syntax
test.d(15): Warning: instead of C-style 'T id[type]' syntax, use D-style 'T[type]' id syntax
test.d(57): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax
test.d(94): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax
test.d(103): Warning: instead of C-style 'T id[]' syntax, use D-style 'T[]' id syntax

I.e. resolves 7 of them. :-)

On Wednesday, 24 September 2014 at 06:29:20 UTC, Walter Bright wrote:
> https://github.com/D-Programming-Language/dmd/pull/4021

I'm pleasantly surprised that the decision has been made to fix that. I thought we'd be stuck with them forever.

On 9/23/2014 11:20 PM, Jacob Carlborg wrote:
> On 24/09/14 07:37, Walter Bright wrote:
>> So help out!
> You always say we should help out instead of complaining.

That's right. Complaining does nothing.


> But where are all the users that want C++ support. Let them implement it instead and lets us focus on
> actual D users we have now.

I was there at the C++ revolution (and it was a revolution) almost at the beginning. And in fact, a reasonable case could be made that I caused the success of C++ by providing an inexpensive C++ compiler on the most popular (by far) platform at the right moment.

What sold C++ was you could "ease" on into it because it would compile your existing C code.

Later on, other C++ compilers came out. I'd talk to my sales staff at Zortech, asking them how they sold Zortech C++. What was the line that sold the customer. They told me "Zortech C++ is the only C++ compiler that can generate 16 bit Windows code. End of story. Sold!"

I.e. none of the features of ZTC++ mattered, except one killer feature that nobody else had, and that nobody else even had a story for.

Now, consider interfacing with existing C++ code. Which top 10 Tiobe languages can?

C: no
Java: no
Objective C: sort of http://philjordan.eu/article/strategies-for-using-c++-in-objective-c-projects
C++: yes
C#: no
Basic: no
PHP: no
Python: no
Javascript: no
Transact-SQL: no

and:

Go: no
Rust: no

The ones marked "no" have no plan, no story, no nothing.

This means if we have some level of C++ interop, we have a killer feature. If users have a "must have" C++ library, they can hook up to it. Can they use other languages? Nope. They have to wrap it with a C interface, or give up. Wrapping with a C interface tends to fall apart when any C++ templates are involved.

C++ libraries are currently a language "lock in" to C++. There are no options.

I've often heard from people that they'd like to try D, but it's pointless because they are not going to rewrite their C++ libraries.

Case in point: last fall Adam Wilson started on Aurora, a C++ Cinder clone. I had thought he could simply wrap to the C++ library. No way. It was just unworkable, and Cinder was too big to rewrite. Aurora was abandoned. If we could have interfaced to it, things would have been much different.

This story is not unusual.


That said, C++ interop is never going to be easy for users. We're just trying to make it possible for a savvy and determined user. And he'll have to be flexible on both the C++ side and the D side.

On 9/23/2014 11:24 PM, Jacob Carlborg wrote:
> On 24/09/14 06:31, Walter Bright wrote:
>
>> But it is a bit unreasonable to expect
>> large project maintainers to rebuild and check for bugs every day. It's
>> why we have a beta test program.
>
> The solution is to make it automatic.


There's no such thing as automatic testing of someone's moving target large project with another moving compiler target.

Heck, the dmd release package build scripts break every single release cycle.

On 9/23/2014 11:27 PM, Jacob Carlborg wrote:
> If it worked before and now it doesn't, then it sounds like a regression to me.

It could be an "accepts invalid" bug was fixed. It could be that we wanted to make a breaking change. It could be that it never actually worked, it just silently failed.

I can say from experience that when you're presented with an unfamiliar tangle of template code (why do people write that stuff :-) ) it ain't at all easy discerning what kind of issue it actually is.

On Wed, 24 Sep 2014 06:07:54 +0000
Cliff via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Why does anyone have to *wait* for anything?
'cause compiler and libs are complex beasts. there are people that have the necessary knowledge and they can write things faster (and better).

i'm sure that if Walter or Andrei made official claim "we want CDGC in DMD as official GC", that people will start some serious hacking.

there is alot more motivation to hack on something if people know that their work is much wanted in mainline DMD. CDGC is not worse that current GC for windows and MUCH better for *nix. it's a clear and instant win. c++ interop is... well, questionable.

note that "GC is top priority" is not the same as "poring CDGC is top priority". the first is "ok, let's think about it" and the second is "ok, we know what to do".