On Friday, 30 December 2016 at 09:53:25 UTC, keito940 wrote:
> ...If you improve the standard library, everything OK? If...
> Next Version Request.
> Add To The F Sharp Like Pipeline Operator(D Language Pipeline Syntax is BAD.) & SML(C Language Compatible) Like Function Syntax &Haskell Like Maybe Monad&Binary Execution speed Up.
> Plz,Now!!!

I also have to change the specification of the language.
First of all, we have to introduce this system!

People here under estimate the necessity to have EXCELLENT editor support

Without editor, nobody will want to write code in D, there are ton of languages now, all with great editor support (Rust, Go, Kotlin, Scalla, C#, java, C/C++), people have choice

There are 10 IDE/plugin project for d, this is too much, half are already dead, we go nowhere, please focus on one that is crossplatform (IntelliJ)

And jetbrains are working on Kotlin native, another big competitor..

On Sat, 2017-02-11 at 15:52 +0000, SC via Digitalmars-d wrote:
> People here under estimate the necessity to have EXCELLENT editor support
> 
> Without editor, nobody will want to write code in D, there are ton of languages now, all with great editor support (Rust, Go, Kotlin, Scalla, C#, java, C/C++), people have choice

Cannot disagree with this.

> There are 10 IDE/plugin project for d, this is too much, half are already dead, we go nowhere, please focus on one that is crossplatform (IntelliJ)

It isn't the number of different projects that is the problem. The problem is the lack of effort going in to the Eclipse and the IntelliJ IDEA plugins. In terms of traction of D, having an excellent Eclipse perspective, and an excellent IntelliJ IDEA and CLion plugin is essential.

Personally, I favour the IntelliJ IDEA and CLion IDEs. Work is progressing on the IntelliJ IDEA but it simply needs more people contributing actively – to my shame I haven't been able to put time into this myself, so I am contributing to the problem. This plugin uses Dub for build management, the CLion version needs to use CMake, so we need the CMake-D stuff to be up to scratch as well.

I have just tried out the Rust plugin to IntelliJ IDEA, it is excellent. JetBrains themselves have taken the Go plugin and turned it into Gogland a complete IDE. It is not half bad. D is very definitely losing in this IDE race, and thus in the potential for traction in the C, C++, Go, Rust, D milieu.

> And jetbrains are working on Kotlin native, another big competitor..

Interesting, but the current competition is between Go, Rust, C++, and D.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Saturday, 11 February 2017 at 18:51:31 UTC, Russel Winder wrote:
> Interesting, but the current competition is between Go, Rust, C++, and D.

I don't know, which fields are you thinking about? I believe the market is changing.

On OSX/iOS: Swift + Metal is the alternative, throw in some bits of Objective-C/C++ where you have long running tight inner loops.

On Windows: moving away from C# sounds very risky.

On Linux: this is more of an open space.

Embedded: C/C++, maybe Rust for those with courage? I suspect moving out of vendor supported tooling is risky (e.g. system-on-a-chip solutions)

Numerics: Python + low level libraries, Matlab etc.

But, the way I see it TypeScript + "native libraries" has the potential for covering a lot of ground. The eco system is exploding.

On Tue, 2017-02-14 at 10:22 +0000, Ola Fosheim Grøstad via Digitalmars- d wrote:
> On Saturday, 11 February 2017 at 18:51:31 UTC, Russel Winder wrote:
> > Interesting, but the current competition is between Go, Rust, C++, and D.
> 
> I don't know, which fields are you thinking about? I believe the market is changing.

It is also "re-tribalising" around the Rust, Go, Swift, C++17 for native code; Java 8/9, Kotlin, Scala, Groovy, Clojure on the JVM; ECMAScript, TypeScript, Elm in the browser, and Python in data science and such like. OK not orthogonal dimensions.

> On OSX/iOS: Swift + Metal is the alternative, throw in some bits of Objective-C/C++ where you have long running tight inner loops.
> 
> On Windows: moving away from C# sounds very risky.
> 
> On Linux: this is more of an open space.
> 
> Embedded: C/C++, maybe Rust for those with courage? I suspect moving out of vendor supported tooling is risky (e.g. system-on-a-chip solutions)
> 
> Numerics: Python + low level libraries, Matlab etc.
> 
> But, the way I see it TypeScript + "native libraries" has the potential for covering a lot of ground. The eco system is exploding.

An interesting perspective is who is putting money into IDEs and JetBrains are a good measuring device for this. C/C++ with CMake got CLion which is now getting a lot of Swift and Rust love. Go got a whole new IDE in Goglang. C#, Ruby, JavaScript get a lot of push, as do the gamut of JVM languages in IDEA – where the Rust plugin gets a lot of push. Python has PyCharm.

D has some small effort in IDEA, but it needs the resourcing to get to the level the Rust, Clojure, Scala, Groovy, Swift, Go, C++, Kotlin languages get.

It is noticeably that many people are leaving the Eclipse environment for the JetBrains one, Ceylon is a prime example. But Eclipse remains a player here (unlike NetBeans?)

Emacs, VIM, SublimeText, Atom, etc. get some love but few people really care about them compared to the Eclipse and JetBrains IDEs.

So if we measure traction by IDE and editor effort D is losing, along with Fantom, Crystal, Pony, Nim, and all the other languages that focus on the language to the expense of the way people use the language. Kingsley started work on the IDEA plugin and Bruno on the Eclipse plugin. Some people are working on the IDEA plugin (I am supposed to be as well, but I am failing). To get D out there with traction, these, not the compiler, should be the core focus of attention – the place where lots of resource is going in. Ceylon, Kotlin, Rust, Go have some core resource that attracts more resource, and there is a snowball effect.

No matter how good D and the compilers are, without high quality IDE support, it will be a peripheral language for the core adherents.

But we have been round this time and again, with extraordinarily little progress.


-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tuesday, 14 February 2017 at 10:22:26 UTC, Ola Fosheim Grøstad wrote:
> But, the way I see it TypeScript + "native libraries" has the potential for covering a lot of ground. The eco system is exploding.

Having done a fair amount of professional development in typescript over the last 6 months, I have to say I'm not as excited about it as I used to be. Don't get me wrong, I still think it's the best language in its space, but the javascript underneath it shows through in a lot of bad places and the lack of real meta-programming makes it hard to get your types exactly how you want them. Overall I've found it a frustrating when I compare it to working in D, despite it having a bunch of cool features I'd love to use in D.

On Wednesday, 15 February 2017 at 11:14:11 UTC, John Colvin wrote:
> On Tuesday, 14 February 2017 at 10:22:26 UTC, Ola Fosheim Grøstad wrote:
>> But, the way I see it TypeScript + "native libraries" has the potential for covering a lot of ground. The eco system is exploding.
>
> Having done a fair amount of professional development in typescript over the last 6 months, I have to say I'm not as excited about it as I used to be. Don't get me wrong, I still think it's the best language in its space, but the javascript underneath it shows through in a lot of bad places and the lack of real meta-programming makes it hard to get your types exactly how you want them. Overall I've found it a frustrating when I compare it to working in D, despite it having a bunch of cool features I'd love to use in D.

The structural flow type-system of TypeScript takes time to get used to and it only provides limited static type checks, so it has rather limited generating capabilities (typing is primarily for correctness checks and IDE-text-completion support). The template-expansion area is a field where D is better off, certainly.

What MS did right though was to create something that is not too unfamiliar for people that know languages like JavaScript, C#, Java or Swift, yet they absorb trendy frameworks like React and Angular as well as all existing JavaScript libraries. Not having a fixed build system is a weakness, and a bit frustrating, but I guess this is deliberately done to absorb as many developers as possible with their existing preferences. Objectively a competing language like Dart is better, but Dart is different enough to not having the ability to absorb developers.

My viewpoint is that this ability to absorb existing practices (like build systems and code bases) is probably where TypeScript is gaining traction from.

I think D might be a bit like Dart in this regard. It is closely related to, but yet too different from C/C++ to absorb the existing practices.

Another example is Swift. Swift managed to take over Objective-C rather quickly IMO, but Swift has also absorbed the non-C semantics of Objective-C, thus it did not require changing existing practice significantly.

On Wednesday, 15 February 2017 at 10:38:04 UTC, Russel Winder wrote:
> It is also "re-tribalising" around the Rust, Go, Swift, C++17 for native code; Java 8/9, Kotlin, Scala, Groovy, Clojure on the JVM; ECMAScript, TypeScript, Elm in the browser, and Python in data science and such like. OK not orthogonal dimensions.

Yeah, it isn't orthogonal dimensions. Not quite sure what you mean by "re-tribalising". Do you mean that developers have broken up from older languages like C++98 and Objective-C and regrouped over Rust, Go, Swift and C++17? I guess that is a reasonable interpretation.

I am still not sure exactly what Rust's demographic is, but I guess it may be catering for those that want a high-level C with a preference for functional programming over templated programming?


> An interesting perspective is who is putting money into IDEs and JetBrains are a good measuring device for this. C/C++ with CMake got CLion which is now getting a lot of Swift and Rust love. Go got a whole new IDE in Goglang. C#, Ruby, JavaScript get a lot of push, as do the gamut of JVM languages in IDEA – where the Rust plugin gets a lot of push. Python has PyCharm.

I haven't seen Gogland before, too bad I turned down the full suite IDE offering from JetBrains recently... VSCode with plugins is ok for Go and TypeScript though.

But it is a clear trend that newer languages are more tuned for IDE support, i.e. the language design is made with text-completion support in mind. This is one primary advantage with TypeScript over JavaScript for instance and alone worth the switch. Writing Python code with PyCharm is also quite different from using emacs, it is almost a "different language".

This trend will continue. Programming for iOS without XCode is unthinkable at this point, and similar situations exists for other platforms.

> Emacs, VIM, SublimeText, Atom, etc. get some love but few people really care about them compared to the Eclipse and JetBrains IDEs.

The cognitive load is just too high these days to use a regular editor if you want to be productive. The APIs are too big, there are too many of them, and they change too much and frequently to deal with "non-standard" editor issues. Just the automated hinting that something is deprecated and suggestions for replacements are invaluable time savers when upgrading codebases.

> So if we measure traction by IDE and editor effort D is losing, along with Fantom, Crystal, Pony, Nim, and all the other languages that focus on the language to the expense of the way people use the language.

I think IDE support should be part of the core project these days. My impression is that Dart had a lot more enthusiastic following when they provided a Dart-editor (eclipse fork). JetBrains supports Dart, but it isn't really the same thing when it isn't free and directly supported by the language provider.

I noticed that the Whiley website says that they are maintaining an eclipse plugin as part of the project.

> Kingsley started work on the IDEA plugin and Bruno on the Eclipse plugin. Some people are working on the IDEA plugin (I am supposed to be as well, but I am failing). To get D out there with traction, these, not the compiler, should be the core focus of attention – the place where lots of resource is going in.

One cannot expect volunteers to keep at it for years. And being left in the dark at some point in the future is not a very enticing prospect when adopting a language. There are currently more open source projects on github than (capable) developers... so one cannot expect others to take over either. It was different back in the day when emacs was the only real alternative.

Community driven development seems to no longer work reliably for projects that have high maintenance costs (with notable exceptions).

I guess this having something to do with the basic needs being met by the Linux ecosystem (the basic Unix toolset being available). Maslow's hierarchy of needs?

> Ceylon, Kotlin, Rust, Go have some core resource that attracts more resource, and there is a snowball effect.

I think Go has benefitted some from having limited and stable language semantics and continuously improving on the implementation. IMO that should make it attractive in the server space, i.e. you get low tooling-related maintenance cost and still get real benefits from recompiling with new versions of the compiler.

I don't much about Rust and snowball effects? I thought Rust had stagnated, but maybe I am wrong?

> No matter how good D and the compilers are, without high quality IDE support, it will be a peripheral language for the core adherents.
>
> But we have been round this time and again, with extraordinarily little progress.

The most important factor is the overall composition of the eco system and a good IDE makes it all come together. Kinda like a carpenter's workbench. You can make small scale stuff without, but you wouldn't do professional work on a tight schedule without a good stable workbench if can get one at another shop (language).

But a good IDE won't make significant change until the semantics for resource handling has been dealt with in a competitive manner... so there are several bits missing. Both Go, Swift and Rust provide "state of the art" memory management. D currently does not.

On 2017-02-15 17:07, Ola Fosheim Grøstad wrote:

> This trend will continue. Programming for iOS without XCode is
> unthinkable at this point, and similar situations exists for other
> platforms.

TextMate on macOS is a native macOS application (Cocoa, C++) but does not use Xcode to build, it's using ninja. I guess that's expected, to use TextMate to build TextMate.

-- 
/Jacob Carlborg

On Wednesday, 15 February 2017 at 16:28:00 UTC, Jacob Carlborg wrote:
> On 2017-02-15 17:07, Ola Fosheim Grøstad wrote:
>
>> This trend will continue. Programming for iOS without XCode is
>> unthinkable at this point, and similar situations exists for other
>> platforms.
>
> TextMate on macOS is a native macOS application (Cocoa, C++) but does not use Xcode to build, it's using ninja. I guess that's expected, to use TextMate to build TextMate.

It certainly is possible to build for macOS/iOS without using XCode, but still unthinkable for most. Even JetBrain's commercial offering fall short because they lag behind when Apple release a new OS version. If the language/framework vendor provides an IDE it becomes difficult to break into the market, if for no other reason than being sure that timeliness requirements are met.