[flagged]
OCaml Syntax Sucks (2016)
21–30 of 140 posts
Re: OCaml Syntax Sucks (2016)
#22As a matter of policy can HN please not accept submissions with non-https URLs?
It's a checkbox at most web hosts, built in to many reverse proxies, etc. There's no excuse for not offering htttps, particularly since it places users at risk if at any point along the path between them and you, there's someone untrustworthy.
Re: OCaml Syntax Sucks (2016)
#23Re: OCaml Syntax Sucks (2016)
#24Earlier quoted context omitted.
It's the other way around. 'async'-annotated methods in C# enable 'await'ing on task-shaped types. It is bespoke and async-specific. There is nothing wrong with it but it's necessary to acknowledge this limitation. let!, and!, return!, etc. keywords in F# are generic - you can build your own state machines/coroutines with resumable code, you can author completely custom logic with CEs. I'm not sure what led you to be…
I'm somewhat already aware of these considerations, it's just that when you're working in web development, a huge amount of your code is async and this means that a large part of the code is wrapped up in these computation expressions that I think are just plain ugly
What's so ugly about them? I don't code in F#, but I do in C# and after reading about them I wish C# had something similar.
Re: OCaml Syntax Sucks (2016)
#25Earlier quoted context omitted.
It's the other way around. 'async'-annotated methods in C# enable 'await'ing on task-shaped types. It is bespoke and async-specific. There is nothing wrong with it but it's necessary to acknowledge this limitation. let!, and!, return!, etc. keywords in F# are generic - you can build your own state machines/coroutines with resumable code, you can author completely custom logic with CEs. I'm not sure what led you to be…
> It is bespoke and async-specific. There is nothing wrong with it but it's necessary to acknowledge this limitation. I would disagree. If you need to have a bespoke set of syntax, then something is not integrated where it should be. The language design should not be such that you are writing things differently, depending on the paradigm that you're handling. That's not something that occurs in every language, so it…
I cannot make sense of this reply. Different languages have different syntax.
Support of asynchronous code and of its composition is central to C#, which is why it does it via async/await and Task (and other Task-shaped types). Many other languages considered this important enough to adopt a similar structure to their own rendition of concurrency primitives, inspired by C# either directly or indirectly. Feel free to take issue with the designers of these languages if you have to.
F#, where async originates from, just happens to be more "powerful" as befits an FP language, where resumable code and CEs enable expressing async in a more generalized fashion. I'm not sold on idea that C# needs CEs. It already has sufficient complexity and good balance of expressiveness.
Re: OCaml Syntax Sucks (2016)
#26Earlier quoted context omitted.
> 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)
As the other commenter pointed out, this isn't restricted to strongly-typed functional languages. 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…
> something like Golang's concurrency
That's wildly overselling it. Closure core async was completely incapable of doing the one extremely important innovation that made goroutines powerful: blocking.
Re: OCaml Syntax Sucks (2016)
#27Worked on an ocaml codebase for two years. My advice is: choose a different language. It's just not a great dev experience in general
> Worked on an X language codebase for two years. My advice is: choose a different language. It's just not a great dev experience in general.
I'm pretty sure it's "working on a codebase" that kills your soul, not the minutae of particular language choice.
Re: OCaml Syntax Sucks (2016)
#28I 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…
You might like Scala. It has much of the good parts of OCaml or F#, but also lets you write imperative code freely when you want. The `for`/`yield` syntax for async is very nice IMO, or you can write Javascript-like promise chaining directly if you want.
Some interesting things happening in the structured concurrency / "Direct style" space. It looks like it could become a powerful and readable way to compose (asyncy type) things. Simpler code, usable stack traces, better traceability, less function colouring concerns.
It's early days in that regard, with some folks doing some really interesting things: Odersky himself / the Ox project.
Re: OCaml Syntax Sucks (2016)
#29[flagged]
That's kinda his entire internet brand tho.
Re: OCaml Syntax Sucks (2016)
#30As a matter of policy can HN please not accept submissions with non-https URLs? It's a checkbox at most web hosts, built in to many reverse proxies, etc. There's no excuse for not offering htttps, particularly since it places users at risk if at any point along the path between them and you, there's someone untrustworthy.
> places users at risk
Help me out here, what's the threat model here while reading troll programming blogs?