Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OCaml Syntax Sucks (2016)

xahlee.info

Post reply on HN
Print view View original

131–140 of 140 posts

Re: OCaml Syntax Sucks (2016)

#131

Post by SkiFire13 »

nsonha wrote: post #129
SkiFire13 wrote: post #83

Another thing I personally hate about OCaml's syntax is the order of generic parameters being backwards. I know why it's like that, but it still doesn't make any sense to me both as a programmer and as a non-native english speaker.

I'm not even an ocaml dev and I prefer how it reads and types to that of C family generics.

Would you mind expanding on why do you prefer it? I'm not too focused on e.g. not using angle brackets, which is pretty common in the C family (though funnily enough they are not used in C), but rather on the order with type arguments being before the generic type, for example the type of lists of integers being `int list` rather than `list int`.

Re: OCaml Syntax Sucks (2016)

#132

Post by nsonha »

SkiFire13 wrote: post #131
nsonha wrote: post #129

Earlier quoted context omitted.

I'm not even an ocaml dev and I prefer how it reads and types to that of C family generics.

Would you mind expanding on why do you prefer it? I'm not too focused on e.g. not using angle brackets, which is pretty common in the C family (though funnily enough they are not used in C), but rather on the order with type arguments being before the generic type, for example the type of lists of integers being `int list` rather than `list int`.

My mother toungue has the reverse order to English grammar too, but I've spoken English long enough for that to not matter. If we're talking about, say, consistency with function syntax, then to me a function is a verb, and a type is a noun, hence still consistent.

I mentioned the typing experience because I hate to have to 1. open and close braces 2. press shift while typing

[2] is also the reason I prefer generics in python and scala than that of java and C#

Re: OCaml Syntax Sucks (2016)

#133

Post by seanwilson »

nsonha wrote: post #127
seanwilson wrote: post #63

Earlier quoted context omitted.

I think typing ergonomics are overlooked as well. CSS has the most verbose syntax for variables I've had to use regularly e.g. `var(--primary-color)` which I find unpleasant to type when experimenting. And I actually like the lack of brackets and commas in OCaml for function e.g. you write `add_numbers 1 2` instead of `add_numbers(1, 2)`. Brackets and commas in particular require you to navigate left/right a lot to a…

var(-- sounds like the person who writes the parser was either too lazy or sucks at his job so they asked the spec writer to give them a break.

I'd be interested in a link about this (can't find one from a quick look), but guessing it's to do with avoiding clashes with names in existing tools/code and backwards compatibility in browsers. In Sass, you would just write $primary-color, but if they copied that syntax exactly, it's likely going to get confusing for Sass tools if it's a Sass variable or a CSS variable.

Re: OCaml Syntax Sucks (2016)

#134

Post by koito17 »

Blackthorn wrote: post #99
koito17 wrote: post #55

Earlier quoted context omitted.

