6 ms·
I'm surprised people care about the syntax... that's pretty much the least important part of the language. I've got a few issues with OCaml 1. The standard li
by yodsanklai 4y ago
I'm surprised people care about the syntax... that's pretty much the least important part of the language.
I've got a few issues with OCaml
1. The standard library is inconsistent. Different projects use different alternatives and it's annoying to switch between then.
2. Concurrency using Lwt/Async. Monads feel more ad-hoc in OCaml than Haskell because there's no type classes and again no consensus on how it should be done. Some projects use tons of variation of `>>=`, other use `let%bind`. Again, no clear consensus and reliance on external libraries which aren't always well documented. I find code relying too much on monads to be much less elegant and simple that plain OCaml.
3. "includes". I tend to get lost in codebase which abuse includes.
4. It's a small community. If you want to work on "real world" stuff, most likely you will stumble into tooling/libraries issues. Not all of these things are very mature or documented and they're evolving fast.
I'm wondering if F# suffers from the same issues.
- dmitriid 4y ago> I'm surprised people care about the syntax... that's pretty much the least important part of the language. Until the syntax starts impeding with your understanding of the code, or is impossible to look up in documentation/google. OCaml IMO is a bit over the line with the number of ascii art used. I definitely agree with your other points. Though I only touched OCaml very briefly.
- momentoftop 4y ago> Some projects use tons of variation of `>>=`, other use `let%bind` It gets better. Since 4.08, the preference would be `let*`.
- hvs 4y agoF# has the entire .NET library available, so that won't be an issue.
- oaiey 4y agoI was surprised that the article mentions dozen of languages but no word of F# which is a mainstream clone/derivate of OCaml. Especially considering exactly that point.
- lf-non 4y agoI think that's understandable. Those dozens of the languages are the ones that the author has personally dabbled with in the past. The focus of article is their personal experience & first impressions. It was not intended to be an exploration of what else is available in the market and how ocaml compares to them.
- adelarsq 4y ago1. For F# you can can use both .NET and JavaScript libraries (with tool called Fable), so isn't a issue. 2. There a lot of ways to the that, which one with pros and cons, but isn't a issue in my opinion 3. For imports there are a thing called AutoOpen that is strange at first. Just need to be carefull where to use 4. .NET documentation tend to be writed for C#. So you need to understand at least a little of C# if you want to use that libraries. But also there are a lot that can be use idiomaticaly with F#, so isn't a big issue.
- devmunchies 4y agosyntax doesn't typically matter as long as you are at least as productive as in other languages. i.e. if editors can do the same things with keybindings. The problem with the (* *) comments is that I can select a block of text, a portion of which is already commented out, and commented the whole selection. You can't solve this without lossy commenting (e.g. removing the inner comment). The portion that is already commented will screw it up. This doesn't matter in single line comments since it will just add an additional "//" in front of a commented line.
- pie_flavor 4y agoDoes OCaml not have nested comments? Typically a language supporting /* */ will treat them like parentheses and require each opener to match a closer. (Not that this doesn't make documenting the behavior of files/static/* harder - hence Rust and C# preferring to document with line comments.)
- octachron 4y agoOCaml has nested comments (and comments are also aware of string literals). Thus any fragments of valid OCaml code can be commented without changes. In other words, the whole line below is commented-out. (* let x = "*)" (* inner comment *) *)
- folmar 4y ago> Typically a language supporting /* */ will treat them like parentheses This is not the case for C, C++ or JavaScript for a start.
- mattpallissard 4y agoI think your comment is the most accurate depiction of the warts. Yeah, the standard library is inconsistent, and they don't seem keen to merge in some features when they're readily available in other libraries. Plus there are some odd implementation details in the Unix module (for example, read/write and friends) at the C level that don't seem to get much traction on fixing despite fairly clear paths to resolution. I personally don't care about the difference between binding something to a variable and the infix operator. What I don't like are the multiple concurrency stories, this is similar to the problem seen with the standard library vs janestreet's. Although with the module system being what it is it's usually not too big a deal to support either concurrency library (even though some libraries force you to use one or the other). Although I'm hopeful that with multicore finally being a real thing, the community will settle on a single concurrency library that can be pulled into the standard library in the future. Despite the issues, it is still my favorite language.
- freedomben 4y ago> I'm surprised people care about the syntax... that's pretty much the least important part of the language. Eh, I don't think I can agree. There are definitely more important things about a language than syntax, but a language with a great syntax can be a lot more enjoyable to use, particularly when reading a lot of code. Prior to learning Ruby I would have agreed with you, but since Ruby and Elixir, the syntax adds much to my enjoyment of working with the language. When I think of ES7 v. ES5 I feel the same way as well. You can do everything in ES5, but in ES7 the syntactical sugar makes it so much more enjoyable.
- phist_mcgee 4y agoI've found newbie JS devs do confuse the meanings of `=>` and `function` to mean the same thing in JS and think that it's just a sugar. I wonder if there's a nice way to 'unfold' sugars via a linter or something to explain in code the subtleties.
- bmitc 4y agoInteresting, because I find Elixir’s syntax to be rather busy, especially coming to it from F#. I love Elixir and Erlang, but Ruby’s influence on Elixir is probably my least favorite thing about Elixir.
- sideeffffect 4y agoTo be frank, any language's syntax is rather busy compared to F#. That language is setting the bar how beautifully a language can look. I don't know of any that comes close, not even Haskell or Python...
- bmitc 4y agoI definitely agree. F# is honestly the best designed modern language, in my opinion. I use it for most of my side projects.
- freedomben 4y ago
- goto11 4y ago> I'm surprised people care about the syntax... that's pretty much the least important part of the language. The syntax is the user interface of a language. It matters.
- kevinmgranger 4y agoI can't say I'm very familiar with OCaml, but I'm excited to see where multicore takes it regarding your second point.
- daxfohl 4y agoAs others have said, F# addresses these issues. The main complaint I have with F# is when using other dotnet libraries you end up having to deal with things like nulls again, which can make the F# feel more cumbersome than it should be. I still like it though.
- pjmlp 4y agoMy main complaint is that after all these years, Microsoft's management still seems not to have a clear picture what they want it for, althought it seems to have replaced Visual Basic in feature love for newer .NET versions.
- daxfohl 4y agoI worked in Azure for four years in a couple different teams. I didn't see a single line of F# code while I was there. I don't think they have any plan beyond supporting it as somebody's side project. Edit: I forgot about https://github.com/microsoft/qsharp-compiler https://github.com/microsoft/qsharp-compiler. IDK if any server code is in F#, but at least the compiler is.
- 0x457 4y agoSyntax is what you deal with every time you read or write in any language. It can't be "the least important". It's probably one of the most important part when you _read_ the code, and reading the code is an important part of programming. Just take a look at this: [1, 2; 3, 4] is the same as: [(1, 2); (3, 4)] That's just hard to read. I don't mind `;` being a separator, but tuples without parentheses is just annoying to look at in 9/10 places.
- yodsanklai 4y agoI agree the second form is preferable to the first one. But I think, most people will use the second form anyway. In my projects, ocamlformat chooses the second option. In the case of OCaml, we can certainly find a few oddities, but really, I never found the OCaml syntax to be such an issue or to make me unproductive in any way. I'm much more prone to syntax errors in Haskell actually. I suspect people who complain are mostly used to C-like syntax and aren't familiar with any language of the ML tradition. I agree that the barrier to entry would be lower if the syntax was more "mainstream", but I don't find there's really anything wrong with OCaml syntax, except that it's "different".
- 0x457 4y agoOh, I don't think Ocaml syntax is an issue at all, I like most of it. I'm saying that, syntax isn't the least important part of a language - look at how many languages compile to JavaScript without bringing anything new ("new" being something like types in TypeScript). > I suspect people who complain are mostly used to C-like syntax and aren't familiar with any language of the ML tradition Yes, that's probably it. Can't really blame them - C, C++, Java, C#, PHP been very popular for long time. When I first saw Erlang, I thought it's a language for aliens.
- Quekid5 4y agoThere was a Revised Syntax (not sure if it's still a thing) which smooths out some of the most egregious warts. It requires preprocessing, but it was part of the standard distribution last I looked. The most egregious for me was actually ;; being so close to ; to type and you'd be staring at weird type errors for ages before realizing what had gone wrong. I realize that this may be hard to convey to people who haven't used OCaml, but: The ;; terminates a top-level definition -- which was usually type-inferred when I was using OCaml... so it would lead to all sorts of "weird" type errors, when all that was missing was a simple ; EDIT: Just for context, last looked (seriously) at OCaml ~15 years ago, last wrote it ~20+ years ago. It's cool, but it ended up just being my gateway drug to Haskell... for which I thank it :)