On Thu, 2015-12-10 at 17:36 +0000, jmh530 via Digitalmars-d wrote:
> 
[…]
> Like how rdmd simplifies using dmd, you would want something that simplifies things further? Like so that when you run something from rdmd, it doesn't just compile things and then run, it starts running and then JITs what is needed.
> 
> I think there definitely would be something convenient about a language that you could easily compile or use like a scripting language without changing the syntax at all.

But isn't rdmd just a compiler and executor? It is not an interpreter. This is AOT with no role for JIT.

-- 
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 Thu, 2015-12-10 at 15:17 +0000, Jack Stouffer via Digitalmars-d wrote:
> […]
> 
> Is PyPy not really Python?

Yes it is. All Python compilers do though is generate bytecodes (as do all Java compilers). Then there is the question whether to AOT or JIT. PyPy JITs (as does CPython, sort of). Jython also JITs but this is on JVM bytecodes.

-- 
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 Thu, 2015-12-10 at 15:25 +0000, Jack Stouffer via Digitalmars-d wrote:
> […]
> 
> Please no.
> 
> Not everything has to be in Phobos; this just puts unnecessary pressure on Phobos maintainers to work on vibe.d as well, and it will slow down vibe.d development DRASTICALLY due to the extra scrutiny for Phobos PRs. Not to mention that breaking changes will no longer be able to happen with vibe.d. Also, vibe.d seems to be doing just fine as it is.

The days of "batteries included" in language distributions are well over. Something Python is having to come to terms with and not doing too well as yet. (Though Continuum Analytics are driving one possible future forward very well.)

The core distribution, here Druntime and Phobos, should only be that which is consciously in integral and required part of the language. Everything else should be in packages. Ceylon + Herd, Rust + Cargo + crates.io, Go + (Git|Mercurial), etc. My feeling is that Ceylon is a bit restrictive in that it only has a central curated repository. Go is being over libertarian in having no central repository but great support for DVCS repositories. Rust may be taking the best middle path, there is a curated central repository but also, easy access to Git and Mercurial repositories.

Clearly D has a package system, but in this it is like Ceylon. I think it needs to be more like Rust. So in this sense Dub needs to be more like Cargo. (It is already very like, in fact may have influenced.)

-- 
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 Thursday, 10 December 2015 at 08:43:21 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 10 December 2015 at 05:20:26 UTC, Joakim wrote:
>> I don't see why others are so concerned about it.  A better use of their time would be to chip in themselves, on documentation or whatever else they're capable of contributing.
>>
>
> I think the primary concern is "what is the plan?". Without a clear plan it really doesn't matter what you do or not do as an individual with just a few hours per week.

I agree that a plan needs to be articulated.  I hoped to get something like that from the vision statement, but broad goals like improving quality or fostering participation are pretty useless.  It should have gone into concrete detail on how they favored accomplishing those broad aims, say by better integrating Panteleev's Digger and other tools into the build process or improving the documentation about getting started on developing D itself.

Perhaps they've been burnt in the past by putting time into writing out concrete plans for D and nobody taking up those tasks- I don't know- but at the very least there should be a central place where others can see the core team's prioritized TODO lists.  Martin has done great work getting some of the core team on trello, but Walter and Andrei do not seem to use it:

https://trello.com/b/XoFjxiqG/active

Anyway, even without a plan, we can see from past commits on the backend alone that it's not a time suck.

> It's like voting or volunteering for a party with the right ideas, but no clear strategy for getting into position. The second concern is that people evaluate performance based on the official compiler. They evaluate Go, not gccgo, and they evaluate dmd, not ldc with an older frontend. This happens repeatedly when people write about these languages.

Hopefully, the recent change to the Downloads page to point out that dmd is faster to compile while gdc and ldc produce faster code will change that. I think you underestimate how much of a selling point dmd's speed is, even if I personally will not be able to use it on Android/ARM.

