Comments for davber does IT http://blog.davber.com Functional functional programming - Haskell, Ruby, Erlang, Scala... Wed, 23 Jul 2008 20:27:11 +0000 http://wordpress.org/?v=2.0.12-alpha Comment on Groovy: Java++ by being Java– by Daily del.icio.us for May 12th through May 16th — Vinny Carpenter’s blog http://blog.davber.com/2008/05/09/groovy-java-by-being-java/#comment-588 Fri, 16 May 2008 13:00:51 +0000 http://blog.davber.com/2008/05/09/groovy-java-by-being-java/#comment-588 [...] davber does IT » Groovy: Java++ by being Java– - Groovy is actually not a brand new language, but rather an extension of Java. The difference between this extension and that of, say C++ over C is that Groovy extends Java by simplifying constructs, ridding the developer of much of the repetitive rituals [...] […] davber does IT » Groovy: Java++ by being Java– - Groovy is actually not a brand new language, but rather an extension of Java. The difference between this extension and that of, say C++ over C is that Groovy extends Java by simplifying constructs, ridding the developer of much of the repetitive rituals […]

]]> Comment on Groovy: Java++ by being Java– by Development in a Blink » Blog Archive » Java and Groovy can do it. Why not C# and PowerShell. http://blog.davber.com/2008/05/09/groovy-java-by-being-java/#comment-587 Wed, 14 May 2008 00:30:30 +0000 http://blog.davber.com/2008/05/09/groovy-java-by-being-java/#comment-587 [...] David Bergman presented Groovy: Java++ by being Java– at Lab49 which inspired me to record this 7min Video doing the same with C# and PowerShell. [...] […] David Bergman presented Groovy: Java++ by being Java– at Lab49 which inspired me to record this 7min Video doing the same with C# and PowerShell. […]

]]> Comment on Groovy: Java++ by being Java– by mhyst http://blog.davber.com/2008/05/09/groovy-java-by-being-java/#comment-586 Fri, 09 May 2008 14:13:01 +0000 http://blog.davber.com/2008/05/09/groovy-java-by-being-java/#comment-586 Hi, That's very interesting and well explained. I guess that Groovy simply turns that code into real Java, doing a lot of work for us (of course). But then... it just makes a call to "javac"? If that's the case, the sentence "compilation on demand" means that: groovy compiles it if it hasn't already compiled before?. Closures are really interesting. I got a lot of new ideas for my ongoing programming language (Lilisp). Lol Thank you again! PS: It's nice to read you again.:) Hi,

That’s very interesting and well explained. I guess that Groovy simply turns that code into real Java, doing a lot of work for us (of course). But then… it just makes a call to “javac”?

If that’s the case, the sentence “compilation on demand” means that: groovy compiles it if it hasn’t already compiled before?.

Closures are really interesting. I got a lot of new ideas for my ongoing programming language (Lilisp). Lol

Thank you again!

PS: It’s nice to read you again.:)

]]> Comment on XPath with namespaces in Java by xPaths problem - Java Forums http://blog.davber.com/2006/09/17/xpath-with-namespaces-in-java/#comment-581 Thu, 24 Apr 2008 02:49:25 +0000 http://blog.davber.com/2006/09/17/xpath-with-namespaces-in-java/#comment-581 [...] davber does IT » XPath with namespaces in Java __________________ dont worry newbie, we got you covered. [...] […] davber does IT » XPath with namespaces in Java __________________ dont worry newbie, we got you covered. […]

]]> Comment on Scripting in Python, Ruby, Perl? No, in C++! by davber http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-569 Wed, 16 Apr 2008 22:24:07 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-569 Hey, I intended to move my blog to an Amazon EC2 instance I use, but decided midway to leave it where it is. That is why it was down for a few days. I will try to find some performance metrics for JRuby and Jython w.r.t. Java. Actually, a more fair comparison would be between JRuby, Jython and Groovy, since they all need a lot of indirections to deal with the dynamic semantics of those languages. If I do not find any good metrics, I will run some tests myself. Thanks for staying in spite of the blog going through the motions for a few days :) Hey, I intended to move my blog to an Amazon EC2 instance I use, but decided midway to leave it where it is. That is why it was down for a few days.

I will try to find some performance metrics for JRuby and Jython w.r.t. Java. Actually, a more fair comparison would be between JRuby, Jython and Groovy, since they all need a lot of indirections to deal with the dynamic semantics of those languages.

If I do not find any good metrics, I will run some tests myself.

Thanks for staying in spite of the blog going through the motions for a few days :)

]]> Comment on Scripting in Python, Ruby, Perl? No, in C++! by mhyst http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-556 Sat, 05 Apr 2008 16:12:56 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-556 I couldn't visit this page for a few days. Are you having problems with it? Perhaps it was off for maintenance? Returning to your comment... Programers are nonconformist people. Always rewriting things. lol I haven't any doubts about the benefits of having Ruby or Python written entirely in Java. There are a lot of Java tools that now are available to JRuby and Jython (mostly application server tools). But how many times are we goind to reinvent the wheel? Haven said that... how slow are going to be the programs writen in JRuby or Jython? Before: machine I couldn’t visit this page for a few days. Are you having problems with it? Perhaps it was off for maintenance?

Returning to your comment… Programers are nonconformist people. Always rewriting things. lol I haven’t any doubts about the benefits of having Ruby or Python written entirely in Java. There are a lot of Java tools that now are available to JRuby and Jython (mostly application server tools). But how many times are we goind to reinvent the wheel?

