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).
