Alpaca – Functional programming inspired by ML for the Erlang VM • Hacker News Board

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#81

Post by j14159 » Sat, Mar 25, 2017, 5:24 PM UTC

Athas wrote: post #58

I am intrigued by this snippet from the README: type messages 'x = 'x | Fetch pid 'x This appears to define a sum type where one of the variants is left with an implicit constructor. How do you pattern match on that? How do you do type inference?

That's a good question and the short answer is that we're deliberately breaking decidability to allow people to use types that are relatively in line with what we're used to in Erlang (I get into this a bit in the talk linked above). There's a reasonable argument to be made that we should knock this off of course but I'm generally biased in favour of making interoperation with the ecosystem simpler :)

We should actually clean up that example you pointed out, matching on the `Fetch` constructor first. What we're really trying to support is unions like:

    type number = int | float

There's a yet un-had argument about the utility of this as well of course and we may want to remove the ability to do this entirely. The way we type this is by actually using type-checking guard functions like `is_integer` to convey information to the typer at compile time.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#82

Post by WhitneyLand » Sat, Mar 25, 2017, 6:57 PM UTC

willtim wrote: post #54

WhitneyLand wrote: post #40

Earlier quoted context omitted.

Seems a bit contradictory. Which is it, corporate backing or novel ability? I would like to see language advantages better quantified. How confident can we be a language is a practical improvement, in what contexts is it true, and what do the improvements buy in cost, quality, innovation, etc. If we had all this data for a new language it would probably be easier to gain critical mass.

No one is funding these studies, so I wouldn't hold your breath. It is down to you to decide for yourself. As an anecdote, I switched to Haskell professionally 5 years ago and am both happier and more productive.

Interesting. Would you say it's the most productive language you've ever worked in?

What's your best guess as to how well this would apply to developers in general?

Once I used a tool chain with a steep learning curve, but I felt the rewards were clearly worth it. However, with that particular team it was difficult to get buy in. It seems not everyone is interested in a little pain for a lot of gain, especially if the concepts are very different.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#83

Post by platz » Sat, Mar 25, 2017, 7:08 PM UTC

WhitneyLand wrote: post #82

willtim wrote: post #54

Earlier quoted context omitted.

No one is funding these studies, so I wouldn't hold your breath. It is down to you to decide for yourself. As an anecdote, I switched to Haskell professionally 5 years ago and am both happier and more productive.

Interesting. Would you say it's the most productive language you've ever worked in? What's your best guess as to how well this would apply to developers in general? Once I used a tool chain with a steep learning curve, but I felt the rewards were clearly worth it. However, with that particular team it was difficult to get buy in. It seems not everyone is interested in a little pain for a lot of gain, especially if th…

Not the OP, but I don't think Haskell will ever be drop-in replacement for mainstream langs for cultural reasons, but that doesn't mean that those who do engage w/ it don't get get tremendous value from it or fail to find it their favorite language (I.e. Doesn't contradict what willtim said). And I think that's OK. (No, you're probably not going to convince a bunch of rubyists to use haskell). You can even train entire teams of willing Haskell developers from scratch, if needed. But the desire / buy in has to be there. IMHO anyways

Part of the problem is that dev is so large that it is hard to make "in general" statements anymore.

It's easier to talk about concrete/specific instances or cases

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#84

Post by toolslive » Sat, Mar 25, 2017, 7:22 PM UTC

jerf wrote: post #26

spraak wrote: post #22

Earlier quoted context omitted.

I'd love to have something that takes the best of Go (static typing, fast compiles, binaries, community) and functional paradigm.

Ocaml is close. Not sure how their concurrency is going, but I'm sure the act of mentioning that will bring someone out to bring us up to date.

There are several libraries for concurrency: - Lwt: https://github.com/ocsigen/lwt - Async https://realworldocaml.org/v1/en/html/concurrent-programming...

However pulling these over more than 1 core is still a problem. OCaml 4.05.0 should have infrastructure for that (although OCaml multicore has been somewhat a `duke-nukem forever` story)

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#85

Post by im_down_w_otp » Sat, Mar 25, 2017, 8:26 PM UTC

haspok wrote: post #55

I think this is great news for the Erlang VM: while you wouldn't want to use static typing for any program you write, there is a very specific use-case where you definitely want to do that: embedding business logic in your application. I've been there, done that: encoding business rules in Erlang is no fun, hard to test, and definitely hard to read and modify later. In this particular domain the constraint of types d…

I'm not sure I'm following you regarding the difficulty of encoding business logic into your code in Erlang.

Erlang's function-head matching system is extremely close to being a Prolog-style logic programming system when used a certain way.

I've found it extremely easy to take what would normally be a big weird database of rules and values and instead precompile every possible route through the system into a bunch of generated function-head matched function calls + guard clauses. It makes assuring that given inputs will definitely produce correct outputs very easy, and makes processing the rules extremely fast.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#86

Post by jnbiche » Sat, Mar 25, 2017, 8:40 PM UTC

bluejekyll wrote: post #71

jnbiche wrote: post #62

Earlier quoted context omitted.

Rust doesn't have fast compile, and I think it's hard to argue that a language without TCO is a functional language. Recursion is a critical part of the functional paradigm. Also, I think a lot of people are attracted to Go because it's very simple to learn and use. Rust with its borrow checker is definitely not simple to learn and use. But it's true Rust has some functional features.

