While I agree with your comments about the general principle, I don’t think this is a particularly good example — the uses of sample in Turing and StatsBase don’t have anything to do with each other, so it is just recycling the symbol for something completely different, not an example of generic programming. Technically fine, but not good style. See this topic.
Generally, defining & exporting a function f in a ...Base package is useful if it is part of a generic interface other packages may extend, or just use without restricting to a particular type in mind. Nice examples include
Both are sampling points according to a distribution, one is just implicitly defined and the other is explicitly defined. I think more an more, a Turing model itself should be treated as a distribution. If the abstraction is done right then you should be able to use a Turing model as a prior distribution for another Turing model. The connection isn’t there yet but I don’t see a reason why it shouldn’t be in the future.
Is Julia’s way of OOP superior to C++/Python? Why Julia doesn’t use class-based OOP?
@vedasulo Your question hits the nail on the head – Java, C++ and (weakly) Python are Class-Oriented Programming (COP) languages, and COP requires multiple-layer inheritance with concrete class sub-classing to resolve the problems discussed above. Julia’s OOP is superior precisely because it’s not COP. If I am allowed to say that a struct + methods = object (and let’s not worry that an object is an instance of a class), in COP methods belong to a struct, whereas in Julia’s Method-Oriented version of OOP, the structs belong to the methods. Both are OOP. Both use a combination of methods and structs to describe behaviour of objects.
Sure, but the signatures are so different that with the current design, it is very unlikely that one could use sample in generic code, like +. Which is what you would expect, as StatsBase’s is sample methods are low-level utility functions, while in Turing they are part of the high-level API.
Note that I don’t indend to single out Turing here — other packages do similar things, and I have done this myself. The idea that recycling a symbol for a completely different, non-conflicting signature may not be a good design for Julia evolved with practice and I think is a good principle to follow.
I loved the syntax as easy as possible. Also I was quite learning about Meta programming and things, also found in lisp and like computerphile telling why was its popular language.
I was quite surprised the power of Metaprogramming , data as code and things and also easy to write and know things.
Only hurdle is , How fast is industries adopting julia knowing these powerful things?
Quite similar to Call/CC in scheme. I could program it like a champ for the one simple example everyone likes to talk about, but after that you are left in the dust wondering how you get adept enough to speak it. And marvel and curse the folks who could. And then you have this epiphany that the whole thing was a scheme (pun intended) to confuse the heck out of you and you should never have bothered with it in the first place.
But there was this quirk in the RISC processor Sun Microsystems used that had this way to optimize tail calls by popping the stack all at once. It was very useful for recursion.