On Fri, 2014-07-04 at 12:48 +0000, via Digitalmars-d wrote: […]
> I pick the most stable tool for the job. Meaning I usually end up with C, conservative use of C++, Python 2.7, Javascript, SQL or
[…]

That should, of course, have read Python 3.4!

-- 
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, 5 July 2014 at 06:48:23 UTC, Russel Winder via Digitalmars-d wrote:
>
> That should, of course, have read Python 3.4!

Most of my code has to run on App Engine, so I stick to whatever version Google use for all my Python stuff. They had Guido do their db-api a couple of years back so they probably stick with 2.7 for a good reason? Sometimes "stable" means "with known bugs and known work-arounds". ;)

On Friday, 4 July 2014 at 21:49:33 UTC, Ola Fosheim Grøstad wrote:
> On Friday, 4 July 2014 at 21:08:27 UTC, Walter Bright wrote:
>
>> Sadly, this also implies that there are no computer languages you believe in. You set an impossible standard. How can you possibly say you prefer C++, a classic design by committee language?
>
> I don't prefer it. I think it sucks, but it is the only viable choice if you want to create a scalable game or virtual world server.

Again, outside, in the real business world, reality is a little
different: take this monster, look, no C++!

http://www.robg3d.com/2014/01/why-ccp-is-still-using-python-2/
http://www.pcgamer.com/2013/06/15/eve-online/

What I loved about D, from the real beginning, was this:
pragmatism, pragmatism!

And after the love, what moved us as a company to adopt it was
Walter: He is a deeply pragmatic guy!
Pragmatism is an invaluable asset in business (btw, THAT should
be stressed in the logo/identity/redesign looooooong thread)

---
Paolo

On Saturday, 5 July 2014 at 09:39:10 UTC, Paolo Invernizzi wrote:
> Again, outside, in the real business world, reality is a little
> different: take this monster, look, no C++!
>
> http://www.robg3d.com/2014/01/why-ccp-is-still-using-python-2/
> http://www.pcgamer.com/2013/06/15/eve-online/

I don't play Eve, but in general the challenge in virtual worlds
is that you need to do full veracity checking on the server to
reduce cheating. You should also hide parts of the model so that
only the server knows it. Basically, you have to run the entire
sim on the server and only run parts of it on the client for
display purposes if you want to reduce cheating without
introducing draconian measures that basically takes over the
machine (which cannot work if the client runs in the browser).

Anyway, at the end of the day, for a freemium game you need to
cut server costs because you cannot estimate correctly how much
money you make per online user. With a subscription model you are
better off and can spend more on hardware.

What you can or cannot do, depends on the business model, the
market and the game design…

> What I loved about D, from the real beginning, was this:
> pragmatism, pragmatism!

I am pragmatic about this. I have stuff planned that can run on
Python on top of Google Datastore on the server and use
Dart+WebGL on the client. But if you want a physics based model,
user building and fast travelling you have to consider the worst
case scenario and you cannot do it in Python or using a disk
based database.  You need a in-memory database and hit the
hardware so that you can take the peaks without ending up with
molasses of latency.

> And after the love, what moved us as a company to adopt it was
> Walter: He is a deeply pragmatic guy!
> Pragmatism is an invaluable asset in business (btw, THAT should
> be stressed in the logo/identity/redesign looooooong thread)

The most valuable factor in business is predictability,
opportunities and being better at cutting costs than the
competition. Google are pragmatic, they dump IE9 on most of their
platforms. Unfortunately for businesses using Google tech that
means loss of predictability, lost opportunities and increased
costs.

Pragmatism in the context of D is community building. Sure, being
pragmatic about the logo is important, you should encourage
people using it in different ways because it is a community
building tool (among many). Like the penguin in Linux being used
in games etc. Community building means encouraging participation
and setting direction. If you don't set direction, people will
sit on the fence waiting for something to happen. Communities
don't build skeletons, they add meat to the bones.

On Saturday, 5 July 2014 at 11:14:40 UTC, Ola Fosheim Grøstad
wrote:
> On Saturday, 5 July 2014 at 09:39:10 UTC, Paolo Invernizzi wrote:
>> Again, outside, in the real business world, reality is a little
>> different: take this monster, look, no C++!
>>
>> http://www.robg3d.com/2014/01/why-ccp-is-still-using-python-2/
>> http://www.pcgamer.com/2013/06/15/eve-online/
>
> I don't play Eve, but in general the challenge in virtual worlds
> is that you need to do full veracity checking on the server to
> reduce cheating. You should also hide parts of the model so that
> only the server knows it. Basically, you have to run the entire
> sim on the server and only run parts of it on the client for
> display purposes if you want to reduce cheating without
> introducing draconian measures that basically takes over the
> machine (which cannot work if the client runs in the browser).
>
> Anyway, at the end of the day, for a freemium game you need to
> cut server costs because you cannot estimate correctly how much
> money you make per online user. With a subscription model you are
> better off and can spend more on hardware.
>
> What you can or cannot do, depends on the business model, the
> market and the game design…