Assuming "blocking" refers to parking goroutines, then blocking is possible. (let [c (chan)] ;; creates channel that is parked forever (go ( The Go translation is as follows. c := make(chan interface{}) // creates goroutine that is parked forever go func() {

No, blocking refers to calling a function that blocks. Core.async can't handle that because macros are actually not capable of handling that, you need support from the runtime. Call a function that blocks in go, the routine will park. Do that in Clojure and the whole thing stalls.

Assuming "function that blocks" means "the carrier thread must wait for the function to return" and "the whole thing" means the carrier thread, then core.async doesn't really have this issue as long as e.g. a virtual thread executor is used.

There is a caveat where Java code using `synchronized` will pin a carrier thread, but this has been addressed in recent versions of Java.[1]

[1] https://openjdk.org/jeps/491

Re: OCaml Syntax Sucks (2016)

#135

Post by frankie_t »

RandomThoughts3 wrote: post #80
frankie_t wrote: post #66

I've recently started a mini-project in OCaml, having some Haskell background. The worst thing so far is that you have to declare and define functions before using them. This results in unimportant utility functions being at the top, and the most important functions being at the bottom of a file. I haven't had much issue with let bindings, however that might be because my functions are fairly simple for now.

> The worst thing so far is that you have to declare and define functions before using them. That's an extremely good thing. Unordered definitions and where are some of Haskell worst decisions with lazy by default, overuse of operators and a community which sadly think point-free is desirable. That's the kind of choices which makes Ocaml a lot more readable.

I guess it's a matter of taste, for me reading the generics and big picture first is more important than the details. Maybe it's my programming skills, but my files start with some five or ten string manipulation utilities and helpers. I honestly do not even care about their implementation, a name would suffice. Which is why I also like `where` approach much more than `let ... in`: it allows you to read the general idea, postponing the details to later (if you want to go into them).

However, I agree on laziness, operators and point-free.

Re: OCaml Syntax Sucks (2016)

#136

Post by Blackthorn »

koito17 wrote: post #134
Blackthorn wrote: post #99

Earlier quoted context omitted.

No, blocking refers to calling a function that blocks. Core.async can't handle that because macros are actually not capable of handling that, you need support from the runtime. Call a function that blocks in go, the routine will park. Do that in Clojure and the whole thing stalls.

Assuming "function that blocks" means "the carrier thread must wait for the function to return" and "the whole thing" means the carrier thread, then core.async doesn't really have this issue as long as e.g. a virtual thread executor is used. There is a caveat where Java code using `synchronized` will pin a carrier thread, but this has been addressed in recent versions of Java.[1] [1] https://openjdk.org/jeps/491

The post I was replying to included explicit mention of ClojureScript, where this does not exist. As it did not for Java for most of core.async's existence. And of course, for virtual threads, that's very much "special support from the language"!

Re: OCaml Syntax Sucks (2016)

#137

Post by koito17 »

Blackthorn wrote: post #136
koito17 wrote: post #134

Earlier quoted context omitted.

Assuming "function that blocks" means "the carrier thread must wait for the function to return" and "the whole thing" means the carrier thread, then core.async doesn't really have this issue as long as e.g. a virtual thread executor is used. There is a caveat where Java code using `synchronized` will pin a carrier thread, but this has been addressed in recent versions of Java.[1] [1] https://openjdk.org/jeps/491

The post I was replying to included explicit mention of ClojureScript, where this does not exist. As it did not for Java for most of core.async's existence. And of course, for virtual threads, that's very much "special support from the language"!

> where this does not exist

Because JavaScript runs an event loop on a single thread. It's akin to using GOMAXPROCS=1 or -Dclojure.core.async.pool-size=1 . There may be semantic differences depending on the JavaScript engine, but in the case of web browsers, the only function that could possibly stall the event loop is window.alert. As for Node.js, one would have to intentionally use synchronous methods (e.g. readFileSync) instead of the default methods, which use non-blocking I/O.

When using core.async in ClojureScript, one could use the I would call this "making use of the platform" rather than "special support from the language". The core.async library does not patch or extend the base language, and the base language does not patch or extend the platform it runs on.

Re: OCaml Syntax Sucks (2016)

#138

Post by gsuuon »

frankie_t wrote: post #66

I've recently started a mini-project in OCaml, having some Haskell background. The worst thing so far is that you have to declare and define functions before using them. This results in unimportant utility functions being at the top, and the most important functions being at the bottom of a file. I haven't had much issue with let bindings, however that might be because my functions are fairly simple for now.

This is generally a pro for me. I can skip to the bottom of a file and see what the main purpose of it is, knowing that it's the only place that could reference everything else in the file.

Re: OCaml Syntax Sucks (2016)

#139

Post by switchbak »

lanthissa wrote: post #84
lmm wrote: post #19

Earlier quoted context omitted.

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.

Scala is great, nearly all of its constructs were right and right early. Kotlin/Java catching up before it got popular kinda nixed its growth and at this point i dont see it being chosen for new projects. Gleams a nice one too if you want pure functional, small community though.

I've been hacking Scala for ... 15 years now, and sadly I have to concur.

Re: OCaml Syntax Sucks (2016)

#140

Post by alurm »

KennyBlanken wrote: post #22

As 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.

https doesn't make content trust worthy.
Post reply on HN