Hi guys,
sorry for the off topic, but this looks really nice,
http://www.osnews.com/story/23097/Quake_II_Ported_to_HTML5
Cheers,
Paulo
April Foold Day :
"Thursday, April 1, 2010
GwtQuake: Taking the Web to the Next
Levelhttps://proxify.com/p/011110A1000110/687474703a2f2f74696d6570656469612e626c6f6773706f742e636f6d2f323031302f30342f6777747175616b652d74616b696e672d7765622d746f2d6e6578742d6c6576656c2e68746d6c
Back in November of 2009, Joel Webber and I were at a GWT Summit focused on
improving the Web and UI latency. Someone was giving a presentation on
WebGL, and I saw Joel sitting in the back of the(…)
"
ref:
2010/4/2 Paulo Pinto <paulo.jpinto at gmail.com>> Hi guys,
sorry for the off topic, but this looks really nice,
http://www.osnews.com/story/23097/Quake_II_Ported_to_HTML5
Cheers,
Paulo
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
http://www.osnews.com/permalink?416631
I think it’s real…=)
-ErsinOn Mon, Apr 5, 2010 at 9:00 AM, Ricardo Leite wrote:
April Foold Day :
"Thursday, April 1, 2010
GwtQuake: Taking the Web to the Next Levelhttps://proxify.com/p/011110A1000110/687474703a2f2f74696d6570656469612e626c6f6773706f742e636f6d2f323031302f30342f6777747175616b652d74616b696e672d7765622d746f2d6e6578742d6c6576656c2e68746d6cBack in November of 2009, Joel Webber and I were at a GWT Summit focused on
improving the Web and UI latency. Someone was giving a presentation on
WebGL, and I saw Joel sitting in the back of the(…)"
ref:
http://timepedia.blogspot.com/2010/04/gwtquake-taking-web-to-next-level.html2010/4/2 Paulo Pinto <paulo.jpinto at gmail.com>
Hi guys,
sorry for the off topic, but this looks really nice,
http://www.osnews.com/story/23097/Quake_II_Ported_to_HTML5
Cheers,
Paulo
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
What Digital Revolution? – www.whatdigitalrevolution.com
Thinking critically about digital worlds.
April Foold Day :
[…]http://www.osnews.com/story/23097/Quake_II_Ported_to_HTML5
[…]
Well, I haven’t actually tried it, but it looks pretty serious, and it’s
certainly doable from a technical POV. 
The Q2 engine is very, very efficient, and computers are orders of magnitude
faster than those it was written for. Also, the low level stuff is done in
native code, just like in modern native code games, leaving even more CPU
power to the script code.On Monday 05 April 2010, at 15.00.47, Ricardo Leite wrote:
–
//David Olofson - Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’
Yeah, what’s shocking about this is that its taken so LOOONG! I mean
people were talking about VRML (virtual reality markup language) way
back in 2000. Guys, don’t fool yourself that javascript is actually
doing 3d polygon transformations and so forth. All that work is done
in native code (or in your gfx card) thru what are essentially
"plug-ins". The js says “here is a model, here is a camera, render
that camera onto the screen”. Its equivalent to running the Python
SDL layer, for example.
But that great thing is that these “plug-ins” are no longer plugins.
They are not-quite-yet-standard parts of HTML5 and therefore come with
the browser.
You really have to ask yourself why so few industry standards are
integrated in the browser and instead require the tiresome plugin
process – .pdf, Java, flash, most music formats, etc. After using
your computer for a few years without reinstall its easy to forget how
little the browser actually does all alone.
So this is not so much of a great technical achievement as a great
political one – that is getting all these industry reps to agree to
include a particular technology against the back-pressure of
corporations who still think they can make $ supplying proprietary
data viewers (or advertising around the “free” install process). And
once inclusion of a technology is theoretically agreed upon there is
still the endless committee discussions of format details and so
forth.On Mon, Apr 5, 2010 at 9:43 AM, David Olofson wrote:
On Monday 05 April 2010, at 15.00.47, Ricardo Leite wrote:
April Foold Day :
[…]http://www.osnews.com/story/23097/Quake_II_Ported_to_HTML5
[…]Well, I haven’t actually tried it, but it looks pretty serious, and it’s
certainly doable from a technical POV.The Q2 engine is very, very efficient, and computers are orders of magnitude
faster than those it was written for. Also, the low level stuff is done in
native code, just like in modern native code games, leaving even more CPU
power to the script code.–
//David Olofson - Developer, Artist, Open Source Advocate.— Games, examples, libraries, scripting, sound, music, graphics —.
| ?http://olofson.net ? http://kobodeluxe.com ? http://audiality.org ?|
| ?http://eel.olofson.net ?http://zeespace.net ? http://reologica.se ?|
’---------------------------------------------------------------------’
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
[…]
But that great thing is that these “plug-ins” are no longer plugins.
They are not-quite-yet-standard parts of HTML5 and therefore come with
the browser.
[…]
Now, one could only hope for a few browsers that actually implement more than
half of the spec correctly or at all. If you’ve ever tried getting anything
non-trivial with a few tables and stuff to work right in more than one
browser, you know why people are building entire sites in Flash…!
It seems like the “features before stability” race of the MS/Netscape war era
never really ended.On Monday 05 April 2010, at 16.44.42, Andrew Stone <g.andrew.stone at gmail.com> wrote:
–
//David Olofson - Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’
Andrew Stone wrote:
Guys, don’t fool yourself that javascript is actually
doing 3d polygon transformations and so forth. All that work is done
in native code (or in your gfx card) thru what are essentially
"plug-ins". The js says “here is a model, here is a camera, render
that camera onto the screen”. Its equivalent to running the Python
SDL layer, for example.
However, reading
it sounds as though the Q2 port is making Javascript work
pretty hard.
Q2 was written using a small subset of the OpenGL 1.1
functionality, before vertex buffers, vertex shaders, etc.
Plus, the relatively brute-force translation from
C -> Java -> Javascript…
So they’re estimating they could get a 2x speedup if the
game were written for modern OpenGL API’s, and with
Javascript efficiency in mind.
Very cool, though!
(It’s weird picturing Javascript performing the box-traces
through the BSP tree for the collision detection…
Regards,
Bill
So they’re estimating they could get a 2x speedup if the
game were written for modern OpenGL API’s, and with
Javascript efficiency in mind.Very cool, though!
I’m sure it’s running a lot of processing in JavaScript, including:
Model animation
Q2 BSP rendering (visibility decompression, BSP recursion, issuing draw calls to OpenGL).
Dynamic lightmap updates (including rendering dynamic lights into the lightmaps on the fly).
Collision detection
AI
It’s the whole game…
It’s pretty scary thinking about it
(It’s weird picturing Javascript performing the box-traces
through the BSP tree for the collision detection…
Yeah. :)On 04/05/2010 01:01 PM, Bill Kelly wrote:
–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier
[…Q2 in JavaScript…]
It’s pretty scary thinking about it
To put things in perspective, I just benchmarked my EEL scripting engine
(similar to Lua in VM design and performance), and concluded that the VM does
somewhere around 80 MIPS on one of my 3 GHz cores.
Yeah, that’s 80 million high level VM instructions per second, in a dynamic
typed, memory managed environment with “smart” datatypes. No JIT or anything;
just a “computed goto” dispatcher. (At best 20% faster than switch().)
Quite enough for some serious real time polyphonic sound synthesis all in
unoptimized script code…!
So, even if JavaScript implementations tend to be extremely slow compared to
this, one can still get a lot of data shuffled.
Well… It wasn’t all that long ago one would have traded one’s soul for 80
MIPS of RISC power. I even left the Amiga for PC! :-DOn Tuesday 06 April 2010, at 00.49.25, Forest Hale wrote:
–
//David Olofson - Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’
And it is exactly because of this, that many studios are leaving C/C++ to
the very kernel of the games engine,
and doing everything else in higher level languages. In some years, maybe
even the kernel of the games engines
will be written in higher level languages.
Everyone would like to be writing the next Crysis, but only few do. For many
types of games you don’t need
the low level access given by C, C++ or assembly languages.On Tue, Apr 6, 2010 at 2:39 AM, David Olofson wrote:
On Tuesday 06 April 2010, at 00.49.25, Forest Hale wrote:
[…Q2 in JavaScript…]It’s pretty scary thinking about it
To put things in perspective, I just benchmarked my EEL scripting engine
(similar to Lua in VM design and performance), and concluded that the VM
does
somewhere around 80 MIPS on one of my 3 GHz cores.Yeah, that’s 80 million high level VM instructions per second, in a dynamic
typed, memory managed environment with “smart” datatypes. No JIT or
anything;
just a “computed goto” dispatcher. (At best 20% faster than switch().)Quite enough for some serious real time polyphonic sound synthesis all in
unoptimized script code…!So, even if JavaScript implementations tend to be extremely slow compared
to
this, one can still get a lot of data shuffled.Well… It wasn’t all that long ago one would have traded one’s soul for 80
MIPS of RISC power. I even left the Amiga for PC!–
//David Olofson - Developer, Artist, Open Source Advocate.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
And it is exactly because of this, that many studios are leaving C/C++ to
the very kernel of the games engine,
and doing everything else in higher level languages. In some years, maybe
even the kernel of the games engines
will be written in higher level languages.
Well, yes, there is more code that is less performance critical - but a higher
level language doesn’t have to be slow! Anything that fits the problem
domain and has a properly optimizing compiler and/or JIT could actually be
faster than C or C++ in real applications. Theoretically, this shouldn’t
happen, but in real life, it doesn’t make sense to optimize our algorithms and
datatypes as much when we have to handcode most of them on the application
level - so even a “slow” language can beat us with it’s optimized smart
datatypes and “clever algorithm enabling” language features.
Also, more raw power makes it more viable to compile and optimize when
starting the game or loading levels, which means we can tune and tweak
specifically for the target and configuration at hand. Higher level languages,
which are less obsessive about low level details, are probably better suited
for this.
Everyone would like to be writing the next Crysis, but only few do. For
many types of games you don’t need the low level access given by C, C++ or
assembly languages.
Indeed. Given a reasonably fast scripting language with bindings to OpenGL,
OpenAL, some physics engine etc, one can implement pretty much anything these
days. Throw in vertex and pixel shaders, and we can do really serious stuff -
but then again, shader code is low level coding all over again. ;-)On Tuesday 06 April 2010, at 08.29.11, Paulo Pinto wrote:
–
//David Olofson - Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’
I concur that speed is important in high level languages.
That said, I’ve been working on my Quake1 engine DarkPlaces since 2000, and it still runs the same language (QuakeC) for its game logic, which is one of the fastest available, and completely suited to
JIT if I ever choose to implement such (after Mac OS X migrated to x86/x86_64 this became even more appealing).
The only really essential thing in a VM design is that you must have type-specific instructions in the underlying bytecode (in other words, an int add instruction rather than merely an add function
call on a polymorphic object that may just happen to be an int), it’s the main deciding factor in suitability to JIT compilation and fast interpretation without JIT as well.
What worries me about languages like lua is that they use polymorphic objects for all variables, which inherently makes them hard to JIT - there is a luajit project but it has to inline large amounts
of functions to have a good chance of recognizing variable types and turning operators into explicitly-typed operators, necessary for fast interpretation or JIT.
There’s never a good reason to make something slow, especially if it is a core element like a virtual machine for a scripting language, which might be running much heavier code than you ever dreamed
of, especially considering how easy it is to make things fast.On 04/06/2010 02:43 AM, David Olofson wrote:
On Tuesday 06 April 2010, at 08.29.11, Paulo Pinto wrote:
And it is exactly because of this, that many studios are leaving C/C++ to
the very kernel of the games engine,
and doing everything else in higher level languages. In some years, maybe
even the kernel of the games engines
will be written in higher level languages.Well, yes, there is more code that is less performance critical - but a higher
level language doesn’t have to be slow! Anything that fits the problem
domain and has a properly optimizing compiler and/or JIT could actually be
faster than C or C++ in real applications. Theoretically, this shouldn’t
happen, but in real life, it doesn’t make sense to optimize our algorithms and
datatypes as much when we have to handcode most of them on the application
level - so even a “slow” language can beat us with it’s optimized smart
datatypes and “clever algorithm enabling” language features.Also, more raw power makes it more viable to compile and optimize when
starting the game or loading levels, which means we can tune and tweak
specifically for the target and configuration at hand. Higher level languages,
which are less obsessive about low level details, are probably better suited
for this.Everyone would like to be writing the next Crysis, but only few do. For
many types of games you don’t need the low level access given by C, C++ or
assembly languages.Indeed. Given a reasonably fast scripting language with bindings to OpenGL,
OpenAL, some physics engine etc, one can implement pretty much anything these
days. Throw in vertex and pixel shaders, and we can do really serious stuff -
but then again, shader code is low level coding all over again.
–
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier
And it is exactly because of this, that many studios are leaving C/C++
to the very kernel of the games engine,
and doing everything else in higher level languages. In some years,
maybe even the kernel of the games engines
will be written in higher level languages.
My understanding is that game studios use higher level languages in some
places to make their iterations faster so they can experiment with a lot
of scenarios and decide what’s best to keep in the final game. If some
high level code becomes a processor bottleneck it will be replaced
with C/C++ code.
Imagine how games will look like 10 years in the future. If you want to
make those games you will be coding in C/C++/Asm. Game engines in
higher level languages will be just a toy, just like Quake II in HTML 5.
So yeah, maybe we’ll play a port of Crysis in HTML 5 in the future but
by that time it will look so last decade…
Everyone would like to be writing the next Crysis, but only few do.
For many types of games you don’t need
the low level access given by C, C++ or assembly languages.
True, but even in the casual games industry where you don’t have to
count machine cycles the engines are written in C/C++. And casual games
are becoming more and more processor intensive with all graphic effects
so I doubt that high level languages will be used in them besides to
drive the low level engine.
Cheers,
AndreOn 06/04/2010 03:29, Paulo Pinto wrote:
On Tue, Apr 6, 2010 at 2:39 AM, David Olofson <david at olofson.net <mailto:david at olofson.net>> wrote:
On Tuesday 06 April 2010, at 00.49.25, Forest Hale <havoc at ghdigital.com <mailto:havoc at ghdigital.com>> wrote: [...Q2 in JavaScript...] > It's pretty scary thinking about it :) To put things in perspective, I just benchmarked my EEL scripting engine (similar to Lua in VM design and performance), and concluded that the VM does somewhere around 80 MIPS on one of my 3 GHz cores. Yeah, that's 80 million high level VM instructions per second, in a dynamic typed, memory managed environment with "smart" datatypes. No JIT or anything; just a "computed goto" dispatcher. (At best 20% faster than switch().) Quite enough for some serious real time polyphonic sound synthesis all in unoptimized script code...! :-) So, even if JavaScript implementations tend to be extremely slow compared to this, one can still get a lot of data shuffled. Well... It wasn't all that long ago one would have traded one's soul for 80 MIPS of RISC power. I even left the Amiga for PC! :-D -- //David Olofson - Developer, Artist, Open Source Advocate .--- Games, examples, libraries, scripting, sound, music, graphics ---. | http://olofson.net http://kobodeluxe.com http://audiality.org | | http://eel.olofson.net http://zeespace.net http://reologica.se | '---------------------------------------------------------------------' _______________________________________________ SDL mailing list SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
What worries me about languages like lua is that they use polymorphic objects for all variables, which inherently makes them hard to JIT - there is a luajit project but it has to inline large amounts
of functions to have a good chance of recognizing variable types and turning operators into explicitly-typed operators, necessary for fast interpretation or JIT.There’s never a good reason to make something slow, especially if it is a core element like a virtual machine for a scripting language, which might be running much heavier code than you ever dreamed
of, especially considering how easy it is to make things fast.
Please remember that Lua’s main goal isn’t to be fast. It was created as
a configuration language. The reason it’s widely used in the game
industry is because it’s very easy to embed, to extend, to interface
with native code, to learn and because it’s actually fast, but this is a
niche Lua’s authors never dreamed of when they created the language.
Andre> On 04/06/2010 02:43 AM, David Olofson wrote:
On Tuesday 06 April 2010, at 08.29.11, Paulo Pinto wrote:
And it is exactly because of this, that many studios are leaving C/C++ to
the very kernel of the games engine,
and doing everything else in higher level languages. In some years, maybe
even the kernel of the games engines
will be written in higher level languages.Well, yes, there is more code that is less performance critical - but a higher
level language doesn’t have to be slow! Anything that fits the problem
domain and has a properly optimizing compiler and/or JIT could actually be
faster than C or C++ in real applications. Theoretically, this shouldn’t
happen, but in real life, it doesn’t make sense to optimize our algorithms and
datatypes as much when we have to handcode most of them on the application
level - so even a “slow” language can beat us with it’s optimized smart
datatypes and “clever algorithm enabling” language features.Also, more raw power makes it more viable to compile and optimize when
starting the game or loading levels, which means we can tune and tweak
specifically for the target and configuration at hand. Higher level languages,
which are less obsessive about low level details, are probably better suited
for this.Everyone would like to be writing the next Crysis, but only few do. For
many types of games you don’t need the low level access given by C, C++ or
assembly languages.Indeed. Given a reasonably fast scripting language with bindings to OpenGL,
OpenAL, some physics engine etc, one can implement pretty much anything these
days. Throw in vertex and pixel shaders, and we can do really serious stuff -
but then again, shader code is low level coding all over again.
Everyone would like to be writing the next Crysis, but only few do. For
many types of games you don’t need
the low level access given by C, C++ or assembly languages.True, but even in the casual games industry where you don’t have to count
machine cycles the engines are written in C/C++. And casual games are
becoming more and more processor intensive with all graphic effects so I
doubt that high level languages will be used in them besides to drive the
low level engine.Cheers,
Andre
That is happening already:
- Do you want to target Zune devices, Windows 7 mobiles or Creators Club in
XBox 360? XNA. - Do you want to develop games for the PSN Home? LUA
- Do you want to develop games for Android, Blackberry, Blue Ray players,
millions of mobile handsets out there? Java - Do you want to use the Unity games engine? .Net
- Do you wan to use the latest version of the Unreal SDK? The new tools are
WPF based (http://www.gamedev.net/columns/events/gdc2010/article.asp?id=1822
) - …
You see, the games industry moves very slowly in comparison with other
computing related industries, but it also moves.
Sure C/C++/Asm are not going away, but the amount of their usage inside a
game is decreasing. I am old enough to remember the same type of discussion
about C and Asm. In those days people would use C to prototype, but real
games would only use Asm (sounds familiar?).
Me, I don’t really care. What is important is that the game is fun to play,
regardless how it was made.On Wed, Apr 7, 2010 at 4:22 AM, Andre Leiradella < aleirade at sct.microlink.com.br> wrote:
–
Paulo
[…]
What worries me about languages like lua is that they use polymorphic
objects for all variables, which inherently makes them hard to JIT - there
is a luajit project but it has to inline large amounts of functions to
have a good chance of recognizing variable types and turning operators
into explicitly-typed operators, necessary for fast interpretation or JIT.There’s never a good reason to make something slow, especially if it is a
core element like a virtual machine for a scripting language, which might
be running much heavier code than you ever dreamed of, especially
considering how easy it is to make things fast.
Indeed, dynamic typing has performance issues, but it’s one of those features
one expects to find in a true high level language. Basically, if you don’t
need features like that, but you do need high raw performance, these languages
are not the right tools for the job! (And, as long as you’re using a non-JIT
VM, instruction decoding seems to be The performance bottleneck anyway…)
That said, I have the same Lua style “all variables dynamically typed” design
in EEL, and so far, my experience is that although it’s very handy in some
cases (like API design), actual code tends to either rely on values being of
specific or functionally similar types (ie “integer/real” or “indexable
container”), or explicit runtime typechecks are used for deciding what to do.
When it comes to actual work, true polymorphism is rare.
Maybe it’s just EEL and my programming style that needs to evolve a bit?
Either way, I’m planning on adding static typing eventually, not only for raw
performance (it’s quite fast enough for what I do already), but also for the
added compile time type checking potential. Catching lots of bugs right in the
compiler is a nice thing, and I want more of that in EEL! :-)On Wednesday 07 April 2010, at 02.28.41, Forest Hale wrote:
–
//David Olofson - Developer, Artist, Open Source Advocate
.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://olofson.net http://kobodeluxe.com http://audiality.org |
| http://eel.olofson.net http://zeespace.net http://reologica.se |
’---------------------------------------------------------------------’
That said, I have the same Lua style “all variables dynamically typed” design
in EEL, and so far, my experience is that although it’s very handy in some
cases (like API design), actual code tends to either rely on values being of
specific or functionally similar types (ie “integer/real” or “indexable
container”), or explicit runtime typechecks are used for deciding what to do.
When it comes to actual work, true polymorphism is rare.Maybe it’s just EEL and my programming style that needs to evolve a bit?
Congratulations, you just discovered dynamic typing’s dirty little secret.
It looks really cool in a demo, but it turns out real code hardly uses it at all.
Data has a type and tends to stay that type far more often than not, so
why not formalize that and gain the benefits of compile-time type checking
and static analysis tools?
Dynamic typing has its uses, especially when anything resembling
serialization is involved, but it’s not such a good idea to base your entire
program around it. I once heard someone say “static whenever possible,
dynamic when necessary.” I like that principle.>----- Original Message ----
From: David Olofson
Subject: Re: [SDL] Off-Topic: Quake II Ported to HTML5
It has Anders Hejlsberg who said that, two years ago when Microsoft was
presenting the dynamic
capabilities of C# 4.0 at the Microsoft PDC.On Wed, Apr 7, 2010 at 2:04 PM, Mason Wheeler wrote:
----- Original Message ----
From: David Olofson
Subject: Re: [SDL] Off-Topic: Quake II Ported to HTML5That said, I have the same Lua style "all variables dynamically typed"
design
in EEL, and so far, my experience is that although it’s very handy in some
cases (like API design), actual code tends to either rely on values being
of
specific or functionally similar types (ie “integer/real” or “indexable
container”), or explicit runtime typechecks are used for deciding what to
do.
When it comes to actual work, true polymorphism is rare.Maybe it’s just EEL and my programming style that needs to evolve a bit?
Congratulations, you just discovered dynamic typing’s dirty little secret.
It looks really cool in a demo, but it turns out real code hardly uses it
at all.
Data has a type and tends to stay that type far more often than not, so
why not formalize that and gain the benefits of compile-time type checking
and static analysis tools?Dynamic typing has its uses, especially when anything resembling
serialization is involved, but it’s not such a good idea to base your
entire
program around it. I once heard someone say “static whenever possible,
dynamic when necessary.” I like that principle.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Makes sense. He’s the one who created the early versions of Delphi, which took Microsoft’s dynamic Variant type and integrated it seamlessly into the existing static type system. (You can assign back and forth between a Variant and static types such as integers or strings, and the compiler takes care of generating the calls to the runtime assignment and conversion functions.) And then 10 years later, C# finally catches up to what Delphi was able to do back in the 90s. :P________________________________
From: pjmlp@progtools.org (Paulo Pinto)
Subject: Re: [SDL] Off-Topic: Quake II Ported to HTML5
It has Anders Hejlsberg who said that, two years ago when Microsoft was presenting the dynamic
capabilities of C# 4.0 at the Microsoft PDC.
On Wed, Apr 7, 2010 at 2:04 PM, Mason Wheeler <@Mason_Wheeler> wrote:
----- Original Message ----
From: David Olofson
Subject: Re: [SDL] Off-Topic: Quake II Ported to HTML5That said, I have the same Lua style “all variables dynamically typed” design
in EEL, and so far, my experience is that although it’s very handy in some
cases (like API design), actual code tends to either rely on values being of
specific or functionally similar types (ie “integer/real” or “indexable
container”), or explicit runtime typechecks are used for deciding what to do.
When it comes to actual work, true polymorphism is rare.Maybe it’s just EEL and my programming style that needs to evolve a bit?
Congratulations, you just discovered dynamic typing’s dirty little secret.
It looks really cool in a demo, but it turns out real code hardly uses it at all.
Data has a type and tends to stay that type far more often than not, so
why not formalize that and gain the benefits of compile-time type checking
and static analysis tools?Dynamic typing has its uses, especially when anything resembling
serialization is involved, but it’s not such a good idea to base your entire
program around it. I once heard someone say “static whenever possible,
dynamic when necessary.” I like that principle.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I can’t wait until inferred typing becomes more popular in mainstream
languages. I mean useful inferred typing, where maybe 10% of the code
has explicit type signatures and the compiler deduces the rest from
use, not like the “var” keyword C# (though I don’t know if they’ve
extended this in more recent updates to the language).