>> sweet spot in every market.  Perhaps those are better tools for those markets, while D will hit different segments of those markets and new markets altogether.
>
> That required a strategy. Like, I am now likely to pick up C again, just to be able to build tight asm.js. WebGL is now becoming mature and asm.js is becoming a massive target, but it takes a focused group to do better than emscripten... So you need a central strategy in order to organize something like that.

Personally, I think that entire web platform is stupid, so I don't care that D doesn't target it.  Mobile and embedded is a _much_ more important target and we're making headway there.  Dan recently got the D tests running on the Apple tvOS and watchOS simulators: soon you'll be able to run D on your TV or watch! :)

>> I agree that Swift is a strong competitor, as I've been saying, but it is currently way behind D in platform support, ie currently just iOS, OS X, and largely done linux/Glibc.  Each has their pros and cons and will garner their own adherents.
>
> Swift may need 1-2 more years, but if people can replace two languages with one, then they have a strong adoption card. But I am not sure if Swift will be able to gain C speeds consitently, though I would not bet on it.

Well, right now, D is on far more platforms, so it has a head start, though alpha quality on mobile.  I'm sure Swift will try to compete, but Apple is not going to port it to Android and it'll be interesting to see how much outside contribution they get, considering Apple is the largest company on earth and people don't really want to do their work for them.  D, without large corporate support, actually doesn't have that problem, ie a giant company pushing an OSS project is a double-edged sword.

The first time Apple tried to spur an OSS community with Darwin and their base OSS tools, it never took off, with Apple only providing open-source code dumps ever since.  It's only later efforts like WebKit, now forked by google for Chrome and Android, and llvm that have built OSS communities.  While Swift has a better chance, since it comes from the llvm group, it will be interesting to see how much outsiders contribute to it.

> But it is rather obvious that being similar to Swift is not a good strategy. If languages get too close, then the better ecosystem wins.

You assume that they're very similar and that Swift will have a better ecosystem eventually.  They are _somewhat_ similar but different enough to attract different devs, and I pointed out above why they might not be able to grow their community much larger.

On Friday, 11 December 2015 at 10:22:18 UTC, Joakim wrote:
> I agree that a plan needs to be articulated.  I hoped to get something like that from the vision statement, but broad goals like improving quality or fostering participation are pretty useless.  It should have gone into concrete detail on how they favored accomplishing those broad aims, say by better integrating Panteleev's Digger and other tools into the build process or improving the documentation about getting started on developing D itself.

Well, my main issue with D is that there is no plan for making things simpler in order to add more advanced clean features based on modern static analysis at the next stage. New features are added, like hacking in C++ support or multiple-alias-this, that just adds more complexity.

Although I still have some hope that a refactored codebase could make "simplification" possible as a side project by an independent group. But making a cleaner version of that language doesn't seem to be on the map by the core developers. As such, D is in the same tarpit as Go. "We are done". Ok, but then these languages will remain in a very small niche that most likely will shrink, not grow. To me, both Go and D are stuck a little bit in the past and I think both languages will need to move one step back in order to make a leap forward.

C++14 would have been great if they had bothered to clean up the language before adding even more to it. I think C++ is a good example of what happens when one doesn't take a step back and clean up in time.

> I think you underestimate how much of a selling point dmd's speed is

Even so, the best performing compiler ought be the official one and released first.

Go also is acclaimed for great compilation speed, yet people complain about execution and say they switch to Rust over it etc. And Rust is known to be slow at compilation.

> Personally, I think that entire web platform is stupid, so I don't care that D doesn't target it.

This is the big problem. It is an open target that is available, and you only compete with C/C++. Yet it isn't prestige among language devs to target it, and it isn't established, so people ignore it. In 5 years people will curse because they didn't actively target it before other languages got established on it.

If you want to grow that is exactly the kind of target you want. People switch if you are the only alternative. That is exactly when they switch to smaller niche products.

