On Tue, Jun 07, 2016 at 02:31:43PM +0000, Steven Schveighoffer via Digitalmars-d wrote:
> On Tuesday, 7 June 2016 at 13:47:39 UTC, H. S. Teoh wrote:
> > .
> > 
> > I can't seem to find an issue I filed some years ago about @safe needing to be whitelist-based rather than blacklist-based. Did it get closed while I wasn't looking?
> 
> 
> This one?
> 
> http://forum.dlang.org/post/mailman.2912.1465288884.26339.digitalmars-d-bugs@puremagic.com
[...]

Oh yes, that's the one.


T

-- 
Making non-nullable pointers is just plugging one hole in a cheese grater. -- Walter Bright

On Tuesday, 7 June 2016 at 14:35:51 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 7 June 2016 at 14:16:03 UTC, Chris wrote:
>> It's not like 20 years + Apple or Google behind it. Given how slowly big languages like Java have progressed over the years, one can only admire the wealth of (sometimes innovative) features D has, implemented by a small number of core developers.
>
> The problem with that reasoning is that the standard libraries of languages like C++, Java and Python are less likely to contain undocumented bugs. Which is more important than features.
>
> The sole purpose of a standard library is to have something very stable to build your own libraries upon. A large number of features in a standard library is not really a selling point for production work.
>
> Having a large number of independent narrow high quality maintained 3rd party libraries is a selling point. The role of a good standard library is to enable writing narrow independent libraries that can be combined.
>
> This is an area where many languages go wrong. Basically, if there is no significant demand for a feature from library authors then it probably should not be added to a standard library.
>
> Arcane bloat becomes baggage down the line and can even keep the language itself from evolving. (breaking your own standard library is much worse than breaking 3rd party frameworks)

Features are important. Templates, for example, make writing code in general and libraries in particular much easier.

You sound as if a wealth of features and good libraries were mutually exclusive. They are not. The problems with Phobos are not due to D's features but to a specific implementation (slow algorithms) - like in any other language.

When writing software, it's important to have a wealth of features to choose from so you can use the one that best fits the task at hand. You realize that when you have to use a language with less features, then it's repeat yourself, repeat yourself ... It's always funny when other languages introduce a feature that D has had for years - after having insisted that the feature was unnecessary.

Java has lambdas now (since version 8, I think) and I read somewhere that it's not certain that Java programmers will adopt (i.e. use) them at all. D has the advantage that its users are not so complacent and actually demand and welcome new features and happily use them. They're not lulled into believing that this or that feature is useless. This is why D evolves somewhat faster which helps to attract users who look for something different, who are not happy with the status quo. At the same time this will forever keep the complacent and those with a herd mentality away and there is absolutely no way to convince them - and we shouldn't try to, because it's a waste of time.

On 6/06/2016 8:40 PM, Russel Winder via Digitalmars-d wrote:
>>
>> Building dmd with Microsoft C++ isn't an official build. Building it
>> with DMC++
>> is, works fine, and does not depend on Microsoft tools.
>
> But standard C++ should be compilable with any standards compliant C++
> compiler. So if it C++ and compiles with DMC++ then it should compile
> with MS C++.
>
>

DMD is not written in C++ any more...

On Tuesday, 7 June 2016 at 15:15:03 UTC, Chris wrote:
> Features are important. Templates, for example, make writing code in general and libraries in particular much easier.

Both C++ and D have simple macro-like duck-typing templates. I don't find that approach particularly impressive. Yes, I use it a lot, but templated programming in this fashion also easily get convoluted and having multiple levels of abstraction can reduce transparency and make debugging more difficult.

> You sound as if a wealth of features and good libraries were mutually exclusive. They are not. The problems with Phobos are not due to D's features but to a specific implementation (slow algorithms) - like in any other language.

Well, D has some language features that probably should be library features (like slices) and some library features that should have been language features (like memory management).

However I was not complaining about "problems", but pointing out that system library APIs get out-of-date over time irrespective of the quality of the implementation. The more detached library features are from the core language the more likely they are to get out-dated.


> When writing software, it's important to have a wealth of features to choose from so you can use the one that best fits the task at hand.

Not really.

C++/D would have been better languages if they just cut all the pointless special casing and boiled the core semantics down to templates and functors.

C++ has at least boiled lambdas down to functors and are better for it.


> You realize that when you have to use a language with less features, then it's repeat yourself, repeat yourself ...

Not true in my experience. Which languages have you used? Orthogonal minimalistic languages can be very expressive. Actually, it is often the opposite, because without that minimalism you have to special case a lot of stuff when similar entities cannot be treated the same.

However in some minimalistic languages everything looks the same (like Lisp) which can make it harder to read source code. Sometimes you want a DSL for readability. However I don't think C++ or D score high on readability. It is not their core strength.

I don't find C++ std or Phobos particularly readable. I can read it, but neither provide shining examples of legible code.


> Java has lambdas now (since version 8, I think) and I read somewhere that it's not certain that Java programmers will adopt (i.e. use) them at all.

So, Java was designed to be a simple language, just like the JVM is simple. Lambdas aren't anything special. Most languages have anonymous functions. Even the minimalistic OO ones.


> D has the advantage that its users are not so complacent and actually demand and welcome new features and happily use them. They're not lulled into believing that this or that feature is useless.

Uhm... Do you really think this reflects reality? You mean the D language designers and fanbois don't try to cut people down when they point out where D needs improvement? ORLY???


> This is why D evolves somewhat faster which helps to attract users who look for something different, who are not happy with the status quo.