I agree, but keep this is mind: a business model is not carved in
stone, it keeps changing, as the market is not a static thing.
And this is true also in the programming language field, as the
IT universe is not a static thing.

I liked the Lang.NEXT panel, especially when Bjarne talked about
the real world pressure over C++...

>> What I loved about D, from the real beginning, was this:
>> pragmatism, pragmatism!
>
> I am pragmatic about this. I have stuff planned that can run on
> Python on top of Google Datastore on the server and use
> Dart+WebGL on the client. But if you want a physics based model,
> user building and fast travelling you have to consider the worst
> case scenario and you cannot do it in Python or using a disk
> based database.  You need a in-memory database and hit the
> hardware so that you can take the peaks without ending up with
> molasses of latency.

If you read carefully, EVE was not designed for the actual number
of concurrent users: they was forced to keep changing, to survive
the challenges. The worst case scenario is the today worst case
scenario.

You can't design now for what you think will be the needs in a
too much distance future, that's will put your product in the
Longhorn cemetery. Things need to be done now, to get the current
business opportunity window.

>> And after the love, what moved us as a company to adopt it was
>> Walter: He is a deeply pragmatic guy!
>> Pragmatism is an invaluable asset in business (btw, THAT should
>> be stressed in the logo/identity/redesign looooooong thread)
>
> The most valuable factor in business is predictability,
> opportunities and being better at cutting costs than the
> competition.

Thinks are a little more complicated than that, but well, at the
end, business is all about satisfying the needs of someone else
who is free to choose among alternatives.

So, turning back into the floating point issue of the thread,
what's the most pragmatic move D can take about that floating
point performance issue?

Take the road that satisfy better the most demanded need asked
nowadays by D user base, so speed by default.
Satisfy the precision demand with real, but keep this need in an
explicit language domain corner: there's no silver bullet.

> Pragmatism in the context of D is community building. Sure, being
> pragmatic about the logo is important, you should encourage
> people using it in different ways because it is a community
> building tool (among many). Like the penguin in Linux being used
> in games etc. Community building means encouraging participation
> and setting direction. If you don't set direction, people will
> sit on the fence waiting for something to happen. Communities
> don't build skeletons, they add meat to the bones.

What I was meaning: "a pragmatic language" is a beautiful
business claim, let's stress it: it worked very well for me!

---
Paolo

On Saturday, 5 July 2014 at 13:16:28 UTC, Paolo Invernizzi wrote:
> I agree, but keep this is mind: a business model is not carved in stone, it keeps changing, as the market is not a static thing.

Ok, but for the virtual world side I am more driven by (artistic) model needs than the business side. So I am looking for a solution that fits the requirements.

> And this is true also in the programming language field, as the
> IT universe is not a static thing.

No, but for contractual work I need to be able to add small enhancements 12 months after deployment without adding transition costs. So a static dev environment matters a lot. If a customer expect that an enhancement takes 10 hours to add, I cannot charge for 50 hours. So if the dev environment incurs a transition cost I have to accept the enhancement request at a loss.

(App Engine is pretty stable and has a 12 months guarantee, which is on the low side IMO. I think 24 months would be more appropriate.).

> If you read carefully, EVE was not designed for the actual number of concurrent users:

I only glossed over it. I read external analyses of EVE 10 years ago when I studied online worlds. I believe they had some significant performance problems back. But the game model is not really low latency based.

> You can't design now for what you think will be the needs in a
> too much distance future, that's will put your product in the
> Longhorn cemetery. Things need to be done now, to get the current business opportunity window.

I'm not interested in virtual worlds for the business, but for the art of it. So my basic ideas are 10-20 years old and basically just waiting for the technology to catch up. ;^)

If I have to nudge the tech to make the last mile, ok, then I might have to do so…

> So, turning back into the floating point issue of the thread,
> what's the most pragmatic move D can take about that floating
> point performance issue?

Provide the tools to specify the constraints, like you do for nogc/safe, but with version support.

But I think D should be specified, not by the implementation, but in a paper. And I think the language should be cleaned up a bit, on paper, without thinking about the implementation cost for a specific compiler. Because if the resulting language is a true beauty, then more hands will come to add meat to the bones.

I'm not complaining about requiring strict IEEE 754 compliance, I am complaining about requiring it and then saying that it does not matter what the compiler devs do. Because it is obvious that on many platforms you don't get full compliance for special cases without some kind of software emulation/handling.

