On 12/28/2017 2:54 AM, Russel Winder wrote:
> Clearly you are missing the point I
> am making, which clearly must be my fault for bad expression.

Whether it's your fault or mine, I apparently have no idea what you mean by the phrase "psychology based design".


> Also clear it is not worth progressing this debate.

Not necessarily true. I have always been interested in human factors design, going back to my experience designing airplane parts and talking with the cockpit design engineers.

A fun example is the warning horns in the cockpit. One was added, I think for stall warning. It turned out to be remarkably effective. So they added horns for other emergencies, each with a distinct sound so the pilot could distinguish them.

But it turned out, in a high stress situation, the pilot would get confused associating the sound with what just went wrong, and would take the wrong corrective action. Boeing then had the brilliant (and obvious in hindsight, as these things so often are) of replacing the horn sounds with words. So the stall warning horn becomes "stall, stall" (I forgot the exact words for it). Problem solved!

With programming language design, I'm pretty interested in why programmers make the mistakes they do, and if the propensity for making those mistakes can be blunted by altering the design of the language. There's a lot of that in D. (I enjoy reading articles about what static checkers do, and articles that collect statistics on types of bugs.)

On Thursday, 28 December 2017 at 08:53:25 UTC, Russel Winder wrote:
> On Thu, 2017-12-28 at 03:34 +0000, codephantom via Digitalmars-d wrote:
>> 
> […]
>> I tried Go. I didn't like it. Syntax changes were not I looked at Rust, but never tried it, as I found the syntax to pretty awful - and it reminded my too much of C++.
>
> The syntax is fine, and it is so unlike C++, it is easy to get into. I am using Rust as my primary language for all GStreamer stuff now.
>

I disagree.

Here is some Rust code...

use std::io::stdin;
fn someFunction(vec: Vec<int>) {}
let  mut vec = Vec::new();
let mut age: i32 = 1;
etc...
etc.....

The syntax is just weird, in my opinion.. it's like some martian language...

Clearly, applied psychology was not front of mind when designing that syntax ;-)
(and I believe the syntax was pretty controverial anyway, and underwent constant changes...but they still managed to get it wrong .. in my opinion).

>> But gee.. I can do things in D so easily and quickly compare to C, and I don't feel like I giving up much for that convenience. Compare that to running dotnet ... grrrr...you sit there just waiting for the program to load.
>
> C# and F# also have a lot going for them, I suspect you used it is the wrong context and so got a bad feel. The same is true for Java. Kotlin, Groovy, I guess which are great in a JVM-centred context.

No. I didn't mean C# per se. What I mean is 'dotnet' (the attempt my MSFT to port C# to other platforms.) I have to sit and wait several seconds sometimes before the dotnet runtime loads itself and starts doing the job I asked it to do. Once it runs it's not 'too' bad, but still noticably slower than a native compiled language. I do like C#, so I'm not against that, but making people wait for things to load like this is just pathetic..it needs to get better... or in the dumpster it goes.

On Thursday, 28 December 2017 at 10:57:55 UTC, Russel Winder wrote:
>
> Not sure which country this is an observation on, but again all countries are different so a global opinion is not possible. The problem in the UK is the shift from wholly government funded tertiary education, to partially government, partially personal funded tertiary education. The cynical would see this as a way of stopping poor people getting an education.
>

It's odd, that humans are still willing to restrict their potential through the limitations of 'money' - money being a creation of humans, not a restriction nature imposed on us. I just don't get it.

The D project is a nice example of people just working together to achieve something that all can benefit from.

On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder wrote:
>
> However, in the end, the GStreamer core people know C, C++ a bit, D not at all. I suspect even if the choice had been Rust or D, Rust would have been chosen because it has no GC and D is a GC language.

That is a little misleading. It was always the intention of Rust designers to allow userd to tie into a garbage collector - like spidermonkey.

It was never designed to be a language that can't make use of GC.

D has gc by default instead. But it's flexible enough to use RAII, and you can customise GC a lot....

So Gstreamer people could have easily worked with D, and I don't believe D's GC implementation would have been a show stopper for them.

On Thursday, 28 December 2017 at 10:54:08 UTC, Russel Winder wrote:
>
> If you want to believe that fine. Clearly you are missing the point I am making, which clearly must be my fault for bad expression. Also clear it is not worth progressing this debate.

You are asking Walter to 'quantify' something that simply does not need to be quantified. This is the problem with the scientific method.

Not everything needs to be, or can be, or should be, quantified.

Some things just make sense, and it is obvious, and it can be left at that.

Like not having to annotate functions with func, or fn.

Not having to use := when you mean =

etc..
etc....

On Friday, 29 December 2017 at 00:26:04 UTC, codephantom wrote:
> On Thursday, 28 December 2017 at 08:53:25 UTC, Russel Winder wrote:
>>[...]
>
> I disagree.
>
> [...]

syntax is not weird at all. it is ML-ish.

On Friday, 29 December 2017 at 07:54:53 UTC, Mengu wrote:
> On Friday, 29 December 2017 at 00:26:04 UTC, codephantom wrote:
>> On Thursday, 28 December 2017 at 08:53:25 UTC, Russel Winder wrote:
>>>[...]
>>
>> I disagree.
>>
>> [...]
>
> syntax is not weird at all. it is ML-ish.

