Bayle Shanks's website: notes-computer-programming-programmingLanguageDesign-prosAndCons-ocaml

http://evan-tech.livejournal.com/136436.html

intro examples

http://queue.acm.org/detail.cfm?id=2038036

opinions

" M: I have a question about research in language design. It's interesting for instance that Java is very much hyped and the community is split among the merits and flaws of the language. The language has indeed acquired some nice features proposed by researchers in the area (like garbage collection), but also the researchers point some of its weaknesses (like the arrays which are covariant and they shouldn't be). There's a whole body of research done in programming languages nowadays, and a very interesting body of research in functional programming languages, but you don't see this research to really influence the real world, i.e. what people are really using on an everyday basis. Instead all sorts of ad-hoc languages pop up like Perl or Python or stuff like that. Where do you see the fault; what's not right?

K: That is unfortunately a very good question, and there's a certain amount of discussion here at Bell Labs between a very strong group in functional programming languages and a group using very much ad-hoc, pragmatic languages. I honestly don't know why the functional languages don't succeed. For instance ML, which is arguably the best combination, perhaps the one that ought to succeed: in spite of being a very well designed language, thought hard about by a lot of good people over a very long time, embodying an enormous amount of effort of compiler technology, still does not seem to be broadly used. I will oversimplify a lot, and probably offend my friends, by saying that the only thing people do with ML is to make ML compilers. [laughing] I'm overstating intentionally, but it has some of that flavor, and I don't really understand why. I think, speaking only for myself, part of the reason that ML in particular, and functional programming languages in general have not caught on more broadly, is that they're aimed at people who have mathematical sophistication, who are able to think in more abstract ways, that lots of other folks, and I include myself, have trouble with. Whereas languages like C are very operational, you can see how every single piece of them maps into what's going on in the machine in a very very direct sense. If I had been brought up at a different time and in a different environment perhaps I'd be totally comfortable in ML and would find C unsafe, a little dangerous, not very expressive. But my sense is that the functional languages come out of a fairly mathematical community and require a fairly mathematical line of reasoning and therefore are difficult for the people on the street.

M: So I guess, the suggestion is for the researchers to somehow lower the language level, to promote the good qualities?

K: I didn't really answer the other part of your question, why research in languages has not had as much effect as it should have. I think actually it has had an effect, in places like parser technology, code generation, no matter what the language is: research had a big effect on building language tools but less on the design of languages per se.

The languages that succeed are very pragmatic, and are very often fairly dirty because they try to solve real problems. C++ is a great example of a language that in many ways has serious flaws. One of the flaws is that it tried very hard to be compatible with C: compatible at the object level, compatible very closely at the source level. Because of this there are places where there's something ugly in the language, weird syntactic problems, strange semantic behaviors. In one sense this is bad, and nobody should ever do that, but one of the reasons that C++ succeeded was precisely that it was compatible with C, it was able to use the C libraries, it was usable by the base of existing C programmers, and therefore people could back into it and use it fairly effectively without having to buy into a whole new way of doing business. And this is not the case for ML, which was being done at about the same time and, at least partly, in almost the same place, but which took a very different view of the world. As a pragmatic thing, C++ is extremely successful but it paid a certain price by being compatible with the previous language.

" -- http://www.cs.cmu.edu/~mihaib/kernighan-interview/

---

" The binary ended up a bit bigger than I’d like. Adding the GTK and OBus libraries in particular added a lot to the size (though they are optional). The main problem with GTK is that it has to be compiled as a plugin, because we don’t know if the target system will have libgtk. If we used a single binary and the library wasn’t present, it would refuse to start. By having it in a plugin we can try to load it, but fall back to console mode if that fails. However, compiling for plugins prevents OCaml from optimising the binary by removing unused library functions, since it doesn’t know which ones might be needed by the plugins.

The binary is compiled with debug symbols, but compiling without has almost no effect (binary becomes 1.5% smaller). "

" The ocamlbuild command automatically discovers dependencies and rebuilds only what is needed, so incremental builds are usually fast and are generally reliable (the exception is that it doesn’t notice if you remove or rename a file, but you always get an error message in that case rather than an incorrect build).

