ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> tcljava-dev
tcljava-dev
Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 2
by Charles Oliver Nutter other posts by this author
Feb 22 2007 1:13AM messages near this date
Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 2 | Re: [tcljava-dev] tcljava-dev Digest, Vol 5, Issue 2
Bruce Johnson wrote:
>  I agree to some extent with what you say, but personally I think that  
>  when the core of a language like Jacl catches up with the C version  
>  (and it is not that far now), that progress can potentially occur  
>  much faster.  There are so many APIs built-in to Java that  writing  
>  extensions is much faster than with C development, and once written  
>  they are cross-platform.  For example, I have scripted access to  
>  Oracle databases with just a few lines of Jacl calling the JDBC  
>  APIs.  I probably never would have set out to write a C interface to  
>  Oracle (like Oratcl etc.), but doing this with Jacl was a breeze.

I was going to respond myself, but Bruce is exactly right here. What 
library exists in the C world that we don't have an analog for in Java? 
Generally porting over "extensions" just means providing a compatible 
interface to the same library in Java. In JRuby, that's exactly how 
we've provided socket support, zlib support, and so on. There are cases 
where a technology needs to be ported because it's based on a very 
specialized library (OpenSSL) or a technology is too new to have a Java 
equivalent (YAML) but we've had community members step up to the 
challenge of implementing those too.

I think in general the problem most dynamic languages on the JVM have 
had is that they target the wrong goal: some amorphous measure of 
"compatibility" with the target language. What's needed is a concrete 
goal people can latch onto and get excited about; some endpoint that 
will actually help developers do something they couldn't do before. For 
JRuby that milestone is Rails support (and BTW, Rails does run fine in 
JRuby apart from a few remaining interpreter bugs since it's generally 
pure Ruby), which has been a compelling enough goal to get folks really 
excited about JRuby. Similar targets exist for Jython, and perhaps 
Grails will be the first really compelling use of Groovy.

The big question then becomes "what milestone can we set for our 
implementation of language X that will get people excited about using it?"

- Charlie

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
tcljava-dev mailing list
tcljava-dev@[...].net
https://lists.sourceforge.net/lists/listinfo/tcljava-dev
Thread:
Patrick Finnegan
Bruce Johnson
Charles Oliver Nutter
Larry W. Virden
Bruce Johnson
Larry W. Virden

Privacy Policy | Email Opt-out | Feedback | Syndication
© 2004 ActiveState, a division of Sophos All rights reserved