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