Gradual typing is messing with my habits… but not in a pleasant way 😕

A type-system for by Théophane Hufschmitt, Oct. 2017
youtube.com/watch?v=79dL7HgmW_

@otini That might be a step beyond even, but honestly I wasn't impressed: adding a very complicated type-system on top of already very/too complicated custom language may be not the best idea, IMO.

@amiloradovsky I think the same problems would arise to typecheck package descriptions written in GNU Guile, no?

Follow

@otini Not quite. is splitting hairs much better, even despite being also a dynamically-typed language.
Record types there, for example, have fixed set of fields with default values, AFAIK, so one cannot just put arbitrary stuff in there and expect it to pass through.
Actually, I'd say Guix already has some type-system, look at this for example:

- gnu.org/software/guix/manual/e

- gnu.org/software/guix/manual/e

There is definitely some static analysis going on.

@amiloradovsky If Guile has real record types with a fixed set of fields, that's probably better. I never quite understood where dynamic field labels where used in NIxpkgs.

@otini is generally better than + in many respects. But less popular, especially among the industrial users wanting clopen source.

@amiloradovsky I would try it but I also need some proprietary software for my laptop.

@otini If this is a user-land software, you can probably just create an expression for it, and build it with `guix build` then install.
If this is a kernel drivers, for example, then I'm not sure how difficult it would be: maybe just `insmod` would suffice, maybe not, IDK.

@samae @otini An organization, which uses * in their business processes, possibly supports the projects financially, and adds specific/niche features.

See e.g. Acknowledgments in

- nixos.org/nixos/community.html

and

- builtwithnix.org/

There is much more, I'm sure.
And I heard several times that the lack of non-free s/w in Guix is a problem for them.

@amiloradovsky

Aha, I see.

Yes, I would believe that industrial users are a bit less interested in the moral aspect of free software and more in its potential financial benefit to them, thus they have no problem with mixing closed and open source softs (especially if the closed source is their own).

@otini
@grainloom @otini @amiloradovsky

You mean, for their own use? Sure, that's what they'd do and that's a description mixing free software and proprietary. They'd probably have no problem using a publicly funded cache for their private business use too.

@grainloom
But why create your own non-free repo, when you can mix it into the free one, and put the burden of long-term support on the community of volunteers?
Sure is right that they aren't allowing non-free s/w, but Nix* is meant to be business-friendly.
@samae @otini

@amiloradovsky @otini @grainloom

Well, IMO because you don't want your *shiny* proprietary code stolen 👻​ or even used to find security weaknesses you left there 🙀​ :D In that sense it is easier keeping a secret.

@samae
It depends:
• If this is something "mission-critical" (assuming businesses have a mission lol), you may not want to expose it to the whole world for audit, especially if it's really cheap (e.g. site's back-end).
• If this is a tooling, needing constant support and integration with the rest of the world, let's "open-source" it and make hordes of jobless amateurs do all the dirty work… Plus get the badge of "open-source company" as a bonus, good.
@otini @grainloom

@samae @otini @grainloom
To recap: libre, not open-source, which should better be called clopen-.

@amiloradovsky @grainloom @otini

I agree on both counts. I was being sarcastic, pointing out that despite the real advantages industrial users could get, I was thinking of one example when said user was afraid of any public audit (meaning on which they didn't have control) or lacked faith that they would ever receive any contribution if they published tooling around the main product.
Sign in to participate in the conversation
Functional Café

functional.cafe is an instance for people interested in functional programming and languages.