On Sat, 29 Nov 2014 00:41:45 -0800
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 11/28/2014 6:08 PM, H. S. Teoh via Digitalmars-d wrote:
> > Hmm. Did you install libncurses5-dev (or libncursesw5-dev)? If not, try
> > `apt-get install libncurses5-dev` (or libncursesw5-dev as appropriate).
> > Otherwise, try -lncurses5 or -lncursesw5, perhaps?
> 
> Yeah, that didn't work, either.
> 
> I wound up simply ripping out ncurses and hardcoding it for xterm.
ah, yes, i'm lazy, so i ripped off ^Z and one scrolling optimisation. it can be fixed easily, but i don't see any sense in it.

On Friday, 28 November 2014 at 23:33:54 UTC, Walter Bright wrote:
>
> I know there's been a lot of "break my code" advocacy lately, but this code was only 2 years old.

I've lost my faith in expecting to see the D core team grasp what the so called "break my code" folks aims to reach.

--
Paolo

Walter Bright:

> On 11/28/2014 3:50 PM, bearophile wrote:
>> I agree. D has to come back to the living. It looks like D is hibernating.
>
> I have no idea what you're talking about.

In the last several years the development of D/Phobos didn't keep a constant speed (and this is normal), I have seen sprints, slowdowns, etc.

In the latest months I'm seeing a reduction of activity both on the language side, on the fixing and merging of important Phobos patches, and even regarding the number of interesting discussions in the main D newsgroup.

Some of this "hibernation" could be caused by the latest "revolution" threads by Andrei. But probably there are also other causes.

Or perhaps I'm just mis-measuring the kind of D activity, and everything is going on as well as usual :-)

Bye,
bearophile

On Saturday, 29 November 2014 at 04:03:47 UTC, Walter Bright wrote:
>
> Actually, we've (myself and 3 others) been hard at work preparing a scope ref proposal. It isn't quite ready to present yet. I agree it is of major importance. It will also slightly break some code, but we have a plan for dealing with that to make it as painless as possible. I believe that scope ref is a big enough win to justify it.

That's a very good news.
---
Paolo

On Saturday, 29 November 2014 at 11:37:52 UTC, bearophile wrote:
> Some of this "hibernation" could be caused by the latest "revolution" threads by Andrei. But probably there are also other causes.
>
> Or perhaps I'm just mis-measuring the kind of D activity, and everything is going on as well as usual :-)

I got very happy when Walter announced "@nogc" and his intent to create a "better C" switch on the compiler.

I felt this was a nice change of direction, but I also feel that this direction has stagnated and taken a turn for the worse with the ref-counting focus… Phobos is too much of a scripting-language library to me, too much like Tango, and hacking in ref counting makes it even more so.

To me, a "better C" would have a minimal runtime, a tight minimalistic standard library and very simple builtin ownership semantics (uniqe_ptr). Then a set of supporting libraries that are hardware-optimized (with varying degree of portability).

However, I think those that are interested in D as a tight system level language have to spec out "better C" themselves as a formal language spec sketch. I'd be happy to contribute to that, maybe we could start a wiki-page. Since a "better C" would break existing code, it would allow a more "idealistic" language design discussion. I think that could cut down on the noise.

I think an experiment would be worth it.

Walter Bright:

> Changing names makes the situation worse by consuming scarce resources.

Changing names make the language/library better, and this can increase the retention rate of new D programmers.


> That's largely speculation. I doubt there's an objective case that "globMatch" is superior to "fnmatch". Not only that, "fnmatch" is a familiar and widely used name across diverse languages. Nobody else uses "globMatch".

Some examples of classes of situations/problems:
- In Phobos there are good functions like std.math.feqrel that people aren't using (I have again and again suggested its usage in D.learn) probably because of their bad names.
- In Phobos there are names like schwartzSort that while descriptive (if you know what a Schwartz transform is), are awfully hard/bad to type and remember (I suggested a "sortKey" or something equally simple, that is less descriptive, but this is not a big problem because schwartzSort is meant to be used quite frequently in D code).
- In Phobos there are also redundant names like std.random.randomShuffle, where in both Python and now C++ "shuffle" suffices.
- Regarding the name "familiarity" point you often raise, this has done not so good to D. We have names like "wchar", "dchar" that have no useful meaning, and you need memory to remember their sizes. We have exceptionally badly type names as "byte" and "ubyte" that are bug-prone, etc. Not all future D programmers have 20 years of C/C++ experience of programming. Sometimes a more "algorithmic" naming scheme for types as in Rust is better (it uses a number to denote the length in bytes of number types).


Good function names are useful because:
- It's simpler to find them when you don't know if Phobos contains something you need;
- Once they are found, a well chosen name allows the programmer to understand faster if that's the right function to pick;
- Once they are used in the code, a good name makes the code more easy to understand;
- Bad names can even cause bugs;
- Sometimes when you can't find a good name for a function is a code smell, it means your function is badly designed or should be split in two or more parts.

Good naming is essential in programming. Improving some D/Phobos names is very important. I understand the need for API stability, but this doesn't kill the importance of good naming. Adding @deprecated to Phobos for years is often acceptable.


> and the lack of a rich set of libraries because of bit rot.

