It would have to be Core_kernel, the subset of Core that doesn't interact with the runtime or OS. I'm very curious about this and would like to know, too.
You're confusing UdeM with UQAM. UdeM is the more prestigious one by far, but it's also smaller than UQAM. There's at least 6 universities in Montreal, it's easy for outsiders to get lost.
I pick some technology that has the following characteristics:
- A complete paradigm shift. I want something that will force me to rethink how I approach problems. I want to force my brain to develop new pathways, so to speak.
- Something will at least a minimum of documentation and community online. I've had to abandon dreams of learning some really awesome language before (ATS) because there was simply no resources and that would make my progress too slow.
- Something that could be fun to use in a side project. I need to be able to find occasions to use it. I learn best by doing rather than by only reading. If I can't think of an application, then I won't be able to become proficient, so I'd rather learn something else.
- And finally, it has to be something fun that feels like falling in love with programming all over again.
EDIT: I usually don't pick more than 1 technology to REALLY LEARN per year, so I don't make these decisions lightly.
The point of the article was to show how the % of used memory will affect performance in a non-linear manner. It's obvious once you know, but it's not if you've never experienced it before.
When open source implementations, reference guides/manuals and public internet forums (in that order from biggest to smallest sign) start being ubiquitous.
Author here, I originally posted this to https://www.reddit.com/r/ocaml to gather some feedback prior to posting it here. It was a surprised when my boss told me "Hey, you're top 10 on HN right now". Glad to know someone liked it enough to post it here before I could :)
It's something I've been working on for quite a while, because I wanted to answer the question "Why do you like OCaml so much and why should I care?" once and for all. Hope you enjoy it.
Speaking of OCaml, all the traffic going to my blog is going through HARchiver [0], a very high performance proxy and reverse-proxy 100% written in OCaml that gathers datapoints for use with Mashape Analytics [1]. Disclaimer, I work at Mashape.
Small nitpick: 'unit' is more like 'void' than 'null'. Think of a procedure that returns nothing in C: it returns void, similarly in OCaml you return unit. I think the equivalent of 'null' would be None, if you think of pointers as 'a option, except you have to handle it explicitly and can't get NullPointerException like you mention.
I'm not sure. Void is not a real value, whereas unit is (unlike the article states) just a normal value, which supports all the things you can do with values, like assigning/let-binding etc.
While at it, let me add some more comments to the article, since the OP was asking for input:
> In Java and JavaScript, any object can be null and it leads to Null Pointer Exceptions at runtime.
I know what is meant, but that is really strangely written, since the only object that can be null is null itself. In JS to pick your example, {} can never be null.
> There are two different forms: SUM types and PRODUCT types
This comes after introducing tuples which are also product types, they even have multiplication signs in their type signature :-)
> SUM types in OCaml are called Variants.
You could note that enums are sort-of-kind-of sum types in C.
Also, you should probably emphasize that your examples use Core which is not the standard library, because the standard library has completely different signatures, has no Option module, etc. You should probably add the relevant open line, otherwise it is confusing for people that some of the examples don't work and produce complicated error messages.
> I'm not sure. Void is not a real value, whereas unit is (unlike the article states) just a normal value, which supports all the things you can do with values, like assigning/let-binding etc.
This is true, but null is effectively at the bottom of the inheritance hierarchy in that it is a valid value for any (pointer) type (in C/C++/Java etc.), while unit cannot be used that way. The relationship between unit and void is that if you were porting a program from an imperative language with void to OCaml, you would generally replace any place where you returned void or took no arguments/void as the argument with unit. Like void it conveys no real information.
