Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
tintin++ ogg sound player script for linux
Author: Robert Smith
Submitted by: Vladaar
6Dragons ogg Soundpack
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.4
Author: Vladaar
Submitted by: Vladaar
LoP 1.46
Author: Remcon
Submitted by: Remcon
LOP 1.45
Author: Remcon
Submitted by: Remcon
Users Online
CommonCrawl, DotBot, Yandex, Remcon

Members: 1
Guests: 4
Stats
Files
Topics
Posts
Members
Newest Member
481
3,734
19,365
618
Micheal64X
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » General » Coding » Kasji's Tiny PHP Implementati...
Forum Rules | Mark all | Recent Posts

Kasji's Tiny PHP Implementation.... for MUDs!
< Newer Topic :: Older Topic > A Better MudProg Solution ;)

Pages:<< prev 1, 2, 3 next >>
Post is unread #21 Dec 30, 2007, 10:02 pm
Go to the top of the page
Go to the bottom of the page

Kasji
Apprentice
GroupMembers
Posts62
JoinedDec 23, 2007

Samson said:

I guess I must also have glossed over the details. I didn't notice Kasji was planning to reinvent the wheel with his own version of PHP. That does indeed seem like a silly thing to do when you have the language already available. Unless it's web based nature makes using it as-is impractical.


I can't say using PHP is impractical, but let me put it in these terms: spend some months reinventing the wheel, or spend some months reverse engineering the wheel so you know how it works and then getting it to fit right.

It's a matter of taste I suppose. And I not saying it would or would not take months, that's just an example.

If anything though, the blueprints for the wheel are available. The devs of PHP used Bison to build their parser/lexer, and so the rules PHP uses are available, in Bison format.

Option 2 is less tedious but also won't work. You don't necessarily have a symbol for every piece of allocated memory; think of e.g. linked lists.


You are right. I was only thinking in the context of a normal variable. Not classes, or structs, or any other such things. In the early stages there won't be anything interesting like that though.

I'm not sure how exactly you plan on making that work, but if you've got a plan then that's fine. I would have walked the AST without using any kind of grammar, because you don't need a grammar to execute. The grammar is just for parsing the syntax, not representing semantics.


Indeed you are right, I would look at it this way: The walker still needs to know the grammar in some senses in order to do things correctly.

This works only if you disallow closures. I don't remember if PHP lets you return functions from functions.


You've totally lost me. I don't see how that's relevant. The walker sees
return foo($a);


The walker executes the function, or any expression for that matter, gets the appropriate value back, and passes it through the return routine. Am I missing something?
       
Post is unread #22 Dec 31, 2007, 2:49 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Kasji said:

I can't say using PHP is impractical, but let me put it in these terms: spend some months reinventing the wheel, or spend some months reverse engineering the wheel so you know how it works and then getting it to fit right.

But the problem is that your comparisons aren't correct. Writing an entire language implementation is a huge, huge task of which you've just barely scratched the surface. Just wait till you start doing garbage collection and stuff like that. :thinking: It would take me quite a while to implement my own language. But it would take me a day or two to embed Lua. Of course, I had to learn how Lua works, but using their incredibly helpful manual and book Programming in Lua, that was also just a week's worth of very casual reading.

Kasji said:

The devs of PHP used Bison to build their parser/lexer, and so the rules PHP uses are available, in Bison format.

That's helpful but just the tip of the iceberg, unfortunately, and not a very useful tip. The difficulty of writing a parser pales in comparison to the difficulty of getting the runtime working.

Kasji said:

The walker still needs to know the grammar in some senses in order to do things correctly.

Not really; the walker needs to know the structure you parse into. You could have completely different syntaxes that parse to the same abstract syntax tree. (Hence the term 'abstract' in AST.) The grammar is just syntax; the semantics are what the tree walker needs to know about.

Kasji said:

The walker executes the function, or any expression for that matter, gets the appropriate value back, and passes it through the return routine. Am I missing something?

I'm talking about the basic case of returning a symbol that is a function, like function pointers in C, or the more advanced (but much more interesting) case of returning a function -- but not the result of a function.

