Real World OCaml | Hacker News Reader

Real World OCaml

realworldocaml.org

99 pointsepsylon42 comments

The login url contains the string

    redirect_uri%3Dhttp%253A%252F%252Fwww.realworldocaml.org

Looks to me like whatever Github authorizing is being sent back to an insecure non-https site. If a passive observer were to see this in transit, I think they could probably steal the authorization token a la Firesheep.

The FAQ says "you temporarily grant us access to your public repositories", so I'm thinking this probably means your Github repos become writable to an attacker.

Some more info from the author on the OCaml mailing list [1].

New readers might want to check out the FAQ before diving in [2].

[1] https://sympa.inria.fr/sympa/arc/caml-list/2013-06/msg00101....

[2] http://www.realworldocaml.org/#faq

EDIT: Some more info from the email.

"Release notes for beta1:

- The first-class modules chapter is incomplete, pending some portability improvements to the ocaml-plugins Core library.

- The binary serialization chapter is also incomplete, but has just enough to teach you about the Async RPC library.

- The installation chapter will be revised in anticipation of the OCaml 4.1 release, and is currently quite source-based.

- The packaging and build systems chapter hasn't been started yet. We're still deciding whether or not to make this an online pointer rather than a print chapter, since it's likely to change quite fast.

- We are preparing exercises per chapter that are not included in this particular beta release, but will be available online as soon as possible.

- The code examples will all be clonable as a separate repository in beta2."

If you are surprised about the access requests when authenticating on GitHub. It seems like they couldn't ask for less than "all your public repos". (as amirmc mentioned, check out the FAQ : http://www.realworldocaml.org/#faq)

Yeah, that seems odd to people the first time. The experience is pretty nice though, since you get all the good stuff from the GitHub issue tracker when you join/create a thread (e.g. dealing with follow-ups by email).

Let me guess... they're using OAuth as an authentication protocol, and it's working weirdly 'cause it's an authorization protocol?

You don't need to guess. It is explained in the FAQ.

"We just want the ability to create issues in one specific public repository, but the minimum privileges we can request from Github are the ones you see when you login."

http://www.realworldocaml.org/#faq

Ah, that's quite reasonable actually. Forgive my bitterness.

Mercifully not. They want to get authorization to post under your name in one single public comments repository (so that when you comment it's all managed by them in their repository). But Github OAuth (they claim) doesn't have that level of fine grained permissions - they can only request permission to post to all repositories in your name.

I've loved using OCaml on some toy problems. OCaml (and so probably F#) feel suitable for anything you'd use Golang for (performance is similar; code can be terser due to typing-saving language features), except if you must have threads for concurrency.

F# has all the threading power of the .NET runtime at its disposal, including asynchronous programming and the TPL.

OCaml global lock on the INRIA implementation might eventually be fixed.

Both are pretty good alternatives to Go if you are more into FP and modern language abstractions.

Are other forms of concurrency still available? This has always seemed like a strange limitation. Most of the code that I write doesn't require me to spin up tons of threads (at least, not in my code), but sometimes it's really helpful to have them.

Yes:

* multiple processes (there are a few libraries that can help make it easier)

* I/O concurrency with cooperative threads library: Equeue, Lwt or Async

* you could also use the built-in Thread module for I/O concurrency but the overhead will likely be higher

* you can execute C code in multiple threads in parallel, only OCaml code is limited to a single thread (due to the global lock)

What are those libraries for multiple processes under Ocaml?

I could google but I'm fishing for your recommendations as well.

Functory, OCamlMPI and Netmulticore (part of OCamlNet). I haven't actually used any of them though, I'm quite happy with Lwt for now.

" Authorize Real World OCaml Commenting?

The app Real World OCaml Commenting will be able to:

    Read your public information.
    Update your public repositories (Commits, Issues, etc).

WAT?

Please read the FAQ

http://www.realworldocaml.org/#faq

I read it as something like this: "We really promise not to mess up your account. Really-really. Oh wait, our server has been hacked".

You still haven't read the FAQ:

  However, we never store your authorization tokens in our server, and instead just directly pass your authorization token into a client-side cookie.

Never store != never see

If you really want to contribute and fear for your actual account, you can still create a fresh new one and just use this one to add some comments where you feel to.

This would be against github ToS

How I wish Scala would be more like OCaml instead of a disgusting mess of useless sigils and buzzwords.

Yeah, I also prefer the ML syntax.

There is Yeti, an ML style language for the JVM:

http://mth.github.io/yeti/

(edit to address questions/comments)

I haven't actually used it so I have no idea if it's ready for "real" use (whatever that means! everyone has a different definition) However, it's under active development which is more than you can say for ML. I only found it when I saw the above comment and thought "I wonder if there is an ML for the JVM" but I have put it on my own todo list to check it out.

And I know the pain of which you speak pjmlp, I have to use PHP for my day job...

Thanks for pointing it out, but on my line of work I will jump of joy the day I will ever manage to use anything besides Java on the JVM.

Fortune 500 enterprise development, offshoring and modern programming languages are hard to combine.

You can compile OCaml to run on the JVM, although I never tried / needed to do such a thing: http://ocamljava.x9c.fr/preview/

Is yeti ready for real use?

Yes. Scala is a great language, but it devolves into line noise so quickly. ML's relative lack of brackets is so nice, and so is the automatic currying of multi-argument functions. I also really love discriminated unions, and it's really hard to simulate them in Scala.

I agree with the first two points about ML, but I'm curious where you've had problems using Scala's case classes as you would ML's discriminate unions (minus the added verbosity)?

What "useless sigils and buzzwords" does Scala have?

The Dispatch periodic table is probably a discredited meme by now, but it's all too representative of many scala libraries. Akka uses ! and ? for its two most important methods (and a pet moan: the experimental typed channel proposal uses :+: for type-level lists despite their being functionally the same as shapeless' :: HList). Shapeless constraints can't even be typed on a normal keyboard - they're things like ->[A]#λ or <<:[B]#λ (real examples from my day job). Scalaz is only slightly better (pulling up a random example I see "@@" used as an operator). Sometimes these sigil operators have non-sigil aliases but that's the perl trap of "there is more than one way to do it" - one can't just ignore the sigils because one has to read code as well as write it (and given that even quite major libraries like scalaz come with no scaladoc, one is often forced to read someone else's code to figure out what a function does).

