Live data from Hacker News

Flix – A powerful effect-oriented programming language

flix.dev

151–160 of 197 posts

Re: Flix – A powerful effect-oriented programming language

#151
post #148
post #129

Earlier quoted context omitted.

"Controversial: Flix defines division by zero to equal zero." Wait what. Can I read up on the motivation somewhere?

The FAQ ( https://flix.dev/faq/#:~:text=Dividing%20by%20zero%20yields%... ) links to https://www.hillelwayne.com/post/divide-by-zero/ , which is more about Pony, but links to https://xenaproject.wordpress.com/2020/07/05/division-by-zer... which properly explains that it's helpful for proof assistants to define division by zero, with particular reference to Lean. Really it's defining a division-like function (Lean cal…

Ah thanks for the insights and references. And yes I'm still curious why this definition of div/0==0 is needed in the context of Flix

Re: Flix – A powerful effect-oriented programming language

#152
post #151
post #148

Earlier quoted context omitted.

The FAQ ( https://flix.dev/faq/#:~:text=Dividing%20by%20zero%20yields%... ) links to https://www.hillelwayne.com/post/divide-by-zero/ , which is more about Pony, but links to https://xenaproject.wordpress.com/2020/07/05/division-by-zer... which properly explains that it's helpful for proof assistants to define division by zero, with particular reference to Lean. Really it's defining a division-like function (Lean cal…

Ah thanks for the insights and references. And yes I'm still curious why this definition of div/0==0 is needed in the context of Flix

Gotta be honest, this isn't very inspiring : "Wait, division by zero is zero, really? Yes. But focusing on this is a bit like focusing on the color of the seats in a spacecraft."

Re: Flix – A powerful effect-oriented programming language

#154

Very cool language. The standard library looks mostly sane, although it does have `def get(i: Int32, a: Array[a, r]): a \ r` which means that it must have some kind of runtime exception system. Not my cup of tea, but an understandable tradeoff

no, that's a region variable if i understand correctly, so closer to a rust lifetime

It is, but your reply seems like a non-sequitur. The point OP was making was that it doesn't return an Option or Maybe or anything like that, meaning that there's a failure case untracked by the type system.

Re: Flix – A powerful effect-oriented programming language

#155
post #42

Earlier quoted context omitted.

Arguably FP really is about eliminating side effects. The research has sprung out of lambda calculus where a computation is defined in terms of functions (remember: Functional programming). Side effects can only be realized by exposing them in the runtime / std-lib etc. How one does that is a value judgement, but if a term is not idempotent, then you arguably does not have a functional programming language anymore.

Lisp always had side effects and mutability, and it's the canonical FP language, directly inspired by lambda calculus. To be fair, before Haskellers figured out monads, nobody even knew of any way to make a FP language that's both pure and useful.

> and it's the canonical FP language

Don't tell that to the Haskell crowd. I feel like at least half the time this topic comes up on HN someone jumps out of the woodwork claiming lisp isn't fp because it doesn't do something or other that Haskell does.

Re: Flix – A powerful effect-oriented programming language

#156
love the syntax, and excited to mess with it, but man i’m sad to see it’s on the JVM. if i had to guess, a lot of langs like this are on JVM because that’s a lot simpler than writing a whole backend with anywhere near the same performance or reliability, and i totally get that.

that being said, bearing in mind that i’m not a Java/JVM developer and only rarely have to use it, for the few nontrivial projects i have shipped with it the build system was by far the most challenging and frustrating. it’s so complex and has such a large surface area.

no hate at all, and the trade offs are completely reasonable, but i am hoping during my career we’ll start seeing either a massive simplification of JVM builds or a lot of innovation that would make native compilers easier to build.

(as a side note, it is nice to have langs like this for when JVM is the only option)

Re: Flix – A powerful effect-oriented programming language

#157
post #154

Earlier quoted context omitted.

no, that's a region variable if i understand correctly, so closer to a rust lifetime

It is, but your reply seems like a non-sequitur. The point OP was making was that it doesn't return an Option or Maybe or anything like that, meaning that there's a failure case untracked by the type system.

oh, right, i misunderstood

Re: Flix – A powerful effect-oriented programming language

#159

Very cool language. The standard library looks mostly sane, although it does have `def get(i: Int32, a: Array[a, r]): a \ r` which means that it must have some kind of runtime exception system. Not my cup of tea, but an understandable tradeoff

Just looking at the language myself, but it seems that it treats out-of-bounds array access as a non-recoverable bug and panics [1, 2], whilst map access returns Option [3]. Exceptions are a language construct only to enable Java compatibility and not recommended otherwise [4], but that's not to say you couldn't implement your own try/catch using the effect system. `r` is a region variable as the sibling comment says.

[1] https://doc.flix.dev/chains-and-vectors.html#vectors

[2] https://flix.dev/principles/ See also "Bugs are not recoverable errors"

[3] https://api.flix.dev/Map.html#def-get

[4] https://doc.flix.dev/exceptions.html

Re: Flix – A powerful effect-oriented programming language

#160
post #155
post #42

Earlier quoted context omitted.

Lisp always had side effects and mutability, and it's the canonical FP language, directly inspired by lambda calculus. To be fair, before Haskellers figured out monads, nobody even knew of any way to make a FP language that's both pure and useful.

> and it's the canonical FP language Don't tell that to the Haskell crowd. I feel like at least half the time this topic comes up on HN someone jumps out of the woodwork claiming lisp isn't fp because it doesn't do something or other that Haskell does.

I doubt it's Haskellers saying that. In my experience Haskellers don't even think about Lisp at all.
Post reply on HN