In Lua you can do things like this:

function make_add(howMuch)
  return function(a)
    return a + howMuch
  end
end

add_two = make_add(2)
print(add_two(2)) -- result: 4

This particular example is obviously not doing something hugely interesting but the idea can be used for extremely powerful purposes.

You can also declare functions anonymously, which is extremely helpful. Perl can do that so I'd be surprised if PHP couldn't. I just don't remember because when I used PHP it was for relatively simple stuff and database access, no interesting algorithms.
       
Post is unread #23 Jan 1, 2008, 11:23 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,643
JoinedJan 1, 2002

DavidHaley said:

It would take me quite a while to implement my own language. But it would take me a day or two to embed Lua. Of course, I had to learn how Lua works, but using their incredibly helpful manual and book Programming in Lua, that was also just a week's worth of very casual reading.


The only problem of course in stating this is that it may not be true for everyone else. A lot of MUD coders have a hard enough time getting C/C++ down well enough to use it without help. For these people it won't just be a week's worth of anything. It'll take months, maybe years, and some people simply won't get it at all and so have to rely on others to figure it out. And embedding is only half the battle. Once that's done then people need to learn Lua syntax and how to use it properly within the MUD. :)
       
Post is unread #24 Jan 1, 2008, 5:16 pm
Go to the top of the page
Go to the bottom of the page

Kasji
Apprentice
GroupMembers
Posts62
JoinedDec 23, 2007

But the problem is that your comparisons aren't correct. Writing an entire language implementation is a huge, huge task of which you've just barely scratched the surface. Just wait till you start doing garbage collection and stuff like that. :thinking: It would take me quite a while to implement my own language. But it would take me a day or two to embed Lua. Of course, I had to learn how Lua works, but using their incredibly helpful manual and book Programming in Lua, that was also just a week's worth of very casual reading.


PHP has little or no documentation about embedding it into other applications. Yes I know Lua takes very little effort to embed, thank you for reinforcing that point, but let me point out again, this isn't Lua. PHP's original design objectives are not necessarily the same as Lua's thus it will definitely (in my case at least) take more than a few days to embed the Zend engine. And as I said in my example, it's just an example. It may very well be faster to study the Zend engine and get it embedded, but in my case, I do not wish to do that. I enjoy writing my own code and solving my own problems, using others' works as references and guidelines.

This is called Tiny PHP for the fact that it doesn't possess every feature that full blown PHP has, and that many builders (who will be writing scripts) wouldn't even begin to comprehend.

I don't want scripters playing with pointers or "interesting" features that you're suggesting. The goal here is to enable scripters to write their own programs with basic but fully functional logic and data manipulation features. I've even discussed with another coder (Stan,) the possibility of using a basic scripting engine to write AI behaviors. It would require altering the update_mobiles function in update.c, but customizing the behavior of individual mobs is a powerful tool. That's the extent of things.

I don't know what you all use mud progs for on your MUDs, but I literally can't think of anything a builder would script that would need pointers, etc. Mud progs provide an added interactivity, quests, and the similar.

And of course, since all of our MUDs are quite different, there will definitely be a modular interface so that struct char_data, etc can be can made (in)accessible easily depending on what you're looking to achieve. And if you want to allow powerful uses of the scripting (such as directly setting variables in inside structs) but want to keep security risks to a minimum, maybe we can develop a permission system for the script engine, where the owner of the script has a permission level of what he/she can and can not use in his/her scripts. Of course, that's just an idea.
       
Post is unread #25 Jan 1, 2008, 7:52 pm
Go to the top of the page
Go to the bottom of the page

Kasji
Apprentice
GroupMembers
Posts62
JoinedDec 23, 2007

Yet another update on my progress.

