[Rd] Julia

[Dominick Samperi]

On Tue, Mar 6, 2012 at 3:56 AM, oliver <oliver at first.in-berlin.de> wrote:
> On Mon, Mar 05, 2012 at 04:54:05PM -0800, Nicholas Crookston wrote:
>> There are many experts on this topic.  I'll keep this short.
>>
>> Newer Fortran Languages allow for call by value, but call by reference
>> is the typical and historically, the only approach (there was a time
>> when you could change the value of 1 to 2!).
>
> Oh, strange.
>
>
>>
>> C "only" calls by value except that the value can be a pointer! So,
>> havoc is just a * away.
> [...]
>
> For me there was no "havoc" at this point, but for others maybe.
>
> There are also other languages that only use call-by-value...
> ...functional languages are that way in principal.
>
>  Nevertheless internally they may heavily use pointers and
>  even if you have values that are large arrays for example,
>  they internally just give a pointer to that data structure.
>  (That's, why functional languages are not necessarily slow
>  just because you act on large data and have no references
>  in that language. (A common misunderstanding about functional
>  languages must be slow because they have nor references.)
>  The pointer-stuff is just hidden.
>
> Even they ((non-purely) functional languages) may have references,
> their concept of references is different. (See OCaml for example.)
> There you can use references to change values in place, but the
> reference itself is a functional value, and you will never have
> access to the pointer stuff directly. Hence no problems with
> mem-arithmetics and dangling pointer's or Null-pointers.
>
>
>
> [...]
>> I like R and will continue to use it. However, I also think that
>> strict "call by value" can get you into trouble, just trouble of a
>> different kind.
>
> Can you elaborate more on this?
> What problems do you have in mind?
> And what kind of references do you have in mind?
> The C-like pointers or something like OCaml's ref's?

OCaml refs are an "escape hatch" from the pure
functional programming paradigm where nothing can
be changed once given a value, an extreme form of
pass-by-value. Similarly, most languages that are
advertised as pass-by-value include some kind of
escape hatch that permits you to work with pointers
(or mutable vectors) for improved runtime performance.

The speed issues arise for two main reasons: interpreting
code is much slower than running machine code, and
copying large data structures can be expensive.
Pass-by-value semantics forces this to happen in
many situations where the compiler/interpreter cannot
safely optimize it away.

Based on the video Julia manages the speed issue by
viewing everything like a template, thus generating new
methods based on type inference. This means there isn't
a lot of runtime type checking for dispatch, because
customized methods were already generated, but this
can lead to another problem: code bloat. There are
no free lunches.

>> I'm not sure we will ever yearn for "Julia ouR-Julia",
>> but it is sure fun to think about what might be possible with this
>> language. And having fun is one key objective.
>
> I have fun if things work.
> And if the tools do, what I want to achieve...
> ...and the fun is better, if they do it elegantly.
>
> Do you ask for references in R?
> And what kind of references do you have in mind,
> and why does it hurt you not to have them?
>
> Can you give examples, so that it's easier to see,
> whwere you miss something?
>
>
> Ciao,
>   Oliver
>
> P.S.: The speed issue of R was coming up more than once;
>      in some blog posts it was mentioned. would it make
>      sense to start a seperated thread of it?
>      In one  of the blog-articles I read, it was mourned about
>      how NA / missing values were handled, and that NA should
>      maybe become thrown out, just to get higher speed.
>      I would not like to have that. Handling NA as special
>      case IMHO is a very good way. Don't remember if the
>      article I have in mind just argued about HOW this was
>      handled, or if it should be thrown out completely.
>      Making the handling of it better and more performant I
>      think is a good idea, ignoring NA IMHO is a bad idea.
>
>      But maybe that really would be worth a seperate thread?
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel