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