I've got a decent dynamic variable class going. It's far from complete, but here's an example:
    std::string str("jedi";);
    tphp_var a, b, c, d, e, f;
    b = "test";
    c = str;
    d = 123;
    e = 3.3;
    a = e + b + c + d;
    f = 'c';
    cout << endl << endl << "A: Type: "; a.print_t(); cout << " Value: "; a.print_v();
    cout << endl << "B: Type: "; b.print_t(); cout << " Value: "; b.print_v();
    cout << endl << "C: Type: "; c.print_t(); cout << " Value: "; c.print_v();
    cout << endl << "D: Type: "; d.print_t(); cout << " Value: "; d.print_v();
    cout << endl << "E: Type: "; e.print_t(); cout << " Value: "; e.print_v();
    cout << endl << "F: Type: "; f.print_t(); cout << " Value: "; f.print_v();

And the resulting output:
A: Type: STRING Value: 3.3testjedi123
B: Type: STRING Value: test
C: Type: STRING Value: jedi
D: Type: INT Value: 123
E: Type: DOUBLE Value: 3.3
F: Type: CHAR Value: c


I think that the addition operator is probably going to be the easiest operator implemented. The other operators you would see don't really have a use for strings, that I can think of. So they'll only apply to integers, chars, and/or doubles.
       
Post is unread #26 Jan 2, 2008, 2:25 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Kasji said:

Yes I know Lua takes very little effort to embed, thank you for reinforcing that point, but let me point out again, this isn't Lua.

I don't really know what point you're trying to make. It sort of seems like you've chosen PHP simply because it's called PHP and you recognize technical superiority elsewhere but nonetheless choose PHP. (but see right below...)

Kasji said:

I enjoy writing my own code and solving my own problems, using others' works as references and guidelines.

As I said in my very first post, it's perfectly fine to want to do this for the learning experience. If that is the goal, it should be recognized, and people shouldn't think that this is being chosen because of efficiency, time, or technical advantages. Along those lines, I also think that it would be a mistake to think that the path you're embarking on is the simplest, so I just wanted it to be clear that what you're attempting to do is really quite difficult (even the simple version).

Kasji said:

I don't want scripters playing with pointers or "interesting" features that you're suggesting.

It sounds like you're setting out to do a huge amount of work to implement a simplistic language. I think it would be a shame when you have so much potential for powerful scripting (if anything for yourself, not your builders) and then not make use of it.

Incidentally, I wasn't talking about pointers at all, but I suspect the point is moot.

Kasji said:

I don't know what you all use mud progs for on your MUDs

I'm moving most command handling into Lua so that I can take advantage of coroutines and thereby have stateful command handling. I had a post about it on these forums but it was lost with the drive crash. Basically I have plenty of reasons to make full use of these features, but I suspect we're not thinking about using scripting in the same way. You appear to want to basically reimplement mudprog but with PHP syntax whereas I am using scripting to drive larger portions of the game, perhaps more like LPC.

Kasji said:

the possibility of using a basic scripting engine to write AI behaviors

I'm a little surprised that you think a basic scripting engine is to best choice for AI behaviors, but maybe we don't have the same kind of AI behavior in mind. A common operation, for example, is to take a function and apply it across a collection of things; you can't do that as nicely without higher-order functions (or at least function pointers or some similar mechanism).
       
Post is unread #27 Jan 2, 2008, 2:55 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

That's interesting; TinyPHP as defined in the syntax you linked to does not allow function calls to be within expressions. It only allows functions to be used as subroutines at the statement level. (It also doesn't have a 'return' keyword so I guess functions can't return anything to be used in expressions anyhow.) How odd...
       
Post is unread #28 Jan 2, 2008, 6:04 pm
Go to the top of the page
Go to the bottom of the page

Kasji
Apprentice
GroupMembers
Posts62
JoinedDec 23, 2007

Do you have a problem with me or my idea, DavidHaley? I had asked you to point out anything I should watch out for, but our conversation seems to have taken a turn for the worst and has hardly been constructive, if that. You seem to have switched from the impartial tone of warning to a more aggressive "this is a bad idea" type of tone, as if you were trying to deter myself or other community members. Of course I could simply be imagining this, but I none-the-less feel that your posts are not constructive. You are by no means obligated to help me, but I request that you not clutter this thread with fruitless posts. I too am guilty of this, as I have entertained your previous few posts, but I will no longer be responding to anything that is not helpful here. Thank you for you time, and thank you for your warnings.
       