Haven said that… how slow are going to be the programs writen in JRuby or Jython?

Before:
machine

]]> Comment on Scripting in Python, Ruby, Perl? No, in C++! by davber http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-555 Tue, 01 Apr 2008 23:21:42 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-555 Ok, the Java-based implementation of Ruby is called JRuby, not "JRube." Sorry for my fingers' slipping up. Ok, the Java-based implementation of Ruby is called JRuby, not “JRube.” Sorry for my fingers’ slipping up.

]]> Comment on Scripting in Python, Ruby, Perl? No, in C++! by davber http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-554 Tue, 01 Apr 2008 23:19:28 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-554 Well, to be fair against some interpreted languages (i.e., languages whose "reference implementation" is an interpreter, since a language per se is neither interpreted nor compiled, it just is ;-)), they usually handle the parsing once, building a parse structure and/or a (high-level) abstract instructions. This family of parse-once interpretative languages include Python (.py ---> .pyc); note that these intermediate forms are rough enough not to earn the label "abstract machine code" (compared to CLI code or Java bytecode), so they still fall under the interpretative umbrella. Additionally, most interesting sessions (such as an in-process web service module; think mod_perl or mod_ruby) live for quite some time, so the initial parsing itself might not be a big deal; the step-by-step interpretation of that internal format is usually quite slow, though. What I said in the preceding paragraph is that it is not - generally - the re-parsing that hurts performance but the actual internal execution of that semi-digested code. To further appreciate the fact that a language per se is not interpretative, look at Ruby, whose Java bytecode implementation is almost complete (the omitted explicit continuation passing, for instance.) That implementation carries another name, JRube, but is implementing Ruby. Or, Python, in its Jython incarnation. I am having fun, and hope you never lose you programming soul :-) Well, to be fair against some interpreted languages (i.e., languages whose “reference implementation” is an interpreter, since a language per se is neither interpreted nor compiled, it just is ;-) ), they usually handle the parsing once, building a parse structure and/or a (high-level) abstract instructions. This family of parse-once interpretative languages include Python (.py —> .pyc); note that these intermediate forms are rough enough not to earn the label “abstract machine code” (compared to CLI code or Java bytecode), so they still fall under the interpretative umbrella. Additionally, most interesting sessions (such as an in-process web service module; think mod_perl or mod_ruby) live for quite some time, so the initial parsing itself might not be a big deal; the step-by-step interpretation of that internal format is usually quite slow, though.

What I said in the preceding paragraph is that it is not - generally - the re-parsing that hurts performance but the actual internal execution of that semi-digested code.

To further appreciate the fact that a language per se is not interpretative, look at Ruby, whose Java bytecode implementation is almost complete (the omitted explicit continuation passing, for instance.) That implementation carries another name, JRube, but is implementing Ruby. Or, Python, in its Jython incarnation.

I am having fun, and hope you never lose you programming soul :-)

]]> Comment on Scripting in Python, Ruby, Perl? No, in C++! by mhyst http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-553 Tue, 01 Apr 2008 22:36:39 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-553 I agree with you about C++ expressiveness. C++ used to be my prefered language and it still holds a lot of weight on my "programming soul". Java became my first language for practical reasons (references are far easy to manage compared with pointers (less versatile though, I know)). But I think everybody should learn C/C++ before even smelling other languages. Interpreted languages tend to be slow. The reason is obvious: every time you run an interpreted program it has to be parsed. Have fun! I agree with you about C++ expressiveness. C++ used to be my prefered language and it still holds a lot of weight on my “programming soul”. Java became my first language for practical reasons (references are far easy to manage compared with pointers (less versatile though, I know)). But I think everybody should learn C/C++ before even smelling other languages.

Interpreted languages tend to be slow. The reason is obvious: every time you run an interpreted program it has to be parsed.

Have fun!

]]> Comment on Scripting in Python, Ruby, Perl? No, in C++! by davber http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-552 Tue, 01 Apr 2008 05:17:59 +0000 http://blog.davber.com/2007/01/29/scripting-in-python-ruby-perl-no-in-c/#comment-552 Hey! A confession: I do use Ruby and Python, and, yes, even Perl sometimes, although the need for the latter tool is getting smaller with Ruby, Python and Groovy in my hands. The main reason - for me - to use C++ for "scriptable" tasks is *not* its speed, but rather the expressiveness of the language. There are meta constructs available that you do not find in a lot of languages - most dynamic languages, for instance, resort to reflection rather than meta constructs - and that really only exist in languages like Haskell and Scala. And speed and native - no FFI - access to all C-based code is nice. Again, I like Ruby and Python. A lot of really slow languages are implemented in C, by the way ;-) Take care! Hey!

A confession: I do use Ruby and Python, and, yes, even Perl sometimes, although the need for the latter tool is getting smaller with Ruby, Python and Groovy in my hands.

The main reason - for me - to use C++ for “scriptable” tasks is *not* its speed, but rather the expressiveness of the language. There are meta constructs available that you do not find in a lot of languages - most dynamic languages, for instance, resort to reflection rather than meta constructs - and that really only exist in languages like Haskell and Scala.

And speed and native - no FFI - access to all C-based code is nice.

Again, I like Ruby and Python.

A lot of really slow languages are implemented in C, by the way ;-)

Take care!

]]>