Most errors are picked up by the type checker immediately at the start of the build, rather than by the unit-tests at the end. That saves a lot of time. "

" Two things did speed it up slightly: building the tests and the main binary with a single invocation (saves having to run the dependency checker twice) and turning on parallel builds. Parallel builds didn’t help as much as I’d hoped however.

Update: edwintorok profiled the build and noticed that 25.5% of the time is spent running a bytecode version of the camlp4 pre-processor (which we use for the Lwt syntax extension and for conditional compilation) and 10.5% is spent on a bytecode version of ocamlfind (looks like an ocamlbuild bug). Why ocamlbuild’s parallelization is often disappointing today looks interesting too. "

There are some changes (module aliases) coming in OCaml 4.02 which should help. Currently, if I change one of the files in the Support module (e.g. Support.Sat) then it first rebuilds Sat, then rebuilds Support with the new Sat module, then rebuilds everything that uses Support (which is everything). In reality, it only needs to rebuild Zeroinstall.Solver when Sat changes. "

" If you do need to modify one of the early modules and run the unit tests quickly, a good trick is to compile to byte-code rather than to native. The byte-code compiler doesn’t do cross-module inlining optimisations, which means that as long as a module’s interface doesn’t change, it doesn’t need to recompile the things that depend on it. "

" It’s surprising to me how reliable the initial tests were. Even though I only converted 4 lines of Python, the tests uncovered pretty much all of OCaml’s weaker aspects (non-portable bytecode, lack of support for shared libraries, relatively large binary size, and somewhat terse error messages from the standard library), meaning there were no nasty surprises during the migration.

However, the testing was less successful at uncovering the benefits (excellent type checking, reliability, exhaustive pattern matching, polymorphic variants, abstract types, easy GTK bindings, and API stability). "

"Instead, the OCaml created a pair of pipes and spawned a Python subprocess. You need to use two pipes, not a single socket, because Windows doesn't support Unix sockets.

The protocol was asynchronous (replies can arrive out of order). Although the original JSON bridge is now gone, the new "0install slave" command (which allows other programs to control a 0install subprocess) uses a very similar system. It's documented here:

http://0install.net/json-api.h... "

gnuvince 4 days ago

link

As a language, OCaml gets most things right: being functional by default appeals to me very much, as does the easy path into imperative programming when you need it. Its type system is awesome not only at catching bugs at compile-time, but also at guiding you in your design. There are a couple of nice-to-have that would be cool though: Haskell-like type classes come to mind, and some minor syntax warts could be improved. Its implementation is also extremely solid: I always expect the code generated by OCaml to perform well. With tools like OPAM, getting the latest compiler and libraries is very easy. Definitely one of my favorite language toolset.

_random_ 4 days ago

link

And there is always an option of using F# when needed.

jordwalke 4 days ago

link

Here's a copy of a previous post I've made on HN about why you might want to choose OCaml instead of another language. Nothing has changed about my opinion since the time I wrote it: Original link: https://news.ycombinator.com/item?id=7766315