This is not a valid argument. The lack of D libraries has various causes, probably the main one is the lack of D developers and the lack of their interest in keeping the code updated (perhaps because they have left D community?). If you take a look at the Julia language community, the libraries (http://pkg.julialang.org/ ) are being refactored and some names change, but there are lot of people that work furiously improving those libs, so they don't rot, they blossom. Julia is a young language but it already has most numerical libraries for all kinds of scientific work (also because writing average-quality Julia library code requires little time).

Bye,
bearophile

Ola Fosheim Grøstad:

> Phobos is too much of a scripting-language library to me, too much like Tango, and hacking in ref counting makes it even more so.

Those "scripting" needs are real, and rather common. Those high level things are worth having in Phobos. On the other hand it's also reasonable to desire something more fit for a lower level kind of coding. One solution is to split Phobos in two groups of functions, for the two usages (and to forbid the lower level functions to call the high level ones), and ship the compiler with both parts. There is already "Phobos core", but I don't know if its meaning is the same as you desire (probably not).


> To me, a "better C" would have a minimal runtime, a tight minimalistic standard library and very simple builtin ownership semantics (uniqe_ptr). Then a set of supporting libraries that are hardware-optimized (with varying degree of portability).

Clearly D is not a "better C", it's a "better C++/Java". You can use D as a "better C" but this needs some adaptation, both for you and the libraries.


> However, I think those that are interested in D as a tight system level language have to spec out "better C" themselves as a formal language spec sketch. I'd be happy to contribute to that, maybe we could start a wiki-page. Since a "better C" would break existing code, it would allow a more "idealistic" language design discussion. I think that could cut down on the noise.
>
> I think an experiment would be worth it.

As usual in open source a good way to do things is to start them yourself and look at how many persons are interested. But from what I'm seeing Rust is putting itself at a level lower than D, with all its care for its "no runtime", it even has annotations and standard library sections for this kind of usage.

Bye,
bearophile

On Saturday, 29 November 2014 at 00:20:38 UTC, Daniel Murphy wrote:
> I think @disabled with a custom message would be perfect for this.  static assert only works for templates.

We just need someone to implement this.
https://issues.dlang.org/show_bug.cgi?id=8728

On Saturday, 29 November 2014 at 12:08:08 UTC, bearophile wrote:
> Those "scripting" needs are real, and rather common. Those high level things are worth having in Phobos. On the other hand it's also reasonable to desire something more fit for a lower level kind of coding. One solution is to split Phobos in two groups of functions, for the two usages (and to forbid the lower level functions to call the high level ones), and ship the compiler

"scripting" needs depend on the application area, the core standard library should only contain the most commonly needed functionality that will work for all applications.

With a big standard library you get this effect:

big monolithic standard library -> other libraries build on it -> many libraries are unsuitable for more restricted applications

big monolithic standard library -> hard to keep bug free, performant and makes language changes more difficult

What you want is this:

tight standard library -> other libraries build on it if they can-> more libraries are suitable for all applications

tight standard library -> high degree of stability -> less breakage of other libraries

tight standard library -> better results for library-aware optimizations

Then you can have a second optional profile for more unstable scripty libraries, a standardized "extras".


> with both parts. There is already "Phobos core", but I don't know if its meaning is the same as you desire (probably not).

No, I think a lot of what is in "core" is really things that should either be in the language or as compiler intrinsics that the optimizer can deal with.


> Clearly D is not a "better C", it's a "better C++/Java". You can use D as a "better C" but this needs some adaptation, both for you and the libraries.

Yes, but if you can look at D1 as being between C/C++ with GC. I think that is a comfortable spot, if you remove the stuff that the implies a mandatory GC.

I think D2 is better off by focusing on stability, evolving in radical changes is difficult. So the more rational approach is to look at the possibility for a D3 on paper and spec a core language that is GC-free, but which can have a more "scripty" GCish profile built on top of it.

When you have that, it become easier to improve D2 too, because you have something (hopefully) coherent to compare D2 against.

If you have something (on paper) that as a whole is a lot more consistent than D2 then maybe it will be more convincing than arguing tiny feature improvements in isolation. Because those tiny improvements might not seem to be worth it alone. But a new holistic design that captures a lot of the current practice in a cleaner way is going to be much harder to pass on.

> As usual in open source a good way to do things is to start them yourself and look at how many persons are interested.

Sure, I have for many years sketched out various on-paper-designs for languages, I am sure many others do to. The problem is finding common ground since people have different programming styles, experiences and different level of theoretical understanding. By starting with D1/D2 as a common ground it might be possible to create a paper spec for a tiny-D3 that could both support a reduced system language profile and later support an extended "scripty" profile.


> But from what I'm seeing Rust is putting itself at a level lower than D, with all its care for its "no runtime", it even has annotations and standard library sections for this kind of usage.

The problem (and advantage) with opinionated languages like Rust and Go is that they restrict their application area. I also feel that the GC'ed D is constraining, but less so than Rust and Go. Ada is also a well rounded language, but it is a bit verbose for smaller projects. So I think there is an open spot for a streamlined D'ish language between C/C++ with some of the qualities of Ada/Go/Rust/etc.

I don't think D is easy to streamline by evolution alone. If you want to arrive at something coherent you need to create abstractions over existing idioms in D programming (interpret current practice through theory) and not create abstractions over the language and libraries (the actual code).

"Martin Nowak"  wrote in message news:znsbjqmgwegyrtvxqmhd@forum.dlang.org...

> We just need someone to implement this.
> https://issues.dlang.org/show_bug.cgi?id=8728

Exactly.  I've had a look at it a couple of times but never made it past the parser.