Post is unread #29 Jan 2, 2008, 6:22 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Well, to be perfectly honest, yes, I do think that your approach has some issues, unless (again) you are doing it for the learning experience. I didn't realize it would be a problem to say so. And yes, to be perfectly honest, I would want to deter anybody who's not in it for learning from following this path given its many pitfalls and quite low time/payoff ratio. I have no problem whatsoever with you -- I'm not sure where you came up with that. On the contrary, I think it's really great that somebody is interested in this kind of work; I've learned a lot about it, the most important lesson, in many ways, being that it's a lot harder than it looks. :shrug:

I take some offense at being told that my posts above, with the potential exception of #26, are fruitless given that they address specific issues and problems that are likely to crop up for you, and general problems in implementing scripting languages. Of course, I was working with only the information you had given me, and as usual it is possible you are much further along than your posts' content, in which case you need only say so.
       
Post is unread #30 Jan 2, 2008, 7:29 pm
Go to the top of the page
Go to the bottom of the page

Darwin
Fledgling
GroupMembers
Posts37
JoinedOct 10, 2007

Samson said:

DavidHaley said:

It would take me quite a while to implement my own language. But it would take me a day or two to embed Lua. Of course, I had to learn how Lua works, but using their incredibly helpful manual and book Programming in Lua, that was also just a week's worth of very casual reading.


The only problem of course in stating this is that it may not be true for everyone else. A lot of MUD coders have a hard enough time getting C/C++ down well enough to use it without help. For these people it won't just be a week's worth of anything. It'll take months, maybe years, and some people simply won't get it at all and so have to rely on others to figure it out. And embedding is only half the battle. Once that's done then people need to learn Lua syntax and how to use it properly within the MUD. :)
Well, if one were to use the SmaugFUSS with Lua already embedded in it and refer to Nick Gammons post on the code, it wouldn't take nearly any time at all to learn how to use it. The code provided is enough to do a lot of things already. The documentation is well presented and it would only take a moment to register to his forums if you had a question about it.

Lua is really simple but powerful and flexable. I don't understand the ease of which it was dismissed as an alternative to the OP. It would surely take less time to embed Lua than it would to create an entirely new scripting language.

This, of course, is just my opinion and should only be taken as such.
       
Post is unread #31 Jan 2, 2008, 8:03 pm   Last edited Jan 2, 2008, 8:05 pm by Kasji
Go to the top of the page
Go to the bottom of the page

Kasji
Apprentice
GroupMembers
Posts62
JoinedDec 23, 2007

Darwin said:

Samson said:

DavidHaley said:

It would take me quite a while to implement my own language. But it would take me a day or two to embed Lua. Of course, I had to learn how Lua works, but using their incredibly helpful manual and book Programming in Lua, that was also just a week's worth of very casual reading.


The only problem of course in stating this is that it may not be true for everyone else. A lot of MUD coders have a hard enough time getting C/C++ down well enough to use it without help. For these people it won't just be a week's worth of anything. It'll take months, maybe years, and some people simply won't get it at all and so have to rely on others to figure it out. And embedding is only half the battle. Once that's done then people need to learn Lua syntax and how to use it properly within the MUD. :)
Well, if one were to use the SmaugFUSS with Lua already embedded in it and refer to Nick Gammons post on the code, it wouldn't take nearly any time at all to learn how to use it. The code provided is enough to do a lot of things already. The documentation is well presented and it would only take a moment to register to his forums if you had a question about it.

Lua is really simple but powerful and flexable. I don't understand the ease of which it was dismissed as an alternative to the OP. It would surely take less time to embed Lua than it would to create an entirely new scripting language.

This, of course, is just my opinion and should only be taken as such.