But it doesn't evolve much, it adds features without fixing what is already there. Which makes it harder and harder to make any significant progress on the language semantics.

C++ actually do improve on the existing features, lambdas was improved in C++14 and further improved in C++17 (constexpr). And C++'s take on lambdas is better than D lambdas. Despite C++ not being able to push breaking changes, which D can (D's major advantage over C++).

If D improved on the existing feature set then it could stand a chance. Like, it could provide better integer semantics than C/C++, but chose not to. It could provide better floating point semantics than C/C++ (not hard to beat, as gcc/clang messes up rounding modes), but chose to stick with something even worse. The only advantage D has in the template department is the ability to select class-members using meta-programming. Everything else you need for practical meta-programming can be done just as well in C++.

If you compare current day D to C++ it only have two advantage points:

- static if

- a naive garbage collector

But D lambdas are worse, floats are worse, ints are worse, simd support is worse (gcc/clang) and documentation is worse.

Please understand that I am not saying that C++ is really great, but D is deliberately not trying to be better, but for some reason choose to just be "somewhat different". That cannot work out to D's advantage as both languages have too many pitfalls to be suitable for newbies (in comparison to high level languages).

As such, Go is better than C++ in some domains by being dependent on GC and stripping down features to the essentials. Go is very unexciting, but they stuck to improving on some core competitive features over time. Which paid off in that niche as other languages cannot get those features within 3 years.

D needs to improve too. Not by growing the feature set, but by improving on what is already there.

On Tuesday, 7 June 2016 at 16:12:42 UTC, Ola Fosheim Grøstad wrote:
>
> If you compare current day D to C++ it only have two advantage points:
>
> - static if
>
> - a naive garbage collector
>
> But D lambdas are worse, floats are worse, ints are worse, simd support is worse (gcc/clang) and documentation is worse.
>

How about no headers or macros? Dub? Chaining range operations with ufcs?

On Tuesday, 7 June 2016 at 09:29:35 UTC, Russel Winder wrote:
> Their "strap line" is effectively that GC is not a problem for systems programming. And they are right. Which is why D has no problem with being a GC language.

Incorrect. Pike, on a panel with D's Andrei, even said that when they labeled Go a systems programming language it was kind of taken in a way they didn't mean. It's more of a server programming language. I don't think Pike would agree that Go would be the best choice for an OS. I'm sure you can create one, and I'm sure he'd agree with this, but I doubt he'd personally reach for it.

> Go has blossomed due to the Web niche but it is used elsewhere.

No. It's blossomed because of its tooling and standard library, which gets traction from the funds of Google.

On Tuesday, 7 June 2016 at 08:05:58 UTC, Russel Winder wrote:
> So instead of debating this endlessly, I think this is about the tenth time this has come up in the last two years, why doesn't a group of people who know about GC algorithms get together and write a new one?

In addition to the other answers, it's worth noting that most every good modern GC algorithm I can think of requires barriers.  Walter has repeatedly and emphatically declared that D will not have barriers, so we're kind of SoL on on that front.  Java and Go don't have that problem.

-Wyatt

On Tuesday, 7 June 2016 at 17:19:16 UTC, Wyatt wrote:
> On Tuesday, 7 June 2016 at 08:05:58 UTC, Russel Winder wrote:
>> So instead of debating this endlessly, I think this is about the tenth time this has come up in the last two years, why doesn't a group of people who know about GC algorithms get together and write a new one?
>
> In addition to the other answers, it's worth noting that most every good modern GC algorithm I can think of requires barriers.  Walter has repeatedly and emphatically declared that D will not have barriers, so we're kind of SoL on on that front.  Java and Go don't have that problem.
>
> -Wyatt

hear, hear!

On Tuesday, 7 June 2016 at 17:04:19 UTC, jmh530 wrote:
> How about no headers or macros?

Textual include files are annoying and C++ needs more symbolic modules, but not having the ability to use namespaces is annoying too and D's take on name resolution can break code.

No need to use macros in C++10, but it comes in handy in debugging and unit testing, actually. So, I am bit torn on that.

So those are just break-even issues, neither better or worse. Plusses and minuses in both camps.

> Dub?

Not a language feature, I avoid to use such features if I can. I really hate being forced to use it with node.js. I prefer downloading directly from github and put specific versions of libraries in my own projects. I don't use a package manager with Python either. Just download libraries, remove unneeded stuff and dump it into my project directory.

> Chaining range operations with ufcs?

I don't like how UFCS makes code less maintainable, and was happy to learn that C++17 most likely won't add it.

I only use generators for testing, not for production. In general I end up using explicit easy to read inner-loops as they are easier for step-debugging and easier to optimize. The time it takes to write the code is less costly than the time it takes to understand what is going on in a debugger.

I use generators in high level REPL languages like Python though.

On 07.06.2016 10:54, Walter Bright wrote:
> On 6/7/2016 1:22 AM, Ola Fosheim Grøstad wrote:
>> So this is solved in modern C++.
>
> This is where we diverge. A language isn't safe unless it can
> mechanically guarantee that unsafe constructs are not used. Saying
> "don't write unsafe code" in C++ does not make it safe language.
>
> How would you know some random 10,000 line piece of C++ code is using
> std::vector instead of [ ]? How do you know that some random PR pulled
> into your project does not have [ ] in it? It's faith-based programming.
> Faith based programming does not scale and is not the point of @safe.

How do you know that some random @safe PR pulled into your project does not corrupt memory?