A couple of people have asked why you might choose OCaml over other languages. I've not done as much OCaml work as others on this thread (I work primarily on ReactJS? (Facebook/Instagram's) functional UI framework), but I can offer a different perspective as someone who is outside of the OCaml community, but asking the same questions. Here are some of my personal findings. I'll narrow any comparison down to the ML family of languages. Java/C++/ and many other languages are just now beginning their slow, but inevitable evolution into becoming a dialect of ML (which IMHO is a sort of admission of the ML/functional family superiority). Once you embrace the power of pattern matching, it's hard to use anything but an ML family language (StandardML?/Haskell/F#/OCaml). I would program in any one of those languages over Java/C++/Objective-C/JS. Practical reasons why you might choose OCaml:

OCaml's records aren't as elegant as SML's but OCaml has labeled arguments with optional default values which can satisfy many of the reasons why you'd use records as arguments in the first place (and may be even more powerful in some cases).
Two modes of compilation (fast native executable XOR fast compilation). Who doesn't like options.
All the benchmarks I can find show that OCaml is very fast (around as fast as C++).
Excellent JS target and and apparent commitment to maintaining it (as someone building a JS library, this is very important to me) (and as someone who wants to build apps and be able to instantly share them with everyone in the world.)
Someone has built an autocomplete plugin for Vim/Emacs (merlin). ("VimBox?" (https://github.com/jordwalke/VimBox/) has configured it to complete as you type - like in Visual Studio etc.)
On very rare occasion, you'll run into a problem that is inherently better suited to OO (dynamic dispatch). I can usually find a way to solve it with functors/modules, but it's nice to know that you have OO in your back pocket in case you ever need it. It's also nice to know you probably won't have to.
Finally, a common package manager (OPAM) is becoming standard. I look forward to seeing how OPAM helps make the new dev experience and the code-sharing/development experience seamless.
The module system is very powerful (SML's). Haskell does not have this, and strangely F# dropped it. (I hear, Haskell's type classes fulfill similar roles (but with more sugar)).
There's usually ocamlyacc grammars for most languages. Most examples of languages, type systems, parsers are already in OCaml (or ML). It's a nice (but small) perk.
Predictability. OCaml is not lazy by default. Lazy computations could become problematic for low-latency applications (such as UIs) if a lot of computation becomes is deferred until the moment a final dependency has been satisfied, but by that time you may be close to your screen refresh deadline and it may lead to a dropped frame. It would have been better to have been computing while waiting for a final dependency. I'm not sure if Haskell (a lazy language) has had this problem. You can opt into laziness in OCaml if you would like to.
Mutability. I feel strange saying this, as such a huge proponent of immutability, but sometimes you just need to hack something in place, mutate some state and come back to clean it up later. (You can still use monads in OCaml).
Tagged Variants (no need to predeclare variants, just pattern match on them and OCaml ensures that only properly matched values ever make their way into that expression).
Industry use is growing. OCaml is used here at Facebook and many other places as mentioned.
There are many abstractions to choose from (Records, Objects, Modules, Functors, First Class Modules, GADTs, ...).

OCaml Cons: - There are many abstractions to choose from (Records, Objects, Modules, Functors, First Class Modules, GADTs, ...). (Edited for formatting)

Paradigma11 3 days ago

link

"- The module system is very powerful (SML's). Haskell does not have this, and strangely F# dropped it. (I hear, Haskell's type classes fulfill similar roles (but with more sugar))."

F# runs on the standard .net type system which is not able to do type classes, modules or higher kinded generics. On the other hand you have compatibility to all .net libraries which is a huge plus.

thinkpad20 2 days ago

link

Ocaml is very enticing in many ways, with a lot of the features I love about Haskell; a few that are missing but also several that are not present in Haskell. Certainly, the strictness is a big plus for me, and being able to do mutability and IO without a monad (purity isn't as important to me). I've been averse to picking it up because I've invested so much time and effort in Haskell, because I'm used to the Haskell way of FP, and because I much prefer haskell's syntax. But maybe if I just dived in, then I'd find I even preferred it to Haskell.

codygman 2 days ago

link

I've actually thought about ocaml myself, but one silly thing keeps putting me off. It feels like typing "let" over and over again would drive me crazy!

I guess it's not that bad after looking at this for example:

https://github.com/0install/0install/blob/master/ocaml/zeroi...

---

"OCaml’s main strengths are correctness and speed. Its type checking is very good at catching errors, and its “polymorphic variants” are a particularly useful feature, which I haven’t seen in other languages. Separate module interface files, abstract types, cycle-free dependencies, and data structures that are immutable by default help to make clean APIs.

Surprisingly, writing GTK GUI code in OCaml was easier than in Python. The resulting code was significantly shorter and, I suspect, will prove far more reliable. OCaml’s type checking is particularly welcome here, as GUI code is often difficult to unit-test.

The OCaml community is very good at maintaining API stability, allowing the same code to compile on old and new systems and (hopefully) minimising time spent updating it later."

talex5 3 days ago

link

It is a joy when you get used to it, but it's not as immediately accessible as Python. As I recall, my first hour or so with OCaml was full of frustrating syntax errors. Keep going though, it's worth it!

One thing I don't think the tutorial mentions, but which helps a lot, is turning on all warnings ("-w A"). The tutorial also fails to mention ocamlbuild, so you start by compiling things manually, which makes everything harder than it should be.

---

ocaml has the 'assert' escape hatch from the type system:

" If something can't be type-checked then you just add an "assert" and do the check dynamically.

For example, in 0install I need to ask the SAT solver which version of a program I should use. I pass it a load of SAT variables, each containing a user data field with the attached program details, run the solver, and get back the selected variable. The SAT problem also contains other variables, with other kinds of data.

I know the user data field for the selected result will be of type program details, but I couldn't figure out how to let the compiler check this statically. It's not a problem; I just check the type and "assert false" if it's wrong. I still get the benefit of static checking almost everywhere else in the code. "

---

orthecreedence 3 days ago

link

Common Lisp guy gonna chime in here...having a REPL that integrates with your editor (vim/slimv in my case) is an intense improvement on any other language I've ever used. With C you edit, leave, `make`, run. With PHP you edit, open browser, F5, run...same with JS.

With lisp, I edit, eval (simple command in my editor), see result. If I'm building a game or a long-running app, I can redefine functions while it's running without doing a full recompile and having to try and get back to the state the app was in when I wanted to test my change.

So you get the ability to live-code while the app is running. Once you get used to being able to do this, leaving your editor and opening to shell to test your app seems like a barbaric exercise.

So a good REPL (lisp or not, doesn't matter) can make the experience a lot more interactive and experimental that your average write -> save -> compile -> run cycle.

gsg 3 days ago

link

Unfortunately the OCaml toplevel pales in comparison to CL environments like slime in terms of visibility and debuggability. Redefinition is also off the table, as OCaml is a very static language. (You can rebind the same name, which can be helpful in exploratory programming but is not at all the same thing.)

It remains an extremely useful tool though.

nathell 117 days ago

link

I have very fond memories of OCaml. It was OCaml that introduced me to functional programming, way back in 2000 in my freshman year at the uni. I'm a Lisper/Clojurian these days, but I think warmly of OCaml's type system, the speed, the self-containedness of the distribution, and the fact that getting the code to compile tends to mean getting it to actually work.

My #1 gripe with OCaml is the fact that its strings are composed of single-byte characters. I know there's Camomile, but not having it as part of the language core creates a sense of disintegration akin to PHP and Python 2.

There's also this: http://www.podval.org/~sds/ocaml-sucks.html which I mostly agree with.

But, all in all, OCaml rocks.

http://www.podval.org/~sds/ocaml-sucks.html

stock_toaster 16 hours ago

link

  > OCaml has the advantage of offering very good performance
  > while not having to deal with the borrow checker

My understanding was that OCaml had no support for parallelism -- so a single core is all you get. Is that not the case?

masklinn 15 hours ago

link

OCaml does have concurrency and parallelism support, but it has a GIL so their effectiveness is somewhat limited unless you go multiprocess.

I believe there are serious efforts towards removing the GIL these days.

swah 11 hours ago

link

Does OCaml still doesn't compile 1.0 + 2.0 or has that changed?

Small stuff like this really bother some people and they fly off to Pythonland never to be seen again.

edorrington 10 hours ago

link

I think he's talking about the fact that OCaml has separate operators for floating point (i.e. in his example, you'd use 1.0 +. 2.0).

scardine 5 hours ago

link

I think most ML implementations still have poor support for unicode, and this is a killer feature for me.

" Why bring this up? Apart from general grousing, my point is that we had little choice in what language to use in teaching our students. Modularity matters most, and we must have a language that supports flexible modularity in the form I am describing here. When we examined our options, which we did very carefully, the only contenders are Standard ML and O’Caml?. We could have gone with either, but were persuaded to use Standard ML, which has worked beautifully for our purposes. The decisive factor in choosing between the two ML’s was simply that we have a prior code base in Standard ML on which to draw, and there are two implementations of Standard ML that support parallelism (MLton and Poly/ML), albeit neither optimally for our purposes. Haskell provides better support for parallelism (by undoing its unfortunate commitment to laziness, which results in an unusable cost model for both time and, especially, space), but wasn’t suitable because of its lack of support for modularity. " -- http://existentialtype.wordpress.com/2011/04/16/modules-matter-most/