People adopted Perl, it was the only real alternative for prototyping like transforms of text.

People adopted Php, it was the only real alternative for embedding code into html.

People thought those application areas were so boring compared to "a general purpose language". It was  not "serious" programming areas. So these languages owned those domains for many years, and grew big.

> Dan recently got the D tests running on the Apple tvOS and watchOS simulators: soon you'll be able to run D on your TV or watch! :)

That's great fun! But it isn't a business-plan with Swift being there already.

> Well, right now, D is on far more platforms, so it has a head start, though alpha quality on mobile.  I'm sure Swift will try to compete, but Apple is not going to port it to Android and

I think they are going to make some core libraries available. I think that has been announced.

> The first time Apple tried to spur an OSS community with Darwin and their base OSS tools, it never took off, with Apple only providing open-source code dumps ever since.  It's only later

There is a lot demand for an easy path from iOS to Android that does not involve hacks like C#. There was actually a Swift compiler made by another company for that purpose. But with Apple backing this approach it becomes much more attractive.

> Android, and llvm that have built OSS communities.  While Swift has a better chance, since it comes from the llvm group, it will be interesting to see how much outsiders contribute to it.

There are some speculations on whether Apple might want to compete with AWS, Google and Microsoft and use Swift as the platform. (iCloud)

> You assume that they're very similar and that Swift will have a better ecosystem eventually.  They are _somewhat_ similar but different enough to attract different devs, and I pointed out above why they might not be able to grow their community much larger.

I assume that some people _might_ bother to weed out the efficiencies in Swift that are related to staying compatible with Objective-C and turn it into a reasonable high level system level language for those that don't need that compatibility.

It won't compete directly with Rust or C++, but it might compete fiercely with other languages that go the ARC route.

On Friday, 11 December 2015 at 11:42:31 UTC, Ola Fosheim Grøstad wrote:
> There is a lot demand for an easy path from iOS to Android that does not involve hacks like C#. There was actually a Swift compiler made by another company for that purpose. But with Apple backing this approach it becomes much more attractive.

For those interested, this is the alternative Swift compiler I was referring to. I haven't tried it though, but it seems to mix with Java/C#:

http://www.elementscompiler.com/elements/silver/

On Friday, 11 December 2015 at 07:40:55 UTC, Jacob Carlborg wrote:
>
> I'm not sure how related rdmd is to the above mentioned features. If one would use rdmd for the above, it would require to compile the code as a dynamic library and the load that. I guess that could be possible.

I was really trying to get a handle on what their point was.

rdmd provides an immediacy that is similar to using some scripting languages. For me, rdmd is better to use when prototyping something than C++, but I'm still more productive prototyping something with R or Matlab.

Nevertheless, while I think there is value in an REPL-like environment for D, I would also give it a low, low priority.

Some people have said things like D is an AOT compiled language. Fine. But imagine you had a scripting language with the exact same syntax and semantics as D, but this language can be used with an REPL. Maybe there would be a few differences, but for the most part a program written in this language could also be compiled with dmd.

Consider the relationship between C and Ch. It provides an REPL interactive shell for C along with some other changes. While there are some differences, you're still basically using an interpreted version of C.

