Functional programmers need to take a look at Zig
pure-systems.org
Functional programmers need to take a look at Zig
1–10 of 163 posts
Re: Functional programmers need to take a look at Zig
#2io is not a monad. theres nothing stopping you from stashing a global io "object" and just passing the global wherever you interface with the stdlib.
It's dependency injection. and yes, you can model dependecies like a monad but most people, even in less pure fp langs, don't.
i don't really say this to just be a pedant, but if you're an fp enjoyer, you will be disappointed if you get the picture that zig is fp-like, outside of a few squint-and-it-looks-like things
Re: Functional programmers need to take a look at Zig
#3[dead]
Re: Functional programmers need to take a look at Zig
#4io is not a monad. theres nothing stopping you from stashing a global io "object" and just passing the global wherever you interface with the stdlib. It's dependency injection . and yes, you can model dependecies like a monad but most people, even in less pure fp langs, don't. i don't really say this to just be a pedant, but if you're an fp enjoyer, you will be disappointed if you get the picture that zig is fp-like,…
My reading of the article, was that the author seems to be in search of a new paradigm, that moves beyond what he sees as the limitations of "fp-like" languages as they exist today. His point appears to be that Zig provides the benefits of "fp-like" languages that exist today, while avoiding at least some of the downsides.
And he does admit you may have to squint, to appreciate the fp capabilities provided by Zig.
Re: Functional programmers need to take a look at Zig
#5> Noise is anything that must be written for the program to function that is not relevant to the domain.
> ...
> What facilities does the language provide me to create correct-by-construction systems and how easily can I program the type-system.
Isn't programming the type-system orthogonal to the program's domain in the same way that manual memory management is?
Re: Functional programmers need to take a look at Zig
#6I don’t get it
Why write:
EqPoint.eql(a, c)
When you can write:
Point.eql(a, c)
Re: Functional programmers need to take a look at Zig
#7Do you really prefer this:
fn Maybe(comptime T: type) type {
return union(enum) {
value: T,
nothing,
const Self = @This();
pub fn just(the_val: T) Self { return .{ .value = the_val }; }
pub fn nothing() Self { return .nothing; }
}
}
data Maybe a = Just a | NothingRe: Functional programmers need to take a look at Zig
#8> Noise is anything that must be written for the program to function that is not relevant to the domain. > ... > What facilities does the language provide me to create correct-by-construction systems and how easily can I program the type-system. Isn't programming the type-system orthogonal to the program's domain in the same way that manual memory management is?
No? I don't agree. The domain can be strongly modelled in the types; for instance, declaring kilometers, seconds, etc. instead of using primitive floats/reals everywhere, to statically prevent dimensional analysis issues.
Re: Functional programmers need to take a look at Zig
#9Do you really prefer this: fn Maybe(comptime T: type) type { return union(enum) { value: T, nothing, const Self = @This(); pub fn just(the_val: T) Self { return .{ .value = the_val }; } pub fn nothing() Self { return .nothing; } } } Over this? data Maybe a = Just a | Nothing
My old memories of Guava in Java 6 have been triggered.
Re: Functional programmers need to take a look at Zig
#10A functional programmer who casts away proper sum types and pattern matching is no functional programmer at all