JRuby is Ruby on the JVM. Jython is Python on the JVM. IronPython is Python on the CLR. IronRuby is Ruby on the CLR. Where is Perl?
Re:Scripting bridges
Matts on 2007-07-24T13:13:26
I really don't understand why Apple don't list perl there too. Camelbones will support the scripting bridges stuff too, so it'll be just as "first class" as the others.
Plus Camelbones has an awesome example app.Re:Scripting bridges
slanning on 2007-07-24T14:02:38
I see you're the author of the awesome example app, heh.
(I don't really even know what Camelbones is, but) I was wondering if you use Algorithm::BinPack for that. Your kind of application is even mentioned in the synopsis (s/CD/DVD/) of that module.
Re:Scripting bridges
Matts on 2007-07-24T14:08:06
I don't, because it would put things on the discs out of order, and I don't want that.Re:Scripting bridges
blech on 2007-07-24T15:12:41
Well, it might or might not yet be a "first class citizen" (which I mean to take "ships with the development tools"). However, you're right; unlike Leon's examples, there is a Cocoa bridge. I put that down to the fact that Sherm Pendley's worked for years on CamelBones with little or no reward, but at least some encouragement.
I suspect the answer to Leon's original question is a combination of "nobody wants to do it", "nobody wants it" and "the Perl world is too insular".Re:Scripting bridges
blech on 2007-07-24T15:16:55
Sigh, that reply to Leon's question doesn't make sense; let's try again. "Where's Perl?" "Nowhere, because either nobody wants it, nobody wants to do it, or the Perl world is too insular and nobody noticed anyone else doing it."Re:Scripting bridges
jordan on 2007-07-24T16:44:13
Nobody develops for Perl anymore, CPAN is too crowded.Re:Scripting bridges
Alias on 2007-07-24T20:43:58
Why? I'll tell you why.
Because Perl is resistant to being processed by development tools.
Plain and simple.
This is the same reason that Google goes for Java and Python mainly, because you can write huge toolchains around it.
Perl is impossible to parse.Re:Scripting bridges
jplindstrom on 2007-07-25T13:33:45
What makes Perl impossible to parse (note: compared to Python)?
Re:Scripting bridges
Aristotle on 2007-07-25T15:55:49
You can’t parse it without executing it, even if it looks that way.
Re:Scripting bridges
davegaramond on 2007-07-26T12:16:14
Certainly not true.You can’t parse it without executing it, even if it looks that way.Re:Scripting bridges
Aristotle on 2007-07-26T13:29:43
You’re wrong.
Re:Scripting bridges
btilly on 2007-07-26T17:27:31
You speak from ignorance. I suggest that you read someone who speaks from experience and reconsider your views.Re:Scripting bridges
Aristotle on 2007-07-26T18:18:41
Thanks, Ben. I wanted to link that, but didn’t remember the title and couldn’t think of good search keywords to ferret it out.
Re:Scripting bridges
jdavidb on 2007-07-25T19:42:23
Is it true that a subset of Perl that eliminates string eval and a couple of other features is parseable? What's happened to efforts based on that?
I'm running on low sleep, and there's probably an answer to this, and I should probably know it, but I'd like a refresher for my poor brain.
:) Re:Scripting bridges
Aristotle on 2007-07-25T23:05:27
I think such a subset is conceivable, but it won’t be of much practical interest, as it must necessarily exclude
BEGINas well as assignment to globs, which effectively means nouse.Re:Scripting bridges
davegaramond on 2007-07-26T12:13:56
No longer so. Take a look at PPI, which is a programmatic way to parse and manipulate Perl code without perl. But I agree it probably came too late (2002? 2003?).Perl is impossible to parse.Re:Scripting bridges
Aristotle on 2007-07-26T13:25:01
Take a look at PPI
You know you are talking to the author of PPI, right?
Re:Scripting bridges
sigzero on 2007-07-26T18:57:22
He probably didn't because he doesn't know you from Adam! ; )Re:Scripting bridges
Alias on 2007-07-27T03:48:27
PPI is a programmatic way to parse and manipulate Perl documents.
It is NOT a way to parse and manipulate Perl code.
I know you probably didn't mean to say it in those terms, but the distinction between code and document is extremely important in this case.
This is why providing method name tab-complete, probably the most obvious of all editor assistance functions, is incredibly difficult to do in Perl.
Even after PPI came out, it took a long time for people to realise that "syntax parser" was not necesarily going to mean method name tab completion, but that other types of functionality (like Perl::Critic) would be the low-hanging fruit for Perl.
I think I have proceedings from TPC 4.0 including somebody's paper about doing this. I don't think it was ever finished.
Re:Perl was earlier, but noone finished it
jjore on 2007-07-24T14:36:42
Perhaps B::JVM?
That said, Perl's having missed the "OMG Dynamic!!!" train is potentially damaging if too many new developers are brainwashed, and Perl starts getting dropped from default installs.
Re:No need
chromatic on 2007-07-26T16:57:17
I expect JRuby will either languish in obsolescence like JPython, or become a separate language competing with actual Ruby.If Ruby 2.0 comes out soon and achieves many of its goals (especially with regard to performance and deployment characteristics), JRuby may be less appealing.
Re:No need
educated_foo on 2007-07-26T18:32:36
It'll have to be fast, because the JRuby guys are *very* good marketers. Watch how they gradually get people to refer to Ruby as "Matz' Ruby Interpreter" or "MRI", making it "just another implementation," and spin their really fast Fibonacci function into performance supposedly equivalent to Ruby 1.8. I don't think they're attempting a "language takeover," but they could almost certainly pull it off if they (and Sun) wanted to.Re:No need
djberg96 on 2007-07-27T01:26:16
I think that's a bit harsh. I personally have no problem with the term "MRI" since there are now multiple implementations (JRuby, IronRuby, Rubinius), and I don't use any of them.Performance may be an issue, but I think a much bigger issue for JRuby will be memory and cpu consumption. I don't know that it's solveable with the JVM, either. Then again, most Java programmers have never given a damn about apps like Weblogic sucking the life out of their systems, so they probably won't care if JRuby does it, too.
:| Re:No need
chromatic on 2007-07-27T16:09:56
Performance may be an issue, but I think a much bigger issue for JRuby will be memory and cpu consumption.As I understand it (though one of my references is the JRuby literature), this is also a problem with standard Ruby and one of the motivations of JRuby.
Re:No need
educated_foo on 2007-07-27T16:56:19
It may be a bit harsh or paranoid, but I don't see how a language without a formal spec can survive multiple implementations. Python, Perl, and Ruby have been coherent so far because Guido's, Larry's, and Matz's implementations of their languages simply *are* those languages. Looking farther afield, even Java survived in part because Sun fought Microsoft tooth and nail to prevent its producing an alternative, incompatible "Java" (Visual J++?). Haskell thrives because GHC is the de facto standard. And Scheme flounders because, beyond R5RS, there's no single standard-setting implementation for useful extensions.So I don't see a lot of hope for a language without an official (ANSI/ISO) standard unless it has a single canonical implementation, so that different behavior by another implementation is always a bug.
And yeah, I'll continue to avoid Java and its insatiable hunger for memory like $UNPLEASANT_DISEASE...
Re:No need
djberg96 on 2007-07-27T01:28:42
That's a good point. My gut tells me the Java programmers who want to be able to use an easier language, but still interface with the Java libraries, will stick with JRuby. The rest will move over to Ruby 2.0.
