I didn't interpret it as an argument about layers of abstraction. You need to be in the detail at the level you're writing (and it's certainly advantageous to know some of the detail of the abstractions below) because you're building abstractions on top of that, because the details subtly change at the base level you're building at, impacting the level that you're building to.
It might just be me, but I find his baroque style very readable. Despite using a vocabulary much broader than mine (irritating but admirable), he at least seems to have read his prose aloud, and considered how it's meter makes its meaning fluent.
I agree that many writers fill their works with needless diversions and unnecessary expositions on their life that add nothing to their text, but this is different from a "baroque style".
Not yet - it's mostly a build tool, but package management abilities (which is otherwised covered by opam) is being added to it^1. It's currently usable for some projects (and worth trying out), but still in preview mode.
Installing via opam and using the cygwin method is supported and should be working fine (cygwin is just used for build - binaries still just link with mingw).
That specific combination (ocaml + mingw) has a known problem with ocamlfind that's still awaiting a new release (see https://github.com/ocaml/ocamlfind/pull/112). ocamlfind underpins quite a bit of the package ecosystem, so this one is annoying, as the mingw workflow is otherwise quite good.
No where in Australia would you expect a fridge to be supplied as part of a tenancy. It does restrict what you can buy, as may removalists will not touch move a fridge if there’s too many stairs or if you can’t get it in the door
Genuine independence is almost impossible at this size, because you need a strong internal discipline to only rely on small donors, and not bend your organisation’s mission to keep larger donors
I think this because nonprofits are subject to a similar market discipline as companies: they compete for funding, relevance, market share etc.
And their board composition converges similarly as those same people are relied upon for their connections to fundraise, hire, etc. They don’t want to be seen taking an unusual strategy as it would be perceived as risky and jeopardising precious donated funds, so the same groupthink emerges.
Even if someone outside these circles was hired, they’d be knocked down with the smallest misstep, with the veiled criticism they weren’t suitable for the position (ie someone with better connections should have been chosen), so even they will fall into line.
Non profit organisations trying to remain relevant (or just survive) behave this way because they arent much different from companies operating in a market for profit.
Their leadership is often not that much different, with similar people working in similar jobs educated in the same institutions and walking in the same social circles, producing the same solutions to the existential problem of organisational survival.
This is probably the highlight of a visit to an otherwise unremarkable English seaside town. The chambers are very old (even by English standards) and so unlike anything else medieval that is still around.
It's interesting reading many of the associated comments, because there is a genuinely active effort to address many of the pain points of the language:
* Windows support has improved to the point where you can just download opam, and it will configure and set up a working compiler and language tools for you[^1]. The compiler team treat Windows as an first tier target. opam repository maintainers ensure new libraries and library versions added to the opam repository are compiled and tested for Windows compatibility, and authors are encouraged to fix it before making a release if its reasonably straightforward
* debugger support with gdb (and lldb) is slowly being improved thanks to efforts at Tarides
* opam is relatively stable (I've never found it "buggy and surprising"), but
there are aspects (like switches that behave more like python venvs) which don't provide the most modern behaviour. dune package management (which is still in the works) will simplify this considerably, but opam continues to see active development and improvement from release to release.
* the platform team (again) are working on improving documentation with worked recipes and examples for popular uses cases (outside of the usual compiler and code generation cases) with the OCaml Cookbook: https://ocaml.org/cookbook
There are other things I find frustrating or that I work around, or are more misperceptions:
* there isn't a builtin way to copy files because the standard library is deliberately very small (like Rust), but there is a significant ecosystem of packages (this is different to other languages which cram a lot into their standard library). The result is a lot of friction for newcomers who have to install something to get what they need done, but that's valued by more experienced developers who don't want the whole kitchen sink in their binary and all its supply chain issues.[^2]
* the type inference can be a bit of a love/hate thing. Many people find it frustrating because of the way it works, and start annotating everything to short-circuit it. I've personally found it requires a bit of work to understand what it is doing, and when to rely on it, and when not to (essentially not trying to make it do things it simply will never be able to do).[^3]
* most people use singly-linked lists because they work reasonably well for their use cases and don't get in their way. There are other data structures, they work well and have better performance (for where it is needed). The language is pragmatic enough to offer mutable and immutable versions.
* ocamlformat is designed to work without defaults (but some of them I find annoying and reconfigure)
Please don't take this as an apology for its shortcomings - any language used in the wild has its frustrations, and more "niche" languages like OCaml have more than a few. But for me it's amazing how much the language has been modernised (effects-based runtime, multicore, etc) without breaking compatibility or adding reams of complexity to the language. Many of these things have taken a long time, but the result is usually much cleaner and better thought out than if they were rushed.
[^1] This in itself is not enough, and still "too slow". It will improve with efforts like relocatable OCaml (enabling binary distribution instead of compiling from source everywhere) and disentangling the build system from Unixisms that require Cygwin.
[^2] I particularly appreciate that the opam repository is actively tested (all new package releases are tested in a CI for dependency compatibility and working tests), curated (if its too small to be library, it will probably be rejected) and pruned (unmaintained packages are now being archived)
[^3] OCaml sets expectations around its type inference ("no annotations!") very high, but the reality is that it relies on a very tightly designed and internally coherent set of language constructs in order to achieve a high level of type inference / low level of annotation, but these are very different to how type inference works in other languages. For example, I try and avoid using the same field name in a module because of the "flat namespace" of field names used to infer record types, but this isn't always possible (e.g. generated code), so I find myself compensating by moving things into separate modules (which are relatively cheap and don't pollute the scope as much).
I also find languages like OCaml avoid a lot of this nonsense in their libraries because the ability to build layers and layers of complex abstraction isn’t there in the same way as Haskell, Rust, or any of the LISPs
This resonates. I spent a fair bit of time thinking about library design for an OCaml library that didn’t directly expose more complicated language features (like functors and first class modules) where they weren’t needed.
The ICFP/SPLASH papers are now starting to find their way to HN.
This was a HUGE combined programming conference with several competing tracks over 7 days. You can find the program here ^1 (you can often find a link to the abstract or full paper if you click on it)
Streams from the sessions will also show up here^2 (you’ll need to match the day and room and ff to the time it appeared)