[ruby-talk:11402] Re: C scripting: Inline.pm model-- just a toy

On Friday 23 February 2001 10:45, John van V. wrote:
> I spent about an hour looking over the Inline.pm faq on perl.com last
> night.
>
> From the users admin point of view, or especially mobile development, I
> think it is not, as they would like you to believe, a drop in replacement
> for XSUB.
>
> Since it has to be linked to the compiler that created perl in the first
> place it is completely unusable in a distributed environment.
>
> The only practical use I can see is the accessing of shared libs, but still
> you need that specific compiler.

Which means that, for distributed use a Ruby 'inline.rb' would have to be 
deployed as an extension with the specification that it be compiled with the 
same compiler as that for Ruby.  Still, it would be useful (within that 
specific environment) for on-the-fly c/c++ 'scripting' I would think.

Another thought on this: there is a prgram called EiC

http://www.kd-dev.com/~eic/

which is a command-line c interpretor. It is also embeddable, and thus a 
candidate for a Ruby extension, perhaps? If nothing else, the irony of using 
C as a 'scripting language' within Ruby is intriguing, yes?

> Oddly, this product comes out of activestate which is fairly carefully
> trying to prevent users from having just such an environment, especially
> one that is copylefted.

That is because 'management' doesn't 'grok' information economy dynamics. I 
tend to think the programmers there do, for the most part, however. 
'Management' in most places (including the US gov) currently don't 'grok' 
information economy dynamics. The failed dot coms are not because of 'bad' 
business models, but significantly incomplete ones, both within and without 
their specific corporate cultures. Solutions do not become or remain 
solutions unless implemeted in their totality.

> Inline perl in ruby would make a lot more sense, since the perl compiler is
> presumably already on the box being migrated to ruby.
>

Very definately.  The ability to leverage the exisiting solutions from CPAN 
will speed adoption of Ruby within production environments. While in many 
cases a Ruby solution may turn out to be cleaner, better, faster and 
available in a more attractive container, the need for _now_ will take 
precedence up front. So a Ruby 'inline-perl' would be a great value.

> Economic ramble:
> I think this kind of analysis is important in defining the difference
> between firms  developing revenue streams inside the development community
> rather than those providing end user products, like web pages.  The first
> model restricts technology by squeezing developers at the head of their
> revenue stream, the latter enables it by bringing back revenue from the
> profit zone.
>
> People dont want tools they want information and entertainment.

Perzactly!!! You 'grok'! Implementations of solutions are of far greater 
economic benefit than the tools to derive them, simply because of much 
tighter binding to the multiplier effect. Ideas are 'seeds', the tools - 
'soil' and 'water', and implementation is the flowering. For the majority of 
people, the flowers _are_ the garden.

Regards,

Kent Starr
[e-mail]