That simplicity comes at a cost. The cost is duplicate code, less strict error handling and the billion dollar mistake. I know that some people downplay the importance of these things; I find that because Rust has strong guarantees in these areas it helps to reduce work, reduce bugs and increase confidence in the software. And use 'cargo check' during Dev for faster compiles.

> That simplicity comes at a cost. The cost is duplicate code, less strict error handling and the billion dollar mistake.

In Go, I agree. But that's not necessarily the case for all simple languages. Take ML, for example. It's a very small, easy-to-learn language with excellent abstraction features that make it easy to avoid duplicate code, as well as excellent static checking and error handling.

Unfortunately, ML lacks a comprehensive, modern standard library like Go has.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#87

Post by willtim » Sat, Mar 25, 2017, 8:59 PM UTC

WhitneyLand wrote: post #82

willtim wrote: post #54

Earlier quoted context omitted.

No one is funding these studies, so I wouldn't hold your breath. It is down to you to decide for yourself. As an anecdote, I switched to Haskell professionally 5 years ago and am both happier and more productive.

Interesting. Would you say it's the most productive language you've ever worked in? What's your best guess as to how well this would apply to developers in general? Once I used a tool chain with a steep learning curve, but I felt the rewards were clearly worth it. However, with that particular team it was difficult to get buy in. It seems not everyone is interested in a little pain for a lot of gain, especially if th…

For me personally it is the most productive and expressive language I have worked in.

There is a steep learning curve, which will make one a better programmer, but not without significant buy in. There is no free lunch.

Haskell is very expressive with its types, especially with regard to when effects happen, which makes it excellent as a shared design language. It's interesting for me to see Java/C# programmers struggle to explain some of their more modern stream abstractions to each other:

http://stackoverflow.com/questions/28459498/why-are-java-str...

The answers above are unable to explain succinctly what the APIs are doing, because the authors lack the necessary common language. They have to answer with wordy essays describing various scenarios and use cases.

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#88

Post by willtim » Sat, Mar 25, 2017, 9:07 PM UTC

platz wrote: post #83

WhitneyLand wrote: post #82

Earlier quoted context omitted.

Interesting. Would you say it's the most productive language you've ever worked in? What's your best guess as to how well this would apply to developers in general? Once I used a tool chain with a steep learning curve, but I felt the rewards were clearly worth it. However, with that particular team it was difficult to get buy in. It seems not everyone is interested in a little pain for a lot of gain, especially if th…

Not the OP, but I don't think Haskell will ever be drop-in replacement for mainstream langs for cultural reasons, but that doesn't mean that those who do engage w/ it don't get get tremendous value from it or fail to find it their favorite language (I.e. Doesn't contradict what willtim said). And I think that's OK. (No, you're probably not going to convince a bunch of rubyists to use haskell). You can even train enti…

Yes I agree. Haskell is a powerful principled general-purpose language, but not everyone will need this.

But this does not mean I am happy with the current mainstream status quo :)

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#89

Post by user1241320 » Sat, Mar 25, 2017, 9:54 PM UTC

spraak wrote: post #22

jerf wrote: post #15

Earlier quoted context omitted.

There's always room for another language. What's hard is cracking into the very, very top tier, the C++, C#, Java, etc. tier. I am also increasingly of the opinion that it simply takes massive corporate backing to get to that level, based on the observation that I haven't seen anything get to that level without it. Python's the only one that has arguably gotten there, I think, and it's still debatable. That said, I d…

I'd love to have something that takes the best of Go (static typing, fast compiles, binaries, community) and functional paradigm.

There was a small attempt to what you describe: https://github.com/oden-lang/oden

Re: Alpaca – Functional programming inspired by ML for the Erlang VM

#90

Post by cousin_it » Sat, Mar 25, 2017, 10:57 PM UTC

louthy wrote: post #66

cousin_it wrote: post #50

Earlier quoted context omitted.

I've worked with systems like that for years, and it's fine. We can have several large binaries with different release schedules, passing around a big struct with 50 fields and many nested structs, with different people making changes to different parts. And nothing breaks. New code accepts old structs, old code accepts new structs, no conversion code required. To achieve that, we follow the design of Protocol Buffer…

What you're describing sounds like a manually implemented type system. > Each field in each struct has both a name and a numeric id. Only ids are used for serialization, so field names can be changed at any time. Fair enough your field names can be renamed. But the 'contract' is field numbers, not names. > All fields are marked as optional or repeated, never required. Most code is written to handle missing fields gra…

It helps that we have one big source control repository for the whole company, which runs many custom hooks that can block changes from being committed. For example, if I try to add a field whose id is lower than the next available id specified in the .proto file, my change won't commit. Same if I try to remove a field that's still used by someone else and my change breaks their build.

More generally, I think RPC interfaces need to be forward-compatible by design. If you have two binaries that are released on different schedules, and the API between them is fully rigid, how do you ever change it? Version the whole API, for a change that adds one boolean feature flag to one struct somewhere? Write a converter for fifty existing fields every time you add a new field, leading to O(n^2) programmer work over time? Come on.

Even more generally, I think static types are a great idea, but they work best locally. Communication over longer distances (in space and time) requires a different set of tradeoffs. There's a reason why people design network protocols and file formats with open-ended forward compatibility in mind. RPCs are kind of a middle ground, and I've found that the tradeoffs in Protocol Buffers work pretty well. YMMV.