[ruby-talk:20442] Re: Backwards language

Ack, first, sorry my mailer doesn't seem to like your quotes...

> Sean Middleditch <[e-mail]> wrote:
> : language such as Ruby, would require far less code on the
> interpreter's : end (no need for a compiler to be built in), and IMHO
> would result in : more readable code that is just as powerful and
> dynamic.
>
> You'll have to prove that assertion.
>

I'm working on it.  ^,^

> : Yes, I see that eval() is very power in the fact that it can
> dynamically : generate executable code, and I believe that it is fun (I
> love playing : with stuff like that myself).  But is it really
> necessary?  When one : wants a very small runtime that is very fast, is
> that power worth : embedding an entire compiler?
>
> You're working on game scripting, right?  Let's take the Crash
> Bandicoot series as a data point.  The game is scripted in a full LISP
> interpreter.  It runs, and fast, on a 33-MHz PSX chip with 3 M RAM.
> What are the numbers you have to fit in?
>

When one wants a small runtime that is very fast, numbers seem to mean a
lot.  While I know that Perl can run in small embedded devices, it doesn't
seem to matter much to people who look at executable size vs. RAM size, etc.

And I also find that Crash Bandicoot/LISP thing interesting.  Do you know
which LISP interpreter, or was it built in house?  LISP is also a small
language (depending on implementation), which is one reason I like it so
much (although I abhor that syntax.  ~,^ )


> It's easy to say "I can't figure out how to write this fast, therefore
> no one can and you don't need it."

Understood.

>
> : And, to be honest, if you're developing a
> : large-scale (possibly commercial grade) application, is fun or
> : robustness/efficiency more important?
>
> Fun is.  Robustness and efficiency do not exist in a vacuum, and if
> your programmers can't find the fun, then the project is doomed anyway.
>  And whatever your school is teaching you, far more small, fun hacks
> grow into complex, critical, *successful* applications than are
> designed that way.

I think there's a difference between what I mean by fun (i.e. recreational
activity and/or playing around) and what you seem to mean, which I'm taking
as "enjoying the experience."  I think C is "fun" in that sense, but I don't
write random bits of code in C for recreation.  Although I've definitely
played with Ruby a lot in that way.

>
> : Some features are fun, and possibly useful, but I still don't at all
> see : eval() as being necessary, or even wise.  Sorry.  ^,^  Perhaps
> I'm just : too old and set in my ways.
>
> http://sourceforge.net/people/viewprofile.php?user_id=26193
>
> I'm fairly certain you are bound by state and federal statues not to
> claim that you are 'too old and set in my ways' before the age of 20.
> BTW, I used to live in Ann Arbor.  Nice place.

The age thing was a joke.  ^,^  And ya, I like Ann Arbor too, although I'm
really closer to Ypsilanti City.  I spend a good deal of my time (or did,
before work took most of it) in Ann Arbor, though.

>
> As for eval(), if you cannot generate code and execute it within a
> program, then you are incapable of metaprogramming - writing programs
> that write programs.  And while switching editors or methodologies may
> give you a 2- or 5-fold increase in productivity, only by incorporating
> the machine into the development process can you find the 1,000-fold
> increase that we are looking for next.  Just a data point.

But should this eval() be built into the language itself as a core
component?  I can where, perhaps if one wished to play with full
meta-programming, it would be necessary, but neither do I see a need for
meta programming outside of the academic field.  or are there some examples
to prove me wrong?  Again, I'd rather be proven wrong and corrected now than
just be wrong for a long time to come.  ^,^

>
> In the general case, well, there is a general question of what you
> percieve as necessary and how you restrict others who see differently.
> It looks like your background is in static Algol spawn, and as Paul
> Graham says "programmers learn not to want what their language cannot
> provide." And I would contend it's a bad idea *not* to expose as much
> power and flexibility to the programmer, because languages that talked
> down to people have historically been bad, or at least non-beloved:
> PL/1, Ada, COBOL.

C/C++ is my most familiar language actually.  I haven't looked into Algol at
all, although I'm slightly familiar with COBOL.  I've studied newer
languages a lot more though, especially lately.

In any event, I find that rarely is there anything I need to do in C/C++
that isn't possible.  Sometimes just a bit hard to do.  ^,^

>
> Lastly, exising features for speed is often a fool's errand.  Speed
> comes

OK, I'm thinking either you did something or I really need a new mailer,
your message is cut off...

Anyhows, I'm not exacting "exising features."  I am developing a new backend
to meet my needs and wants.  Much as how Ruby was developed because no
language suited Matz's needs and/or wants.  I would never dream of using my
new language for a real application, because it won't have the features to
do so - it isn't *meant* to have the features to do so.

Ruby is a very dynamic language, which is really great, but isn't what I'm
looking for in my project.  I seem to have generated the wrong set of
reponses to my original query, which was merely what people though of
designing a backend before a syntax, for a syntax-neutal language, once
designed for it's power and speed of execution over it's gramatical and
syntactical features.

::sighs:: Man am I high-strung today... ~,^

Sean Etc.