scripting

Phlip ecrivit le 25/01/2005 22:20 :

>>>Now show me block closures ;-)
>>
>>http://groovy.codehaus.org/Closures
>
>
> Thank me for not requesting templates.
>
> http://some.college/.../pizza
>
> Templates are a bandaid for the loss of ability to treat a class as an
> object. With that ability, you pass class names as objects into methods
>
> So we'd be back to dynamic typing strapped-on to Java. Regardless of any
> "lipstick on the pig" issues, I have always speculated that dynamic and
> static typing should be program-time decisions, not built into the language.
> Going from dynamic to static might be easier, and the other way more
> efficient.
>
> Which leads us back to game development's fetish for efficiency. Yes, you
> can squeeze Java to make it faster.

I just wanted to point out that java is a very viable alternative for
scripting. Vampire, the Masquerade used it.
(http://www.gamasutra.com/features/19990611/java_13.htm)

Also, Chrome is written in Java. (http://chromethegame.com/en/show.php)

> But has anyone, anywhere, put Java inside a PS2 or Xbox?

I saw Linux on PS2 so why not a JVM ? Isn't there JVMs on mobiles
thanks to MIDP ?

Wismerhill ecrivit le 26/01/2005 10:23 :

> Also, Chrome is written in Java. (http://chromethegame.com/en/show.php)

Doh! Chrome * logic * is written in Java.
(http://www.chromethegame.com/en/show.php?015)

>> But has anyone, anywhere, put Java inside a PS2 or Xbox?

They plan to release Chrome on XBox.

In article <41f76150$0$25755$626a14ce@news.free.fr>,
Wismerhill <wis@NOSPAMchez.comNOSPAM> wrote:
>I just wanted to point out that java is a very viable alternative for
>scripting. Vampire, the Masquerade used it.
>(http://www.gamasutra.com/features/19990611/java_13.htm)

That's just one title, never ported to consoles, and the sequel to
it seems to have ditched Java. However, scripting languages like Lua
have been used in dozens of games, on consoles and PCs. Why? They're
much more lightweight, and their overriding mentality behind the
design is that they do as much work as you want. In short, they say
"You want to use us? Great. You don't want to use us? No sweat."

Other languages like Java and Lisp (and especially their
proponents) have a huge chip on their shoulder, and say "you are an
complete and utter fool if you consider using anything other than
OurOneTruePureLanguage(tm)." Guess which attitude works better when
people are *considering* adding that language? When Lua is used in
dozens of commercial games, and Java isn't, that's empirical evidence
that they're doing something better. I've presented my theories as
to why.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein

On Tue, 25 Jan 2005, Phlip wrote:

> Wismerhill wrote:
>
>>> Now show me block closures ;-)
>>
>> http://groovy.codehaus.org/Closures
>
> Thank me for not requesting templates.
>
> http://some.college/.../pizza
>
> Templates are a bandaid for the loss of ability to treat a class as an
> object. With that ability, you pass class names as objects into methods
>

No, they are not. Any time something offers static properties, it is not
merely a bandaid for a feature that doesn't - it's effectively a test for
free. Languages with no static semantics are naturally going to be simpler
(try Self - it's almost as compact as the lambda calculus) for a given set
of dynamic (run-time, if you will) capabilities, but that doesn't make the
distinctions necessary for good static semantics mere patches for not
doing it the same way.

> So we'd be back to dynamic typing strapped-on to Java. Regardless of any
> "lipstick on the pig" issues, I have always speculated that dynamic and
> static typing should be program-time decisions, not built into the language.
> Going from dynamic to static might be easier, and the other way more
> efficient.
>

Dynamic to static makes it a collosal pain in the arse to work out what's
going on, doubly so if the type system wasn't designed with effective
static typing in mind. Being able to constrain dynamic types to a certain
range is also useful.

You're right that bolting dynamic types on top of a static system allows
more efficiency though, you can throw away the unneeded run-time type
info.

--
flippa@flippac.org

"My religion says so" explains your beliefs. But it doesn't explain
why I should hold them as well, let alone be restricted by them.

Wismerhill <wis@NOSPAMchez.comNOSPAM> wrote in
news:41f76150$0$25755$626a14ce@news.free.fr:


>> But has anyone, anywhere, put Java inside a PS2 or Xbox?
>
> I saw Linux on PS2 so why not a JVM ? Isn't there JVMs on
> mobiles thanks to MIDP ?

PS2 has 32 MB RAM. While current JVM works on computers with 32 MB
RAM and swap, it should be highly optimalized for PS2. I would be
more happy with converter between Java programs and PS2 executable
images (with some restrictions like no dynamic class loading) It
doesn't look like Sony would do it anytime soon withou being
severally blackmailed.

Xbox is easy. Do you have any stable driver for it? (prefferably in
BSD licence) You could static compile Java for it by JET, or GJC,
then you just need to get a library to link with Xbox graphic
drivers and input devices. Dunno if Xbox could (with possibly some
hacking) run current 1.4.2 Sun/IBM JVM.

How many JVMs would be on PS3? Thats a question. IBM could hide
sometype of hardware JVM for internal work. First version of
console that would be interesting to create JVM for would be PS3,
so it might be the first console with dual JVM.

Of course I'm not interested in consoles. The target platform
(recommended) for my current game is the Earth simulator (they
don't know about it). So I'm more interested in computers with at
least 2 GB RAM (with swap).
xxx could run on PS2 without problem even with JVM JITing in a
memory.


Then again it seems that some persons are forgeting an one of
Java's purposes. To be transferable to different platforms. How it
would run on that platforms is problem of platform's manufacturer.
Consoles are platform with "fixed" hardware. (actually much more
fixed than cell phones) This means there is no problem with
generation of statical executable on different platform (possibly
with crossplatform code included), and be without problem with JIT.
Computers aren't as nice so JVM is reasonably nice guard between OS
and program to disalow any bad behaviour and possiblity to
recompile for AMD 64, or for dual core CPU after a few years is
very nice. Actually yes consoles could have use for JIT as well, if
they would have harddrives. You'd push inside blue ray old CD with
PSX game, then start a small program it would look towards some
library, recompile it for a PS3, and add a nice SAI and other
effects into result. It's significantly easier when you have
something like CASM, or bytecode avilable for crossrefferencing
with original executable.
Of course we have computers, and EPSXE so why worry about it.
Right?

(how you would do roll eyes as anime smillie?)

p@yahoo.com wrote:
> cr88192 wrote:
> > mind you, I am personally under the impression that haskell's learning
> cure
> > is a bit high for a scripting lang.
> Scripting language != designer's interface.
> We need to give designers a clean, high-level interface that allows them to
> focus on their job.
> I suspect that the best scripting system is one with a language that allows
> _programmers_ to then create such an interface. Then programmers respond to
> cruft written by designers, and refactor that under the interface, extending
> its abilities.
> In this model (which, so far, is only imaginary), it seems that designers
> never cut a class, hence the scripting language's learning curve is less
> important.
> Haskell might be the exception ;-)
> > mind you, the typical user doesn't want to need to "understand" the
> > language, but more likely copy and paste fragments, and edit others, and
> > hope for it to work.
> And that's why programmers attend to this code at all times, and don't allow
> designers to have their way with it.
> --
> Phlip
> http://industrialxp.org/community/bi...UserInterfaces

Great!

leslie_johnson@forums.duskmail.com