OCaml Syntax Sucks (2016)
11–20 of 140 posts
Re: OCaml Syntax Sucks (2016)
#12The title is a little inflammatory. The critique is specifically about Ocaml’s handling of let-bindings. AFAICT OP thinks the syntax sucks because: 1. there’s no marker to indicate the end of let scopes 2. functions are bound with the same syntax as constants He asserts that this is confusing. In practice - for the many issues I have with Ocaml! - neither of these are actual issues, in my experience, once code format…
- Reason, a different syntactic frontend for regular OCaml: https://reasonml.github.io/
- ReScript, a language with OCaml semantics that compiles into: JS https://rescript-lang.org/ (I suppose it's a reincarnation of js-of-ocaml).
Re: OCaml Syntax Sucks (2016)
#13idk mate, his guide to pick prostitutes has more compelling argument compared to this article. i mean, almost all the time ocaml users don't write their stuff "nested".
Re: OCaml Syntax Sucks (2016)
#14Worked on an ocaml codebase for two years. My advice is: choose a different language. It's just not a great dev experience in general
Re: OCaml Syntax Sucks (2016)
#15I want to like OCaml, but the tooling isn't great and async operations require a library to work for some reason. I tried f# but if you want to do async operations there, you have to do them in these even weirder "computation blocks" with this annoying ! Syntax. I've found that the best way to write ML family programs is to let an imperative language handle IO and then write any more mathematically or logically compl…
> async operations require a library to work for some reason Rephrased: ocaml is so flexible that async can be implemented as a library with no special support from the language. This is the beauty of ocaml (and strongly typed functional languages more broadly)
I don't think that's anything specific to strongly typed functional languages. In eg Rust even the standard library relies on third party crates.
Though it is still somewhat amusing to me that loops in Haskell are delivered via a third party library, if you ever actually want them. See https://hackage.haskell.org/package/monad-loops-0.4.3/docs/C...
I do agree that it's good language design, if you can deliver what would be core functionality via a library.
Whether you want to integrate that library into the standard library or not is an independent question of culture and convenience.
(Eg Python does quite well with its batteries-included approach, but if they had better dependency management, using third party libraries wouldn't be so bad. It works well in eg Rust and Haskell.)
Re: OCaml Syntax Sucks (2016)
#16Re: OCaml Syntax Sucks (2016)
#17idk mate, his guide to pick prostitutes has more compelling argument compared to this article. i mean, almost all the time ocaml users don't write their stuff "nested".
Link? I tried to look around the site, but I.. couldn't take very much of it.
http://xahlee.org/Periodic_dosage_dir/las_vegas/20031015_cop...
Found it via Google
Re: OCaml Syntax Sucks (2016)
#181. It’s whitespace insensitive, which means I can code something up really messy and the code formatted will automatically fix it up for me.
2. In general there aren’t a ton of punctuation characters that are very common, which is great for typing ergonomics. Don’t get me wrong, there are still a lot of symbols, but I feel compared to some languages such as Rust, they’re used a lot less.
Beyond the syntax, there are a couple of things I really like about the language itself:
1. Due to the way the language is scoped, whenever you encounter a variable you don’t recognize, you simply have to search in the up direction to find its definition, unless it’s explicitly marked as “rec”. This is helpful if you’re browsing code without any IDE tooling, there’s less guessing involved in finding where things are defined. Downside: if the “open” keyword is used to put all of a module’s values in scope, you’re usually gonna have a bad time.
2. The core language is very simple; in general there are three kinds of things that matter: values, types, and modules. All values have a type, and all values and types are defined in modules.
3. It’s very easy to nest let bindings in order to help localize the scope of intermediate values.
4. It has a very fast compiler with separate compilation. The dev cycle is usually very tight (oftentimes practically instantaneous).
5. Most of the language encourages good practice through sane defaults, but accessing escape hatches to do “dirty” things is very easy to do.
6. The compiler has some restrictions which may seem arcane, such as the value restriction and weak type variables, but they are valuable in preventing you from shooting yourself in the foot, and they enable some other useful features of the language such as local mutation.
Re: OCaml Syntax Sucks (2016)
#19I want to like OCaml, but the tooling isn't great and async operations require a library to work for some reason. I tried f# but if you want to do async operations there, you have to do them in these even weirder "computation blocks" with this annoying ! Syntax. I've found that the best way to write ML family programs is to let an imperative language handle IO and then write any more mathematically or logically compl…
Re: OCaml Syntax Sucks (2016)
#20I want to like OCaml, but the tooling isn't great and async operations require a library to work for some reason. I tried f# but if you want to do async operations there, you have to do them in these even weirder "computation blocks" with this annoying ! Syntax. I've found that the best way to write ML family programs is to let an imperative language handle IO and then write any more mathematically or logically compl…
> async operations require a library to work for some reason Rephrased: ocaml is so flexible that async can be implemented as a library with no special support from the language. This is the beauty of ocaml (and strongly typed functional languages more broadly)
Clojure has core.async, which implements "goroutines" without any special support from the language. In fact, the `go` macro[1] is a compiler in disguise: transforming code into SSA form then constructing a state machine to deal with the "yield" points of async code. [2]
core.async runs on both Clojure and ClojureScript (i.e. both JVM and JavaScript). So in some sense, ClojureScript had something like Golang's concurrency well before ES6 was published.
[1] https://github.com/clojure/core.async/blob/master/src/main/c...
[2] https://github.com/clojure/core.async/blob/master/src/main/c...