Jesus, enough already. I have examined Lua. I know about Lua. I understand the capabilities of Lua. I do not want Lua. I did not create this thread asking for alternatives to creating a scripting language. I created this thread for those interested in watching the progress of this scripting language and helping if they so choose to. I never once asked anyone "should I create my own language or go with something already out there?" If that question were open to discussion, I would quickly choose embedding something like Lua (probably Python though.) Something that isn't an option in the first place, can't be dismissed. This thread would not exist if I wanted to implement Lua or some other already existant language. I would simply go and do it and wouldn't have come here in the first place (for that particular matter.)

And DavidHaley, I certainly did not mean that all your posts are fruitless, they have (at least in the first page of this thread) been quite helpful in providing some guidance and ideas. But I certainly did mean that last 3 are not constructive, or in other words, not helpful to me. Of course your posts may be helpful to others. But I guess by posting this message I've gone against my own words, seeing how this post is not furthering the development of this project.

I'll try to salvage this thread though. Just a quick update. To show that I am not partial to blindly walking into this so called pitfall, I am making an effort to disect the Zend engine and learn how it works. Incidentally this helped me find a few things about PHP I didn't even know, but aren't relevant to this project in any case. ANTLR doesn't allow left-recursion rules, example:
some_list: (some_list)? item;

That's left-recursion for those who don't know, and as you might deduce, right-recursion looks like:
some_list: item (some_list)?;

Note: the ? in the rule means that (some_list) is optional (it may appear 0 or 1 times.)

The PHP grammar uses left-recursion only, and so I am guessing that Zend is a bottom-up parser, because it will consume tokens from right to left, matching the longest rule. Longest meaning most tokens.

Now that I have a couple days off from work I can spend some more time getting things done.
       
Post is unread #32 Jan 2, 2008, 11:05 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Kasji said:

If that question were open to discussion, I would quickly choose embedding something like Lua (probably Python though.) Something that isn't an option in the first place, can't be dismissed.

Forgive me for returning briefly to this point, but I believe that the reason it has been discussed to this extent is that at least some people feel that the disadvantages are strong enough that we think it might be worth reconsidering even though it wasn't your original question. At the very least, it is why we've been trying to explore your reasons for this choice (your stated reasons so far being preferring the syntax, and to a lesser extent the learning experience). I think you've made it clear though now that you're not in the least bit interested in thinking about anything else whatsoever no matter what. :wink:

Kasji said:

The PHP grammar uses left-recursion only, and so I am guessing that Zend is a bottom-up parser, because it will consume tokens from right to left, matching the longest rule. Longest meaning most tokens.

It wouldn't surprise me if PHP was written for a bottom-up parser because LR/LALR is, I believe, more common than LL parsing. That said, bottom-up parsing doesn't have to be right-to-left, in fact, usually it is left-to-right.

Fortunately, though, it has been proven that any left-recursive grammar can be relatively straightforwardly (and automatically) translated to a right-recursive grammar, so this isn't really a show-stopper. (You still might not end up with an LL grammar in the most general case but usually you do.)
       
Post is unread #33 Jan 3, 2008, 11:53 am
Go to the top of the page
Go to the bottom of the page

Kasji
Apprentice
GroupMembers
Posts62
JoinedDec 23, 2007

I know that you'll love this one: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=lua&lang2=php

A nice language benchmarking site. As you can see, Lua vs PHP, Lua is the clear victor. The reason I am bringing this up is not to say that Lua is better than PHP in terms of speed and memory use (which is quite apparent), but rather: This is a good reason not to embed the Zend engine. This is why I would rather reconstruct PHP from the ground up, rather than embed the current PHP implementation.
       
Post is unread #34 Jan 3, 2008, 3:20 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Yes, I know about Lua's benchmarking, although in this case I believe the speed doesn't really matter. And yes, it that may be true that PHP's implementation is slow and that redoing it could be faster. But it's also true that those other engines were written by people over a long course of time and who probably were fairly good at what they do; chances are that they weren't exactly novices at this. So I think it's unlikely that a first-time implementation would beat those other implementations. Now, the fact that you have set out to implement only a basic subset of PHP might be a better reason to think it will faster. Still, be cautious: it's your first time doing this, after all...
       
