Re: Irssi redesign / rewrite

> perhaps try to make as much of stuff a part of the Perl scripting 
> language. Don't keep /notify command in irssi, but move to a perl script? 
> look at XiRCON: has never crashed on me, and i've used it since the first 
> release... there aren't many commands that actually need to be kept in 
> irssi (and C) even for added speed. Make the interfacing clean, simple, 
> and correct and you probably solve a lot of issues, and make the design 
> cleaner.
>
> And how about using some other language (hint: Ruby)? Perl seems to be a 
> mess to interface with.

--I agree that scripts should hold as much of the features as possible, 
replybut I also think that irssi should be fully --functioning for most 
people without external scripting language. --You already note the worst 
problem, people want to use different scripting languages. People also 
install irssi in computers --that don't have some specific language 
installed, Perl is quite safe nowadays since it's been around for ages. I'm 
IRCing --from a computer that doesn't have Ruby installed, and likely will 
not be unless I install it into homedir. --Supporting multiple scripting 
languages is good for giving script coders a choice, but annoying for users 
who want to use --script done with multiple languages, possibly requiring 
them to install the language and at the very least use more memory. I -- 
won't be writing support for more than one language (very likely Perl), but 
that doesn't mean others can't write it. Irssi's --core doesn't make any 
assumptions what scripting language you may be using.

I know I'm full quoting, but as this is older mail I wanted to keep the 
context.  I personally think having an internal scripting language is a 
very BAD idea.  If anyone has used MIRC and its insane scripting language I 
would not like to see yet another client-specific scripting language.  Perl 
is great, but I know it has many detractors.  Would it be so difficult to 
have loadable modules that were interpreters for various scripting 
languages?  Pick one for the base, ie Perl, then produce an API (or even 
write modules with the project) that support various other major languages. 
 The most annoying thing to me about switching clients is having to learn a 
new language each time.  I would be thrilled (and I'm sure others would be 
too) if we could script in the language(s) we prefer?

The modules could be loaded at runtime, or statically built in depending on 
the users needs/wants.  Yes you would have scripts floating around in 
differnet languages, but choices mean your user base would grow.  Making 
the major scripting languages official modules would ensure QA, but you 
could also make the API easy to access so any language under the sun could 
theoretically be supported.

Just my $0.02.

Ted