I love scala, but I do find myself wishing method names were required to be alphanumeric.

Both ! and ? have their history in Erlang, it was a conscious design decision to use those sigils.

I've not looked at typed channels at all, but yeah, thats annoying.

Scalaz and Shapeless are designed to do crazy type level stuff, taking their inspiration from type/group/set theory.

And yes, I agree Scala is the successor to Perl (but I have no problem with that :p )

Documentation for the Jane Street's Core Library looks incomplete or damaged (E.g. Core.Core_list module https://ocaml.janestreet.com/ocaml-core/latest/doc/core/Core...). I think, this is very unfortunate, because the labrary is probably great. I have not tried it yet (I'm pretty happy using just the standard one most of the time), but I whould like to have Async, Sexplib and other new things from Jane Street. Is there a better documentation for this lib?

The documentation generation tools are a bit of a mess at the moment. We're working actively with OCaml Labs to improve the tools here, and we expect to have the documentation in a much cleaner and easier to use state (and prettier) by publication time.

Thank you Yaron! The book looks great.

No I am not entering my Github credentials just to look at your book's website.

When we're out of beta, we'll open the book up for people to read without any kind of login. For now, though, we're putting this out there largely to get feedback before publication. Unfortunately, github has fairly coarse-grained permissions, so we need to ask for rather a lot.

It's a good effort as "Developing applications with Objective Caml" http://caml.inria.fr/pub/docs/oreilly-book/

has become rather dated.

But you will still need the reference manual and some other sources as it seems rather sketchy in some aspects (syntax extensions, C bindings)

(I've made lots of small comments in the book, hoping it may help)

Not much traffic on OCaml here lately, compared to the "new stuff" and what appears to be a resurgent interest in Erlang. So this is an interesting project

In this era of Scala, Clojure, F#, (and Erlang), what use cases of OCaml would interest developers to dive into it?

Its also interesting there are two new OCaml books of recent: http://ocaml-book.com/

Does anyone have some good reading material to start getting into functional languages?

This book is one route in. It's intended for those who've programmed before but not necessarily with functional languages. I suspect intros to any of the functional languages would be fine (e.g Haskell, Scala, F#). There's even a Coursera course on Scala.

Reply on news.ycombinator.com