Live data from Hacker News

The Flix Programming Language

flix.dev

11–20 of 126 posts

Re: The Flix Programming Language

#11
> Region-based Local Mutation

> Flix supports region-based local mutation, which makes it possible to implement pure functions that internally uses mutable state and destructive operations, as long as these operations are confined to the region.

> We can use local mutation when it is more natural to write a function using mutable data and in a familiar imperative-style while still remaining pure to the outside world.

> We can also use local mutation when it is more efficient to use mutable data structures, e.g. when implementing a sorting algorithm.

Another language with a feature like this is F* (or FStar), but I think it uses a different kind of compile-time analysis.

Haskell actually kind of lets you do it through the ST monad (there's a function called runST that turns mutable code inside the ST monad into pure code). But F* (and Flix) can do it implicitly

Re: The Flix Programming Language

#12

Earlier quoted context omitted.

Do you worry about side-effects that leak beyond the scope of the routines you're authoring? Why / why not?

i do, does functional programming make this a non issue? maybe im just not smart enough to wrap my head around it.

Generally, yes. Some languages are really hardcore about it (notably Haskell), while others just strongly encourage you to write functions without side effects. Ed: that's the "purity" they're talking about in OP.

The other major neat thing about functional languages is how they let you treat functions like objects, but most modern programming languages have adopted that as well, so it's not a big differentiator anymore.

Re: The Flix Programming Language

#13
Lots of interesting bits in the FAQ: https://flix.dev/faq/

Particularly in the sections titled "What features are not supported" (no exceptions or panics, so e.g. indexing has to return an Option in case it's out of bounds) and "What controversial design choices are made". Some pithy remarks towards the end as well.

To follow HN tradition and find the most controversial topic to discuss, my guess is it's either not allowing name shadowing, or divide by zero equals zero. Or the site not working without javascript (see the section on that near the end, but you'll need to turn on javascript to read it I guess)

Re: The Flix Programming Language

#14

Earlier quoted context omitted.

Do you worry about side-effects that leak beyond the scope of the routines you're authoring? Why / why not?

i do, does functional programming make this a non issue? maybe im just not smart enough to wrap my head around it.

Functional languages that require calling out side-effects (eg: "\ IO" in Flix) allow you to write functions that are "pure" (aka: they can do no mutation of data or perform IO) and will always give you the same result for a given input. Writing the majority of your code as pure functions makes the code much easier to reason about, especially as the system scales. IMHO, it also makes testing simpler.

It's definitely a different way of thinking and it has a lot of benefits. However, some of the downsides (which Flix seems to fix with region-based local mutation) might be implementing a sort that keeps two copies of a list in memory just to return the second list and discard the first. Depending on your list, this may not be an issue.

Re: The Flix Programming Language

#16
Just a friendly UBC piggyback on Waterloo’s programming language ;)

Over summer, I built my own little functional language, Crumb (https://github.com/liam-ilan/crumb). Unlike Flix, the scope is tiny, but some pretty awesome stuff has been done with it. (Checkout this pixel art editor in your terminal, 100% Crumb: https://github.com/ronilan/crumbicon).

There’s a template (https://github.com/liam-ilan/crumb-template) and vscode highlighter (https://github.com/liam-ilan/crumb-vscode) for anyone who wants to mess around with it. Any feedback super appreciated :D

Re: The Flix Programming Language

#17
post #3

Great, But \ is ugly

Your username matches your comment!

Also, I agree but I'm not sure what I would propose as a better token. Maybe another colon?

def printAndInc(x: Int32): Int32 \ IO =

becomes:

def printAndInc(x: Int32): Int32 : IO =

Or maybe, since functions need something after the \, even for pure functions, we just drop the \ and use the last argument?

def printAndInc(x: Int32): Int32 IO =

Re: The Flix Programming Language

#18
Related. Others?

Flix – Safe, reliable, concise, and functional-first programming language - https://news.ycombinator.com/item?id=31448889 - May 2022 (42 comments)

Flix – Next-generation reliable, concise, functional-first programming language - https://news.ycombinator.com/item?id=25513397 - Dec 2020 (84 comments)

The Flix Programming Language - https://news.ycombinator.com/item?id=19928153 - May 2019 (2 comments)

Re: The Flix Programming Language

#19

Lots of interesting bits in the FAQ: https://flix.dev/faq/ Particularly in the sections titled "What features are not supported" (no exceptions or panics, so e.g. indexing has to return an Option in case it's out of bounds) and "What controversial design choices are made". Some pithy remarks towards the end as well. To follow HN tradition and find the most controversial topic to discuss, my guess is it's either not a…

I did like seeing the FAQ become more and more deranged the further I scrolled!

I'll perhaps be the first to jump on the 1/0 != 0 hate train though; they mention they designed the stdlib to avoid the partial-function pitfalls of Haskell's, but the article they linked to support their design decision of 1/0 being 0 mentions that it boils down to division being a partial function - x/0 is not a case division can handle. Would it not then be reasonable to make division return an Option?

Re: The Flix Programming Language

#20

do functional languages mainly appeal to computer language enthusiasts/researchers? im just not seeing the benefit personally.

Functional Programming was, for a long time, talked about as yet-another-solution to solve the issue of complexity in larger codebases, primarily the complexity of controlling state getting out o hand.

Similar to OOP, which promised to do this by encapsulating state, FP promised to do this via purity, aka. getting rid of as much state as possible, and only allowing stateful transition at certain well defined sections of the program.

The "market advantage" of OOP was that, via Java, it was already so well established, and so many coders had been trained in OOP languages, that it remained alive. FP on the other hand, coming out of academia and requiring all these industry people to suddenly do things in syntactically and conceptually different ways, never really gained traction. OOP simply came first, it is as simple as that.

Whether FP would have actually solved the problem is anyones guess, since it never gained the traction of OOP and Procedural languages. My best guess is that it wouldn't, because I don't believe in silver bullets.

It should be noted that both approaches contributed valueable things to contemporary languages. E.g. first order functions being the norm comes from FP.

Post reply on HN