Post is unread #35 Jan 4, 2008, 12:15 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

One question I have is... do you want to write a PHP interpreter (or a subset thereof)? Or do you want the PHP syntax and don't care what engine is actually under the hood?

I ask because it is often a much simpler task to write a syntax parser and then emit a properly formed chunk of code for another interpreter to handle. Embedding a secure language (there are many, Lua, Ruby, Python, Perl, even LPC if you want to really mix and match) and then writing a translation layer might be interesting. In fact, if you wanted to trust MONO/.NET, you could even use allow multiple high-level interfaces.

If you do want to build the beast from the ground up though, more power to you! Just keep the Dragon Book handy, and a good supply of tasty beverages and pain killers. :)
       
Post is unread #36 Jan 4, 2008, 1:02 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

That's an interesting idea, and would probably be better than attempting to reimplement an entire runtime interpreter, but it still seems like a whole lot of effort just to keep PHPish syntax. :wink: (IMHO, of course.) Syntax translation poses sometimes significant problems of its own, depending on the differences between what the source and target languages can express (or how they express it).
       
Post is unread #37 Jan 4, 2008, 3:04 pm
Go to the top of the page
Go to the bottom of the page

Kasji
Apprentice
GroupMembers
Posts62
JoinedDec 23, 2007

This thought actually occurred to me yesterday or the day before. I was wondering, would it be possible to embed a current implementation, but alter the implementation to use PHP syntax or translate the PHP syntax to the implementation's syntax. I dismissed the idea though, because I am not sure it would be any easier than writing an implementation from the ground up. There are some issues to take into consideration as well, PHP being dynamic typed, it would be difficult to translate to a static typed implementation (at least at first glance.) But seeing how this Tiny PHP is a very limited in features, aside from the dynamic typing it probably wouldn't be not too bad to do.

Again though, I am not sure if it would be less effort, and as David said it would depend on the target implementation. This is something I am not sure how to implement though, and quite honestly I'd rather alter the lexer/parser of the implementation than have to add the overhead of translating.
       
Post is unread #38 Jan 4, 2008, 7:49 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

The syntax of PHP is very similar to C, and as such it has much in common with Perl and Ruby. I wouldn't expect that direction to be significantly different, provided you accept that the end product perl or ruby code would not be terribly efficient. Python and Lua are also typeless (or weakly typed... I forget), although their syntax is a little different.

in PHP:

$foo = array( 1, 2, 3 );
foreach ( $foo as $k => $v ) {
  echo "$v\n";
}

in Perl:

my @foo = [ 1, 2, 3 ];
for( my $i = 0; $i < scalar(@foo); $i++ ) {
  print $foo[$i] . "\n";
}

more efficiently in Perl:

my @foo = [ 1, 2, 3 ];
print "$_\n" foreach ( @foo );



Nothing is ever as simple as it first seems, but translation avoids the joys of dealing with managing stack frames for local variables, garbage collection and circular references, and other ways to fill your evenings with joy. :)
       
Post is unread #39 Jan 4, 2008, 8:19 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Perl is a pain to embed. I'd recommend against embedding Perl if at all possible...

In the end of the day, the syntax of the target language is irrelevant. What matters is what can be expressed in both languages, and then whether everything in the source has an obvious, 'automateable' translation into the second.

TinyPHP's syntax seems extremely simple, though. It doesn't even have return values for functions. I'm also not sure it has array initializers (I don't remember and don't feel like pulling up the spec now). So I think it would be a fairly simple manner to write even regular expressions that translate it into another language.
       
Post is unread #40 Jan 4, 2008, 8:33 pm
Go to the top of the page
Go to the bottom of the page

Quixadhal
Conjurer
GroupMembers
Posts398
JoinedMar 8, 2005

I agree with you there. Perl is a "write only" language, unless you've been brain damaged by doing database work with it for five years like myself. :)

Ruby is a nice language.... perl with a much cleaner syntax AND design, but still a rather perl-like feel.
       
Pages:<< prev 1, 2, 3 next >>