headers
Brandon Van Every | 1 Jan 2008 04:03
Picon

Re: Towards a better meta-programming language

On Dec 31, 2007 5:33 PM, Robert Blum <r.blum <at> gmx.net> wrote:
> >  How many competing
> > products for "boutique" languages do you think there are?  Where are
> > all the Haskell implementations vying for maximum performance?
>
> There are at the very least Glasgow Haskell, York Haskell, Chalmers
> Haskell-B, JHC.

You wanna give people a rundown on which of these is fast?

>
> >  Heck,
> > even things like Python and Ruby typically have 1 implementation
>
> Hardly. RubyCompiler,  Ruby.NET Compiler, JRuby, Rubinius, Jython,
> Py2c, PyPy, IronPython are just the ones that immediately come to mind.
>
>
> > that everyone actually uses,

Clipping mid-sentence is disingenuous.

> > and a handful of "it'll be faster someday"
> > implementations that some hacker is working on, but that never
> > actually get any traction.
>
> Sun sponsors *at least* two competing Ruby implementations. (JRuby and
> Rubinius). Hardly "never get any traction".

Which one is fast?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Plunket | 1 Jan 2008 11:19

Re: Towards a better meta-programming language

Brandon Van Every wrote:

> > > So use PCRE if build performance is so important.  What's the problem?
> >
> > Q: When did regular expressions become the solution to every problem?
> > A: When Brandon discovered them.
> 
> Non-sequitor.  In this context, the complaint was not about regexes,
> but the slowness of scripts.

Actually, I think Jon's point was opening and reading every file N times
to do a build was the slow part.  Not the "doing the work" part.

> I get really... bored... listening to people make excuses why they
> can't take action, when imperfect but off-the-shelf tools are
> available to do the job, and have been around for a long time.  I'm
> all for better tools than regexes.  I've heard precious few
> suggestions.

It's not about imperfect tools, it's about the right tool for the job,
no?  I mean, if the tool doesn't even do the thing you need it to do (in
this case, pattern matching was never even mentioned 'til you brought it
up), then it doesn't really matter how amazing it is.

> > TopTip: Regular expressions are good for pattern matching, but not so
> > good for code generation.
> 
> Only if you insist on complicating your life with as much excruciating
> C++ minutiae as possible.  If you're doing something relatively
> simple, like translating Autoconf + GMake to CMake...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Plunket | 1 Jan 2008 11:26

Re: Towards a better meta-programming language

Jon Watte wrote:

> What you're thinking is not much different from a #include that takes a 
> shell command string as argument.

...and at that point, why not get away from trying to parse C++ at all,
and trying to dig into the compiler, etc., etc., and just define some
other source for the file?

E.g. why not define the data you want serializable in an XML file, for
instance, and "build" that file with XSLT or something along those
lines?

So instead of

class Example { int foo; };

import "tool.exe"(Example)

or whatever...  do:

<class name="Example">
   <member name="foo" type="int">
</class>

-tom!

--

-- 
_______________________________________________
Sweng-Gamedev mailing list
(Continue reading)

Permalink | Reply | 13 comments |
headers
Mat Noguchi | 1 Jan 2008 17:22

Re: Towards a better meta-programming language

Replace junior programmer with non-systems programmer and all is well.

MSN