oh. I didn't know..

in any case, ML syntax is even weirder ;-)

Since a large portion of programmers ( I assume) are familiar more or less with the syntax of C,C++,Java,C#, I cannot understand why Rust chose to go down a completely different path with their syntax.

Familiar syntax is really important, especially as I swap between those langauges that I just mentioned..alot.

Rust is out, for me, simply because I don't want to be confused by their weird syntax everytime I go from one language to the next. With D, I can switch constantly from it to C, without incurring any syntax induced psychological trauma.

On Thursday, 28 December 2017 at 16:43:41 UTC, John Gabriele wrote:
> On Thursday, 28 December 2017 at 15:57:18 UTC, Paulo Pinto wrote:
>> On Thursday, 28 December 2017 at 11:27:29 UTC, Russel Winder wrote:
>>> On Wed, 2017-12-27 at 18:41 +0000, Laeeth Isharc via Digitalmars-d wrote:
>>>> 
>>> […]
>>> However the GStreamer folk are backing Rust (for memory safety issues noted earlier) so even though D has a GStreamer binding (thanks to Mike and GtkD) I more or less have to use Rust because it is the official binding. Comparing and contrasting D and Rust is interesting for me. Both have many pluses and many minuses. However, in the end, the GStreamer core people know C, C++ a bit, D not at all. I suspect even if the choice had been Rust or D, Rust would have been chosen because it has no GC and D is a GC language.
>>
>> Not only GStreamer, Rust is on its way to become an offical GNOME language, and who knows, eventually take over Vala's role.
>
> I haven't followed Gnome+Rust news. What suggests Rust may be on its way to become an official Gnome language?
>


GNOME and Rust devs are collaborating on how to easily integrate Rust with the Gtk+ object model.

Meetings were held at GUADEC, and a few projects, like GStreamer are now only using Rust for new code being written. It remains open what they will do with existing plugins.

The blog reports about those meetings are quite easy to find.

For example,

https://2017.guadec.org/talks-and-events/index.html#abstract-5-replacing_c_library_code_with_rust_what_i_learned

https://internals.rust-lang.org/t/rust-and-gnome-meeting-notes/4339

On Sunday, 24 December 2017 at 16:51:45 UTC, Patrick Schluter wrote:
> That's the biggest problem with C++, they pile on relentlessly half baked feature after half baked feature in a big dump that no one with a life can ever grasp.

I think D has more first class language features (and thus special casing) than C++.  For instance, C++ lambdas are just sugar over objects and most of the new stuff is primarily library features with some minor language tweaks to back it. So I don't think the core C++ language itself has changed dramatically.

Like, constexpr is mostly about allowing things that were forbidden, but it is opening new ways to structure code, which in turn "deprecates" some old clumsy idioms… Except those old clumsy idioms linger… both in online tutorials, in code bases and of course in the mentality of the programmers…

Since those "deprecated" idioms are built by combining features it cannot easily be detected and transformed into "modern" idioms by a tool either. Whereas a high level dedicated language feature could more easily be "deprecated" and dealt with in a language upgrade.

Which is one downside of using library-based constructs over language constructs.

So I am a bit torn on library vs language features.  From an aesthetics point of view having a small and expressive language seems like the better choice, but one can make good arguments for a low level oriented DSL as well.

With a well designed DSL the compiler author might more easily reason about the programmers intent and perhaps make better optimization choices… thus allowing the programmer to write more readable performant code…

I think the DSL approach makes more sense as computer architecture get less simplistic.

Although currently CPU vendors target C-like code, that might change in the future as less code is written in C-like languages…

On Saturday, 23 December 2017 at 09:10:25 UTC, Walter Bright wrote:
> On 12/22/2017 7:23 AM, Russel Winder wrote:
>> I think we are now in a world where Rust is the zero cost abstraction
>> language to replace C and C++, except for those who are determined to
>> stay with C++ and evolve it.
>
> Maybe it is. But that is not because D isn't up to the task. I've converted a large program from C to D (Digital Mars C++'s front end) with -betterC and it really is a zero cost abstraction. The memory safety benefits are there (DIP 1000), RAII is there, nested functions, array bounds checking, template metaprogramming, CTFE, etc.
>
> D as betterC really is a game changer, for anyone who cares to give it a try.

I think D's great strength compared to Rust is that it is much easier to code in D. How easy is it write a simple linked list in Rust - without using library features? Rust makes even simple tasks hard to write.

D as a language combines best features of C, C++ and Java which is great in my view. And the better C option makes it really viable for creating shared libraries that can be easily used in other projects.

Trying to replace C is really not the right goal for D I think. In my experience, C and C++ have already been replaced by Java, C# or Go in application development except where the code is legacy and is just being kept "alive". And nothing beats C for systems developers who want a high level assembler rather than abstractions and safety features.

In my view, D should be D - the main issue with D is not the language, but the tooling. It needs to "just work" on the major platforms and needs good IDE support.

Regards
Dibyendu