> What I was meaning: "a pragmatic language" is a beautiful
> business claim, let's stress it: it worked very well for me!

Python is a very pragmatic language, I don't like the dynamic aspects, but it is one of the most pragmatic languages out there.

The way I see it now, the most pragmatic solution would be to fork D, clean up the syntax a bit and make it work well for the domain of game servers. I don't need the libraries. Only UDP/TCP. Whether that is cost efficient compared to just using C++, I dunno. But the more I follow the discussions on the D forums, the more I feel that forking will be more productive than spending effort on affecting the current direction (which most probably will not get me what I want).

On 5 July 2014 15:20, via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Saturday, 5 July 2014 at 13:16:28 UTC, Paolo Invernizzi wrote:
>>
>> I agree, but keep this is mind: a business model is not carved in stone, it keeps changing, as the market is not a static thing.
>
>
> Ok, but for the virtual world side I am more driven by (artistic) model needs than the business side. So I am looking for a solution that fits the requirements.
>
>
>> And this is true also in the programming language field, as the IT universe is not a static thing.
>
>
> No, but for contractual work I need to be able to add small enhancements 12 months after deployment without adding transition costs. So a static dev environment matters a lot. If a customer expect that an enhancement takes 10 hours to add, I cannot charge for 50 hours. So if the dev environment incurs a transition cost I have to accept the enhancement request at a loss.
>
> (App Engine is pretty stable and has a 12 months guarantee, which is on the low side IMO. I think 24 months would be more appropriate.).
>
>
>> If you read carefully, EVE was not designed for the actual number of concurrent users:
>
>
> I only glossed over it. I read external analyses of EVE 10 years ago when I studied online worlds. I believe they had some significant performance problems back. But the game model is not really low latency based.
>
>
>> You can't design now for what you think will be the needs in a
>> too much distance future, that's will put your product in the
>> Longhorn cemetery. Things need to be done now, to get the current business
>> opportunity window.
>
>
> I'm not interested in virtual worlds for the business, but for the art of it. So my basic ideas are 10-20 years old and basically just waiting for the technology to catch up. ;^)
>
> If I have to nudge the tech to make the last mile, ok, then I might have to do so…
>
>
>> So, turning back into the floating point issue of the thread, what's the most pragmatic move D can take about that floating point performance issue?
>
>
> Provide the tools to specify the constraints, like you do for nogc/safe, but with version support.
>
> But I think D should be specified, not by the implementation, but in a paper. And I think the language should be cleaned up a bit, on paper, without thinking about the implementation cost for a specific compiler. Because if the resulting language is a true beauty, then more hands will come to add meat to the bones.
>
> I'm not complaining about requiring strict IEEE 754 compliance, I am complaining about requiring it and then saying that it does not matter what the compiler devs do. Because it is obvious that on many platforms you don't get full compliance for special cases without some kind of software emulation/handling.
>

This is a library problem, not a language problem.  In this case std.math uses real everywhere when perhaps it shouldn't.


>> What I was meaning: "a pragmatic language" is a beautiful business claim, let's stress it: it worked very well for me!
>
>
> Python is a very pragmatic language, I don't like the dynamic aspects, but it is one of the most pragmatic languages out there.
>

http://pyd.dsource.org


> The way I see it now, the most pragmatic solution would be to fork D, clean up the syntax a bit and make it work well for the domain of game servers. I don't need the libraries. Only UDP/TCP. Whether that is cost efficient compared to just using C++, I dunno. But the more I follow the discussions on the D forums, the more I feel that forking will be more productive than spending effort on affecting the current direction (which most probably will not get me what I want).

You mean, MiniD?  Someone has already done that, years ago....

http://jfbillingsley.com/croc/wiki/Lang/GettingStarted

On Saturday, 5 July 2014 at 15:09:28 UTC, Iain Buclaw via Digitalmars-d wrote:
> This is a library problem, not a language problem.  In this case
> std.math uses real everywhere when perhaps it shouldn't.

If x/y leads to a division by zero trap when it should not, then it isn't a library problem.

> You mean, MiniD?  Someone has already done that, years ago....

No, I meant forking D.

Ola Fosheim Grøstad:

> No, I meant forking D.

There is already Delight and FeepingCreature has created a D-like language. If you fork D you will have lot of fun :-) Keep us updated.

Bye,
bearophile

On Saturday, 5 July 2014 at 15:28:00 UTC, bearophile wrote:
> There is already Delight and FeepingCreature has created a D-like language. If you fork D you will have lot of fun :-)

Thanks :)

Both Delight and FeepingCreature appears to be alive. I guess that is a good sign.