Re: The Revenge of the Geeks
Date: Thu, 24 Jan 2013 16:10:54 -0600
Message-ID: <kdsbk5$575$1_at_news.albasani.net>
On 1/24/2013 10:06 AM, Arne Vajhøj wrote:
> On 1/23/2013 11:47 PM, BGB wrote: >> On 1/23/2013 7:17 PM, Arne Vajhøj wrote: >>> On 1/23/2013 5:35 AM, BGB wrote: >>>> On 1/23/2013 3:25 AM, Arved Sandstrom wrote:
>>>>> On 01/23/2013 02:21 AM, BGB wrote:
>>>>>> On 1/22/2013 11:33 PM, Kevin McMurtrie wrote: >>>>>>> Yes, it is a shame that Oracle runs Java but Sun wasn't so great >>>>>>> at it >>>>>>> either. Both pushed for high cost, high complexity "enterprise >>>>>>> edition" >>>>>>> libraries that come and go like fashion but dragged their feet on >>>>>>> streamlining the language itself. >>>>>> >>>>>> much agreed... >>>>>> >>>>>> the lack of "streamlining" of the core language is admittedly one >>>>>> of my >>>>>> bigger complaints about Java at present. >>>>>> >>>>>> this is along with what few new features are added to the core >>>>>> language >>>>>> (and to the JVM) are IMO far too often via ugly hacks. >>>>>
>>>>> I'm not too worried about Java the language being close to
>>>>> stagnant, so
>>>>> long as library development is up to par. Because if the solution I've
>>>>> selected includes the JVM, then often Scala or Clojure are better
>>>>> choices for high-productivity coding. Myself I don't care if Java the
>>>>> language ever gets updated again - it's not important. The innovation
>>>>> shifted away from Java the language years ago; there are better JVM
>>>>> options now.
>>>>>
>>>>> So I would disagree with both you and Kevin that "streamlining" the
>>>>> core
>>>>> language is all that important. You can't do enough of it to core Java
>>>>> to make it worthwhile, without major changes. So why bother now?
>>>>> What's
>>>>> important actually *are* those "high cost, high complexity EE
>>>>> libraries", plus the later SE/EE-agnostic libraries like concurrency.
>>>> >>>> yes, but the lack of polish for the core language doesn't really make >>>> using Java a particularly attractive option when contrasted against, >>>> say, C++ or C#. >>> >>> I don't think Java should worry about C++. For business apps, then >>> C++ is not really an option. And business apps is what Java is good >>> at. >> >> some of us never go anywhere near business apps though... > > Yes. But then Java may not be the obvious choice. > >> for example, I am mostly at-present a game developer, with side areas in >> audio/video processing (writing codecs, ...), and am also into things >> like compilers and scripting VM technology. >> >> these are generally areas where C and C++ have a much stronger hold. > > Yes. > > Java is probably almost non-existing on the graphical side. > > I believe some multi-player games use Java server side. >
Minecraft has both the client and server end written in Java.
don't know much about others games.
most of the other game engines I am aware of are typically written in C or C++, usually with either a common scripting language (such as Python or Lua), or a specialized scripting language (such as UnrealScript, descendants of QuakeC, ...).
in most I am familiar with, servers are typically run by individuals, usually either a "listen server", where the player runs the server and also plays the game at the same time, and other players may join their world, or a "dedicated server", typically where the server runs in its own process, which may or may not be on the same computer the player is using to play the game.
I am less familiar with MMOs though, but from what I can gather it is more often that they will do something like the dedicated server case, just typically run each area on its own server (often each on a different physical computer as well). when a player hits an area between server-managed regions, they will typically just jump from one server to another.
my project more fits into the category of a game-engine mostly in C with a scripting language, and is mostly aiming for the listen-server and player-run dedicated-server use case (which may be coupled with the use of an HTTP server for pulling other game contents).
I ended up trying to use Java for scripting at one point (since Minecraft made it look like maybe this made sense), and ended up using my own custom mini-JVM (using a JavaME like subset, mostly due to JNI frustration), but soon enough realized that it didn't really make a particularly great scripting language (didn't really fit in well with the use case, and I couldn't readily "eval()" it).
(I also evaluated using .NET and/or Mono and C# for scripting, but this also looked like a big mess).
so, effort mostly shifted back to my custom script language, which is more closely derived from JavaScript and ActionScript (with a lot more elements from C, Java, C#, ... glued on). (like, hell, I will glue on what parts I care about).
it seems to work moderately well for game-scripting tasks, without the same level of funkiness as Lua or Python (I more prefer an at least vaguely C/Java/C# style syntax, even if the language still has its share of funkiness, and the controversy over whether to the use JS/AS or Java/C# style declaration syntax, ...).
theoretically, I guess it would be a more direct competitor with Lua or similar though.
security is a potential worry case (yet to be adequately addressed IMO), mostly to hopefully be able to prevent malicious content to be spread to/from servers and/or exploit client computers.
these would be sort of like macro-viruses in MS Word or similar...
>>> C# is a pretty good language. >>> >> >> in general, yes, it is ok. >> >> its main selling points IMO are its reasonably fast compile times and >> ease of quickly throwing together GUIs in WinForms, ... > > WinForms was supplemented with a slight taste of replaced with > WPF 7 years ago. >
well, yes, but a person can choose whether they want to use WinForms or WPF (at least in my version of Visual Studio, it gives both options in the "New Project" box, along with "Console Application", ...).
>>>>> 90% of developer productivity is achieved by adept and informed use of
>>>>> what other people have written: libraries.
>>>>> >>>> >>>> potentially, but if a person can choose freely, all the major language >>>> options have libraries. not necessarily all the same libraries, but >>>> libraries none-the-less... >>> >>> Maybe in the SE space, but not in the EE space. >>> >> >> AFAIK, Java EE costs money though, and I somehow suspect probably most >> end-users have Java SE installed. > > No - Java EE does not necessarily cost money. JBoss, Tomcat etc. can be > used for free. > > Java EE is server side. Client side will typical be browser, but can in > theory also be a Java SE desktop app or a .NET/native desktop app. >
ok.
I had thought Java EE had been like some sort of bigger money-costing version of Java SE (with more libraries and stuff).
granted, I had never really looked much into it.
>> but, in any case, with the other languages there are a wide range of >> libraries available, many under fairly open licenses (like MIT or BSD), >> and there is a lot more GPL stuff available, > > In the EE space you would need to look at CORBA or DCOM. > > You would prefer Java EE believe me. > > :-) >
errm, so you can't just copy all the files over to ones' servers? and/or recompile the code for ones' servers?...
granted, dunno much about business systems, but I was under the understanding that most were some combination of:
rack mounts running Linux, typically with x86 CPUs, and with Gigabit Ethernet or 10GbE or similar linking them all together.
one or more server computers in a desktop-like form factor, sometimes with multi-CPU boards, Xeon or Opteron chips, and craploads of RAM installed, and sometimes also in a LAN. AFAIK, Linux is also popular here. (though I guess Windows XP, Windows Vista, and Windows Server, also make an appearance).
something more strange, like IBM mainframes or similar, where everyone uses them via funky multi colored textual interfaces inside of a terminal emulator, ... pretty much everything I have read about them sounds strange.
as for data sharing (between lots of networked servers), I am less sure, I would think maybe something like NFS or SAMBA, but then thinking of it, NFS or Samba might not scale well if the number of servers becomes sufficiently large (like, people would probably want to locally cache files, rather than always doing IO over the network, ...).
I guess alternatively, an option could be a sort of centralized batch-push or batch-pull, where a daemon or similar is used to update all the servers, or something... (say, on a schedule, they pull from a Git or Hg repository or something...).
but, in any case, people have probably figured out all this stuff already.
otherwise, not entirely sure why developing for these would be all that much different than dealing with a normal PC or Linux box. Received on Thu Jan 24 2013 - 23:10:54 CET