On Friday, 24 April 2015 at 07:33:42 UTC, weaselcat wrote:
> I'm biased because I do essentially zero webdev though, so when I see a lot of changes for std.json or text processing, I don't get too excited. D has a lot of sugar but missing many essential things you'd expect if you want to compete with C++.

I do webdev, but I would not use D for it. Integration with the surrounding infrastructure is more important in most webdev applications (e.g. frontends, caching, load balancing, distributed databases/file systems don't have to be application specific).

D could fit for a game server, but json and text processing? Nah. The only C++ text processing I do are file paths and the like.

D has a slight edge on C++ when it comes to arrays and slicing. Like I spent several days writing my own type safe array slice library to improve my C++ codebase, but then I realized that a library solution is more flexible than a builtin for reference types like slices (template matching on any parameter you want: fixed size, alignment, unique typing, strides, 2D slicing, special casing for void slices). So overall, not sure if it makes sense to have it as a builtin if you also have meta programming features.

> for example, typecons.unique has been in an unusable state for... ever? It's just another one of those things in D that

The memory model needs work and uniformity, not a quick fix. Good unique ownership and stack allocation is critical. I don't recall the last time I used reference counting in C++ and I cringe every time I do heap allocation by reference (rather than embedding).

> I think pattern matching and better meta programming in general would make the language better either way.

Yes, that can be an advantage if you also simplify the core language when you can express the syntactical sugar using the meta programming features.

Ideally the core language should just be a high level VM, which you use to verify memory safety, separate compilation, high level optimization etc.

On Friday, 24 April 2015 at 07:04:10 UTC, Ola Fosheim Grøstad wrote:
> the market for programming languages is a Winner Takes It All market.

/*Scratching my head*/

I don't see how anyone could possibly describe the current landscape as "winner takes it all". Scala, Clojure, D, Go, Haskell, C#, Objective C, Swift, Ceylon, Python, Ruby, PHP, Julia...these are just a few of the languages that I've watched develop in recent years.

On Friday, 24 April 2015 at 14:41:13 UTC, bachmeier wrote:
> On Friday, 24 April 2015 at 07:04:10 UTC, Ola Fosheim Grøstad wrote:
>> the market for programming languages is a Winner Takes It All market.
>
> /*Scratching my head*/
>
> I don't see how anyone could possibly describe the current landscape as "winner takes it all". Scala, Clojure, D, Go, Haskell, C#, Objective C, Swift, Ceylon, Python, Ruby, PHP, Julia...these are just a few of the languages that I've watched develop in recent years.

General system level languages: C/C++, Ada. The rest are marginal.

On the JVM you get some "big" marginal languages in addition to Java because you have a stable VM, thus reducing risk/retain interoperability. But they are marginal compared to Java.

Objective-C/Swift would be dead without Cocoa. They are framework languages and marginal outside the framework.

C# would be dead without Windows. It is a framework language that is being pushed outside the framework, but would still die without it.

Web dev is a fashion industry, not an engineering discipline. The hot frameworks shift constantly: Perl is dying, Php is dying, Ruby may be next, Go is still marginal and could be a fad.

Haskell is a marginal language, even though it is big within the FP community as it is backed by programming language research (you can say the same about ML).

Adoption of programming languages are by nature tied to their eco system (libraries, frameworks, and eductional resources), so you have potential for exponential growth and lock in, hence the winner takes it all.

There are _lots_ of languages, most are close to dead, some are lingering, some are clinging to a niche... but only a few ones gain momentum.

On Friday, 24 April 2015 at 16:40:03 UTC, Ola Fosheim Grøstad wrote:

> There are _lots_ of languages, most are close to dead, some are lingering, some are clinging to a niche... but only a few ones gain momentum.

Well, I don't want to get into a big debate about how you define those things. I'll just say that I'm not concerned about D disappearing. I write some D code, drop it into an R package along with a Makefile, and my coauthors and I are using D. None of the things you claim as design flaws are a problem for us.

As always, when it comes to programming languages, it really depends on what you're trying to do. Not that long ago someone around here was claiming Python is a niche language like Haskell. On Reddit, garbage collection is often called a design flaw. YMMV applies more to programming languages than about anything else.

On Friday, 24 April 2015 at 20:50:17 UTC, bachmeier wrote:
> along with a Makefile, and my coauthors and I are using D. None of the things you claim as design flaws are a problem for us.

Sounds like your usage fall into the category "compiled scripting language", but there you have many alternatives. So, you may use D for such, but I'd question if that is a rational direction.

For system programming a solid unmanaged memory model, strong typing, verification and near optimal performance matters. The requirements are much more demanding.

> As always, when it comes to programming languages, it really depends on what you're trying to do. Not that long ago someone around here was claiming Python is a niche language like Haskell.

Which is wrong.

Python and Haskell are opposites. Python is a versatile general dynamic imperative _scripting_ language, suitable for connecting components top-down. Haskell is a statically typed functional programming language where you design bottom-up. Haskell has a small following (but big within FP). Python has a wide following, extensively documented, to the level where it is difficult to find a question unanswered when using Google.

>On Reddit, garbage collection is often called a design
> flaw. YMMV applies more to programming languages than about anything else.

C++ would have been dead if the memory model was based on a Boehm GC. Many people have tried and left D due to compiler quality and GC. If those two issues had been given the highest priority (over new features) D would have taken a larger market share a long time ago.

(And no Tango/Phobos was not a big deal, just a minor annoyance.)

On Fri, 24 Apr 2015 14:41:11 +0000, bachmeier wrote:

> On Friday, 24 April 2015 at 07:04:10 UTC, Ola Fosheim Grøstad wrote:
>> the market for programming languages is a Winner Takes It All market.
> 
> /*Scratching my head*/
> 
> I don't see how anyone could possibly describe the current landscape as "winner takes it all". Scala, Clojure, D, Go, Haskell, C#, Objective C, Swift, Ceylon, Python, Ruby, PHP, Julia...these are just a few of the languages that I've watched develop in recent years.

yet how much of them are really used for something serious?

C and C++ -- thanks to libraries
PHP -- thanks to monkeys
C# -- thanks to m$
Obj-C -- thanks to apple
sometimes Ruby and nodejs with js (oh god, why?!).

that's all. you can find some niche projects on other languages, but that doesn't really matters.

On Saturday, 25 April 2015 at 07:51:38 UTC, Ola Fosheim Grøstad wrote:
> C++ would have been dead if the memory model was based on a Boehm GC. Many people have tried and left D due to compiler quality and GC. If those two issues had been given the highest priority (over new features) D would have taken a larger market share a long time ago.
>
> (And no Tango/Phobos was not a big deal, just a minor annoyance.)

That's me. I looked at D a while back and started playing around with it some, but it seemed at the time D was still working out it's design (v2 was being discussed) and the GC seemed too integral in the libraries. I came back recently to see how its progressed and the focus seems to be like it wants to be a lower level scripting language. I can just use Java or C# for such things, both have a wider range of supported platforms and perform pretty well for having a GC. D does seem nice for shell scripting on *nix though.

But the GC is annoying when making games, it's like a network lag, very noticeable, even with tuning.

I use C++ as C with classes. If C had namespaces, strings, templates with a good syntax and was all in one file it would be a dream (classes are a bonus). That was my initial impression of D... until I learned of the GC. Then I thought of it as Java/C# without the VM.

The lack of supported platforms was also a consideration. At a minimum I'd want 64 bit desktop support for Linux, OSX and Windows and mobile support for iOS and Android. LDC is tempting.

Hi Ola.

You have been in this community for much longer than me, and I always learn from your posts technically.

> I find it worrying that the evangelical D users are perceiving D as a compiled scripting language and claim it is similar to Python... D semantics are not at all like Python. That can't win.

Why does it worry you?  What bad things will happen?  People say all kinds of things and have all kinds of delusions about reality, yet the sky doesn't fall.  To an academic computer scientist, no doubt Python and D could not be more different.  To someone in the commercial world (hedge funds are what I know best), what tool do you pick up next to process your data when Python starts to choke?  Both the Eurostar and the plane will get you from London to Berlin - they work on very different principles technically, but am I a fool for considering them substitutes?

> I find it worrying that the people who say they want to use D as a system programming language are into games, yet the projected vision for the D leadership now is to make it a web programming language that should ship with vibe.d. That can't win.

Perhaps it's obvious to someone more familiar with the specific questions, but I think your argument would be more effective if you explained why shipping vibe.d somehow detracts from D's potential as a systems programming language, or for games in particular.  There are games devs here, and although they are spirited and opinionated, I don't recall them arguing against incuding vibe.d.

> I find it worrying that so many people attracted to D system level programming are into games, yet game development needs are ignored. That can't win.

Really?  You have a man with the expertise and experience of Walter Bright devoting his time to rewriting string processing parts of the standard library himself, in service of the goal of making Phobos GC free, and you say that game development needs are ignored?  (Not that games need strings, but that either a library is GC free or it isn't, and this is something games people seem to care about).  Plus all the work on refcounting etc.  I am sure there are many other aspects, and games themselves don't interest me, but that doesn't strike me as a balanced perspective.

It's odd to mention D's role as a systems language without discussing its use in embedded systems.  The pioneer who spoke at dconf a couple years back undertook a valiant effort, but it was too much for him to manage in one go.  (And of course Adam Ruppe's highly entertaining presentation on bare metal programming).  But although the pioneers may have the arrows in the back and not always be so happy about the situation, they do clear the way for others - these now  seem to be picking this up, and I would be really surprised if D is not pretty usable on a decent subset of embedded systems in a couple of years.

Similarly the work on ARM/Android/iOS, which seems to be coming along.

> There is a need to move towards something beautiful, and that's not in Andrei's vision, but in the original D1 vision + the improvements proposed by Bearophile, Timon Gehr and others.

I appreciate you may not have time, but if you had any links to stuff if they are gathered in documents rather than myriad fragments, I would be curious to see.

> …but move...

It's not for me to talk about strategy.  But it strikes me that you are calling for a further massive shift, when people have their plates too full already.  It may not be exciting, but full C++ support, making Phobos GC free, rounding out refcounting and introducing custom allocators seem to me to be likely to have a more immediate and more powerful impact than what you suggest, whatever may be the longer-term merits.  (I would like to understand these)

> Remember: It's a winner takes it all game.

I notcie that you keep asserting this, without taking the trouble (that I have seen) to argue the reasons for this belief.  The winner takes all idea can be traced to the work of Vilfredo Pareto, but he spends some time speaking about the circulation of the elites.  In other words the top dog is not static - this applies to income of a relatively free-market nation, and it also applies to other aspects of this phenomenon in human society.

It's a human tendency to lack imagination and to believe that the present state of things is how they intrinsically are and can never change.  This tendency is developed in our era by the mental habits that go with the way we use technology (see Iain Macgilchrist's work), and yet it also creates tremendous opportunity for those with imagination and perceptiveness.

You might as well have said To Honda, Toyota, Nissan, Hyundai etc that "it's a winner takes all game" when their products were demonstrably inferior with little prospect ever of competing with US cars - the idea of that would have been laughable.  But beyond being mistaken, this would not have been helpful advice.

I don't follow the news closely day to day, and just saw there are now 8Tb drives for a couple of hundred pounds.  These days you can download not just data for US equities, but the majority of all non-intraday data for all publicly listed stocks, futures, and currencies and economic series for free - this used to cost $100k pa plus.  So data sets keep growing - CPU performance continues to improve, but in a less convenient way, but as I understand it memory perf lags.  Which means in the future you may be increasingly irritated by people speaking of using D for scripting purposes...


Laeeth.

i couldn't agree more with Ola Fosheim Grøstad. the d1 vision was great and d2 has become an abomination of a scripting language. i left after the demise of d1 and the lot of andrei's ideas.
now come every once in while and see whats going on - and hope maybe in d3 it will go back to the vision of d1.
no offense intended

On Friday, 24 April 2015 at 07:04:10 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 24 April 2015 at 02:33:19 UTC, ketmar wrote:
>> On Thu, 23 Apr 2015 19:05:06 -0700, Walter Bright wrote:
>>
>>> On 4/23/2015 5:37 AM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
>>> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>>>> Yes, it is because of modular artithmetics which is a D design flaw.
>>> 
>>> Out of the innumerable posts you write, I can't recall one which didn't
>>> assert that whatever D does is wrong.
>>
>> that's 'cause he don't talking about features done right. ;-)
>
> Oh, but I have!! I've pointed out that the vision for D1 was right, but D2 ruined it by adding cruft without fixing the flaws... ;-)
>
> Walter got A LOT right in his original _vision_ as represented on his original website for D1:
>
> - Taking current practice for C++ and building a better syntax for the most common patterns.
>
> - Clearly stating that a programming language should encourage you to write code that is aesthetically pleasing on the screen and make that easy.
>
> - Clearly stating that language semantics should be so simple that you didn't need a long specification for it.
>
> - Clearly stating that performance was imperative as a goal for the language and that D would not aim to replace higher level languages like C#.
>
> I can applaud to this, anyone who has exposed themselves to the annoyances of C++ can applaud to this! And D1 was a step in the right direction. A good start.
>
> The vision was lost on the way to D2, and most unfortunately the market for programming languages is a Winner Takes It All market. D2 is only a marginal improvement on C++, and worse in some areas. That can't win.
>
> I find it worrying that the evangelical D users are perceiving D as a compiled scripting language and claim it is similar to Python... D semantics are not at all like Python. That can't win.
>
> I find it worrying that the people who say they want to use D as a system programming language are into games, yet the projected vision for the D leadership now is to make it a web programming language that should ship with vibe.d. That can't win.
>
> I find it worrying that so many people attracted to D system level programming are into games, yet game development needs are ignored. That can't win.
>
> D is lucky that Rust is annoying, Go is marginal, and Nim is unknown, so people are stuck with ugly look C++ code.
>
> There is a need to move towards something beautiful, and that's not in Andrei's vision, but in the original D1 vision + the improvements proposed by Bearophile, Timon Gehr and others. Or swing 100% to Andrei's direction and improve significantly on meta programming by adding pattern matching and partial evaluation, so that you have something significantly better than C++.
>
> …but move...
>
> Remember: It's a winner takes it all game.

I get so tired of non game devs spouting off about what they think gamedevs do.  Let me give you a clue, we are aware of the internet.  We do process strings and JSON.  Not only that but we usually do this stuff in C++, and it often sucks to write.  There is really only a small fraction of game code that tends to look like low level C.  There are people who spend all their time writing this kind of code, but there are tons of other programers doing other things.  Farming this work out to C# isn't a realistic option at runtime, and at tool time it requires maintaining bindings.  That's part of the reason D is attractive to me as a gamedev.  I WANT all those high level features, I want them to be performant, and I want the ability to write low level code when necessary.  D1 just doesn't cut it.