Let's suppose there's a Dh that is to D as Ch is to C. Would some people find value in Dh? I think yes. Would there be some overlap between implementing this hypothetical language and dmd/rdmd? I would suspect quite a bit (though I don't know enough of the technical details). Would it be possible to use a JIT in the implementation? I don't see why not. Should smart people work on creating Dh? I'm guessing other priorities are more important.

On Thursday, 10 December 2015 at 15:16:05 UTC, Paulo Pinto wrote:
> Both are now getting AOT compilers as part of their standard toolchains.

I found this video interesting:

https://channel9.msdn.com/Events/ASPNET-Events/ASPNET-Fall-Sessions/Introducing-the-dotnet-CLI

Apparently it will become possible to AOT C# libraries and call them from other languages?

On Friday, 11 December 2015 at 11:42:31 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 11 December 2015 at 10:22:18 UTC, Joakim wrote:
>> I agree that a plan needs to be articulated.  I hoped to get something like that from the vision statement, but broad goals like improving quality or fostering participation are pretty useless.  It should have gone into concrete detail on how they favored accomplishing those broad aims, say by better integrating Panteleev's Digger and other tools into the build process or improving the documentation about getting started on developing D itself.
>
> Well, my main issue with D is that there is no plan for making things simpler in order to add more advanced clean features based on modern static analysis at the next stage. New features are added, like hacking in C++ support or multiple-alias-this, that just adds more complexity.

Unless you articulate what your alternate plan is to make things simpler, perhaps along with some github PRs or a DIP, things will keep going as they are.

> Although I still have some hope that a refactored codebase could make "simplification" possible as a side project by an independent group. But making a cleaner version of that language doesn't seem to be on the map by the core developers. As such, D is in the same tarpit as Go. "We are done". Ok, but then these languages will remain in a very small niche that most likely will shrink, not grow. To me, both Go and D are stuck a little bit in the past and I think both languages will need to move one step back in order to make a leap forward.
>
> C++14 would have been great if they had bothered to clean up the language before adding even more to it. I think C++ is a good example of what happens when one doesn't take a step back and clean up in time.

I completely agree that languages need to clean up and release breaking versions at some point, just as D did with the 2.0 release.

>> I think you underestimate how much of a selling point dmd's speed is
>
> Even so, the best performing compiler ought be the official one and released first.

I don't see why, usually you prototype first with the faster compiler, then build for production with the slower one with better codegen.  Of course, it doesn't help that ldc/gdc are behind in the frontend version they're using, but you could always use an older dmd to prototype if you know you'll need ldc/gdc.

> Go also is acclaimed for great compilation speed, yet people complain about execution and say they switch to Rust over it etc. And Rust is known to be slow at compilation.

I'm sure both types of speed have their own audience, but with D you can have both. :)

>> Personally, I think that entire web platform is stupid, so I don't care that D doesn't target it.
>
> This is the big problem. It is an open target that is available, and you only compete with C/C++. Yet it isn't prestige among language devs to target it, and it isn't established, so people ignore it. In 5 years people will curse because they didn't actively target it before other languages got established on it.

I don't think system programming languages have much of a shot at web dev, which is why I've always said the market for vibe.d is limited, no matter how great it is.  C/C++ certainly have almost no penetration there.  Web devs use scripting languages to prototype, then switch to Java when they need to scale.  D could maybe hit those who want to scale beyond that, but that's not many places.

Your asm.js/WebAssembly target is a little different, but using the web for such apps is just as dumb.  There are good reasons why mobile is ascendant and webapps on the downswing.

> If you want to grow that is exactly the kind of target you want. People switch if you are the only alternative. That is exactly when they switch to smaller niche products.
>
> People adopted Perl, it was the only real alternative for prototyping like transforms of text.
>
> People adopted Php, it was the only real alternative for embedding code into html.
>
> People thought those application areas were so boring compared to "a general purpose language". It was  not "serious" programming areas. So these languages owned those domains for many years, and grew big.

"Grew big" _in those domains_, ie they have made no inroads into other markets.  This is what I keep pointing out to you: you can optimize for one niche and do extremely well there, but then you often find yourself stuck in that niche, as Go finds itself today.

>> Dan recently got the D tests running on the Apple tvOS and watchOS simulators: soon you'll be able to run D on your TV or watch! :)
>
> That's great fun! But it isn't a business-plan with Swift being there already.

It is for those who want to be cross-platform, as D pretty much passes all its tests on Android and iOS, while Swift is still only on iOS.

>> Well, right now, D is on far more platforms, so it has a head start, though alpha quality on mobile.  I'm sure Swift will try to compete, but Apple is not going to port it to Android and
>
> I think they are going to make some core libraries available. I think that has been announced.

Not for Android, Apple will _never_ make Swift for Android, the community will have to do that.

>> The first time Apple tried to spur an OSS community with Darwin and their base OSS tools, it never took off, with Apple only providing open-source code dumps ever since.  It's only later
>
> There is a lot demand for an easy path from iOS to Android that does not involve hacks like C#. There was actually a Swift compiler made by another company for that purpose. But with Apple backing this approach it becomes much more attractive.

Apple is not backing any approach: they're making the source available so devs can do anything they want with it.

>> Android, and llvm that have built OSS communities.  While Swift has a better chance, since it comes from the llvm group, it will be interesting to see how much outsiders contribute to it.
>
> There are some speculations on whether Apple might want to compete with AWS, Google and Microsoft and use Swift as the platform. (iCloud)

If so, they're pretty dumb, as server hosting is a low-margin, highly competitive business.  I have no idea why google or MS would want to be in it.  Amazon I kind of understand, because their retail business is even lower-margin!

I think Apple has long ago learned the lessons of WebObjects, Xserve, and OS X Server: stay out.

>> You assume that they're very similar and that Swift will have a better ecosystem eventually.  They are _somewhat_ similar but different enough to attract different devs, and I pointed out above why they might not be able to grow their community much larger.
>
> I assume that some people _might_ bother to weed out the efficiencies in Swift that are related to staying compatible with Objective-C and turn it into a reasonable high level system level language for those that don't need that compatibility.
>
> It won't compete directly with Rust or C++, but it might compete fiercely with other languages that go the ARC route.

Which isn't D either, unless you include D because of the GC.  Swift looks like a strong competitor- I've always said that- but it's yet to be seen what kind of uptake it gets out of its home turf of iOS.

On Sunday, 13 December 2015 at 12:29:49 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 10 December 2015 at 15:16:05 UTC, Paulo Pinto wrote:
>> Both are now getting AOT compilers as part of their standard toolchains.
>
> I found this video interesting:
>
> https://channel9.msdn.com/Events/ASPNET-Events/ASPNET-Fall-Sessions/Introducing-the-dotnet-CLI
>
> Apparently it will become possible to AOT C# libraries and call them from other languages?

Yep, that's what Paulo keeps referring to.

On Tuesday, 15 December 2015 at 16:17:32 UTC, Joakim wrote:
> Unless you articulate what your alternate plan is to make things simpler, perhaps along with some github PRs or a DIP, things will keep going as they are.

I don't think series of DIPs will change anything. First we need to be close to consensus on what ought to be done better.

But since Swift has SIL and Rust is getting MIR, I'm starting to think that it would be overall less work to build a new language adopted to one of those than polishing Nim, Crystal and D... That option didn't really exist before, and it won't resonate well with D designers either.

But it is a reasonable strategy when languages seem to be converging on semantics that are rather similar.

The basic question is: can you afford to compete?

Yes, if you reuse existing infrastructure, not only what exists, but what is coming.


> Your asm.js/WebAssembly target is a little different, but using the web for such apps is just as dumb.  There are good reasons why mobile is ascendant and webapps on the downswing.

I don't think there is a downswing for web-apps.


> you can optimize for one niche and do extremely well there, but then you often find yourself stuck in that niche, as Go finds itself today.

Being stuck in Go's niche would be a fantastic situation for D as Go's market penetration might be 20x that of D. The main limitation for Go is the Go language authors' vision and attitudes. Not really related to the domain.


> Which isn't D either, unless you include D because of the GC.

D2 appears to be going for ref counted ownership, so I assume that the outcome will be that D2 becomes comparable to Swift with ARC.

D2 might have trouble finding a key feature to market after Swift adds hygienic macros. Depending on how they go about it.