-----Original Message-----
From: sweng-gamedev-bounces <at> lists.midnightryder.com
[mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of James Robertson
Sent: Monday, December 31, 2007 2:13 AM
To: sweng-gamedev <at> midnightryder.com
Subject: Re: [Sweng-Gamedev] Towards a better meta-programming language

Or maybe you're just a better coder in Python than the other guy is in C.
(That sort of tool sounds like exactly the sort of thing that would be given
to a junior programmer - something small and isolated that they can cut
their teeth on.)

----- Original Message -----
From: "Tom Plunket" <gamedev <at> fancy.org>
To: <sweng-gamedev <at> midnightryder.com>
Sent: Monday, December 31, 2007 8:33 AM
Subject: Re: [Sweng-Gamedev] Towards a better meta-programming language

> Joris Mans wrote:
>
>> Which of those would be best suited to not be written in C++? I think
>> from
>> an ease-of-programming point of view, all. Unfortunatly from a
>> performance
>> point of view I guess that the scripts are the only good candidates
>> because
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mat Noguchi | 1 Jan 2008 17:58

Re: Towards a better meta-programming language

There is a significant difference between not taking action and trying to devise the "right" solution.

In this discussion, "right" is having a stable build process that can be replicated *reliably* across an
entire studio. It has very little to do with whether it is possible to do it right now.

MSN
-----Original Message-----
From: sweng-gamedev-bounces <at> lists.midnightryder.com
[mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of Brandon Van Every
Sent: Monday, December 31, 2007 2:49 AM
To: sweng-gamedev <at> midnightryder.com
Subject: Re: [Sweng-Gamedev] Towards a better meta-programming language

On Dec 31, 2007 3:19 AM, Tom Plunket <gamedev <at> fancy.org> wrote:
> Brandon Van Every wrote:
>
> > So use PCRE if build performance is so important.  What's the problem?
>
> Q: When did regular expressions become the solution to every problem?
> A: When Brandon discovered them.

Non-sequitor.  In this context, the complaint was not about regexes,
but the slowness of scripts.

I get really... bored... listening to people make excuses why they
can't take action, when imperfect but off-the-shelf tools are
available to do the job, and have been around for a long time.  I'm
all for better tools than regexes.  I've heard precious few
suggestions.  My point is, if you can't actually think of anything
better, then just get on with what's readily available.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mat Noguchi | 1 Jan 2008 18:04

XML is ugly, was RE: Towards a better meta-programming language

Ugh, XML is not readable, no matter what anyone says to the contrary.

http://www.secretgeek.net/ixml.asp

Hell, just making the <tag/> construct optional would make it more palatable.

Blah blah blah, you can make a UI on top of it, blah blah blah, XML doesn't easily scale when you crap out really
huge files.

MSN
-----Original Message-----
From: sweng-gamedev-bounces <at> lists.midnightryder.com
[mailto:sweng-gamedev-bounces <at> lists.midnightryder.com] On Behalf Of Tom Plunket
Sent: Tuesday, January 01, 2008 2:27 AM
To: sweng-gamedev <at> midnightryder.com
Subject: Re: [Sweng-Gamedev] Towards a better meta-programming language

Jon Watte wrote:

> What you're thinking is not much different from a #include that takes a
> shell command string as argument.

...and at that point, why not get away from trying to parse C++ at all,
and trying to dig into the compiler, etc., etc., and just define some
other source for the file?

E.g. why not define the data you want serializable in an XML file, for
instance, and "build" that file with XSLT or something along those
lines?
(Continue reading)

Permalink | Reply | 12 comments |
headers
Jack Palevich | 1 Jan 2008 18:37
Picon
Favicon

Re: XML is ugly, was RE: Towards a better meta-programming language

When XML was being developed Microsoft proposed making the close-tag
optional (they introduced  "</>" as the universal close tag), but the
XML style gods rejected the proposal because it makes it more
difficult for "desperate Perl hackers" to use regular expressions to
parse XML.

Even the web world, where XML originated, has people who prefer not to
use it. There's a popular alternative called JSON (JavaScript Object
Notation). It is much cleaner and more C-like than XML. It's not quite
as clean as LISP S-expressions, but it has the advantage of being
syntactically correct JavaScript, so it's especially easy to use from
JavaScript.

http://www.json.org/

An example of JSON:

{
  "player": {
    name: "joe",
    position: {
      x: 100.0,
      y: 200.0
    }
}

On Jan 1, 2008 9:04 AM, Mat Noguchi <matthewn <at> bungie.com> wrote:
> Ugh, XML is not readable, no matter what anyone says to the contrary.
>
> http://www.secretgeek.net/ixml.asp
(Continue reading)

Permalink | Reply | 9 comments |
headers
Jack Palevich | 1 Jan 2008 18:41
Picon
Favicon

Re: XML is ugly, was RE: Towards a better meta-programming language

Gah, the JSON example got munched. Here's another try:

{
 "player": {
   "name": "joe",
   "position": {
     "x": 100.0,
     "y": 200.0
    }
}

Note that in S-expressions this would be even simpler:

(player
  (name "joe")
  (position
    (x 100.0)
    (y 200.0)))

On Jan 1, 2008 9:37 AM, Jack Palevich <jackpal <at> google.com> wrote:
> When XML was being developed Microsoft proposed making the close-tag
> optional (they introduced  "</>" as the universal close tag), but the
> XML style gods rejected the proposal because it makes it more
> difficult for "desperate Perl hackers" to use regular expressions to
> parse XML.
>
> Even the web world, where XML originated, has people who prefer not to
> use it. There's a popular alternative called JSON (JavaScript Object
> Notation). It is much cleaner and more C-like than XML. It's not quite
> as clean as LISP S-expressions, but it has the advantage of being
(Continue reading)

Permalink | Reply | 8 comments |
headers
Joshua Jensen | 1 Jan 2008 18:44

Re: XML is ugly, was RE: Towards a better meta-programming language

----- Original Message -----
From: Mat Noguchi
Date: 1/1/2008 10:04 AM
> Ugh, XML is not readable, no matter what anyone says to the contrary.
>
> http://www.secretgeek.net/ixml.asp
>
> Hell, just making the <tag/> construct optional would make it more palatable.
>
> Blah blah blah, you can make a UI on top of it, blah blah blah, XML doesn't easily scale when you crap out
really huge files.
>   
I have used Lua for nearly all of my data file formats for over 10 years 
now.

Advantages (in no particular order):

    * I find it much easier to human read and write than XML.
    * It is easy to parse, either through Lua's parser or through a 
custom parser.
    * It has a binary format.
    * It represents hierarchies through tables.
    * It can represent binary data, strings, and numbers.
    * It preparses things such as numbers so the data type is known.  
Contrast this with XML where everything is a string, and you end up 
custom parsing its strings into the data type the code asks for and not 
what the file format creator provided.  In Lua: "3.141592" is not the 
same as 3.141592.
    * The API for reading the data is consistent on all platforms, be it 
the standard C API or a C++ API such as LuaPlus.  Even accessing the Lua
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joshua Jensen | 1 Jan 2008 18:50

Re: XML is ugly, was RE: Towards a better meta-programming language

----- Original Message -----
From: Jack Palevich
Date: 1/1/2008 10:41 AM
> Gah, the JSON example got munched. Here's another try:
>
> {
>  "player": {
>    "name": "joe",
>    "position": {
>      "x": 100.0,
>      "y": 200.0
>     }
> }
>   
For the sake of reference, the same expression in Lua is:

    player = {
        name = "joe",
        position = {
            x = 100.0,
            y = 200.0
        }
    }

Josh
_______________________________________________
Sweng-Gamedev mailing list
Sweng-Gamedev <at> lists.midnightryder.com
http://lists.midnightryder.com/listinfo.cgi/sweng-gamedev-midnightryder.com
(Continue reading)

Permalink | Reply | 0 comments |

Gmane