Live data from Hacker News

Why do we need modules at all? (2011)

groups.google.com

71–80 of 94 posts

Re: Why do we need modules at all? (2011)

#71
I had a vaguely similar notion of a global proof database. Picture something like a blockchain (actually a "blockgraph") of Lean theorems built up from other theorems and axioms also on the same distributed global data structure.

A use-case could be optimising compilers. These need to search for alternative (faster) series of statements that are provably equivalent to the original given some axioms about the behaviour of the underlying machine code and basic boolean algebra and integer mathematics.

This could be monetised: Theorems along the shortest path from a desired proof to the axioms are rewarded. New theorems can be added by anyone at any time, but would generate zero income unless they improve the state-of-the-art. Shortest-path searches through the data structure would remain efficient because of this incentive.

Client tools such as compilers could come with monthly subscriptions and/or some other mechanism for payments, possibly reusing some existing crypto coin. These tools advertise desired proofs -- just like how blockchain clients advertise transactions they like to complete along with a fee -- and then the community can find new theorems to reach those proofs, hoping not just for the one-time payment, but the ongoing reward if the theorems are general and reusable for other purposes.

Imagine you're a FAANG and there's some core algorithm that uses 1% of your global compute. You could advertise a desire to improve the algorithm or the assembly code to be twice as efficient for $1M. Almost certainly, this is worth it. If no proof turns up, there's no payment. If a proof does turn up, a smart contract debits the FAANG's crypto account and they receive the chain of theorems proving that there's a more efficient algorithm, which will save them millions of USD in infrastructure costs. Maths geeks, AI bots, and whomever else contributed to the proof get their share of the $1M prize.

It's like... Uber for Fields medals, used for industrial computing.

Fully automated gig work for computer scientists and mathematicians.

Re: Why do we need modules at all? (2011)

#72
post #67

Earlier quoted context omitted.

It's all related to naming. You can refer to a symbol with auth/guard/token/authenticate or auth_guard_token_authenticate, and what matters is the amount of characters you type sometimes. Also you can have encapsulation with the first option. Smalltalk have the same live experience, but do have modules, because it makes editing easier and encapsulation is nice for readability and clarity.

No, neither Smalltalk nor any of the Lisp environments that purport to support hot code reloading have the same facilities the Erlang VM has.

Concurrency and tasks supervision is orthogonal to modules/packages.

Re: Why do we need modules at all? (2011)

#73
post #41

I miss Joe, he left us too early. He always had wild ideas like that. For a while he had this idea of a git + bittorrent he called it gittorrent, only to find out someone had already used the name. I think it was a bit of an extension of this universal functions idea. If you expand some of the comments below, he and other members of the community at the time have a nice discussion about hierarchical namespace. I part…

> The dot in the name has no semantics it's just a separator.

That's not true of all module systems. It's true in Java, but not in Rust, where it establishes a parent-child relationship, and in which context [1]:

> If an item is private, it may be accessed by the current module and its descendants.

[1] https://doc.rust-lang.org/reference/visibility-and-privacy.h...

Re: Why do we need modules at all? (2011)

#74
post #73
post #41

I miss Joe, he left us too early. He always had wild ideas like that. For a while he had this idea of a git + bittorrent he called it gittorrent, only to find out someone had already used the name. I think it was a bit of an extension of this universal functions idea. If you expand some of the comments below, he and other members of the community at the time have a nice discussion about hierarchical namespace. I part…

> The dot in the name has no semantics it's just a separator. That's not true of all module systems. It's true in Java, but not in Rust, where it establishes a parent-child relationship, and in which context [1]: > If an item is private, it may be accessed by the current module and its descendants. [1] https://doc.rust-lang.org/reference/visibility-and-privacy.h...

And privacy in Rust is load-bearing for encapsulating unsafe operations from safe code, so it's not just a nice-to-have, its fundamental to the language.

Re: Why do we need modules at all? (2011)

#75

I think Hoogle[1] is proof this concept could work. Haskell has modules, of course, but even if it didn't, Hoogle would keep it still pretty usuable. The import piece here which is mentioned but not very emphasized in TFA is that Hoogle lets you search by meta data instead of just by name. If a function takes the type I have, and transforms it to the type I want, and the docs say it does what I want, I don't really c…

Hoogle works because of how richly-typed Haskell is, but Erlang is dynamically-typed.

Re: Why do we need modules at all? (2011)

#76

> database of functions This is exactly what Unison ( https://www.unison-lang.org/ ) does. It’s kinda neat. Renaming identifiers is free. Uh… probably something else is neat (I haven’t used Unison irl)

I tried it out. Fascinating language and a completely different paradigm. The language itself is familiar, but the structure of the program is different - no files – all functions are in a database and their history. I found the language a bit difficult to navigate, but that is probably because of my experience of work with files, and having tools based on files.

Re: Why do we need modules at all? (2011)

#77

I had a vaguely similar notion of a global proof database. Picture something like a blockchain (actually a "blockgraph") of Lean theorems built up from other theorems and axioms also on the same distributed global data structure. A use-case could be optimising compilers. These need to search for alternative (faster) series of statements that are provably equivalent to the original given some axioms about the behaviou…

The Metamath Proof Explorer (AKA the set.mm database) works on a similar principle, of all theorems forming a tree of backreferences that ultimately lead to the axioms [0].

Though it wouldn't make sense to build something like that on top of such a fast-moving, complex, and bug-prone target like Lean.

[0] https://us.metamath.org/mpeuni/mmset.html

Re: Why do we need modules at all? (2011)

#78
post #41

I miss Joe, he left us too early. He always had wild ideas like that. For a while he had this idea of a git + bittorrent he called it gittorrent, only to find out someone had already used the name. I think it was a bit of an extension of this universal functions idea. If you expand some of the comments below, he and other members of the community at the time have a nice discussion about hierarchical namespace. I part…

[deleted]

Re: Why do we need modules at all? (2011)

#79
post #65
post #41

I miss Joe, he left us too early. He always had wild ideas like that. For a while he had this idea of a git + bittorrent he called it gittorrent, only to find out someone had already used the name. I think it was a bit of an extension of this universal functions idea. If you expand some of the comments below, he and other members of the community at the time have a nice discussion about hierarchical namespace. I part…

Software development is continually emotionally stunted by a lack of people with expertise in multiple other fields. English absolutely has namespaces. Every in-group has shibboleths and/or jargon, words that mark membership in the group that have connotations beyond the many dictionary definitions of that word (in fact I wonder how many words with more than three definitions started out as jargon/slang words that ac…

yes. and math/logics trained brains confuse hierarchical namespaces with trees. names in nested namespaces should be DAGs, maybe even arbitrary graphs, meaning a chair can be a sit-on thing in several contexts, but not in all (think meeting).

in many contemporary programming languages you can express this, too, by exporting some imported name.

Re: Why do we need modules at all? (2011)

#80
post #36

Earlier quoted context omitted.

I agree, but also agree with the author's statement "It's very difficult to decide which module to put an individual function in". Quite often coders optimise for searchability, so like there will be a constants file, a dataclasses file, a "reader"s file, a "writer"s file etc etc. This is great if you are trying to hunt down a single module or line of code quickly. But it can become absolute misery to actually read t…

One thing I experimented with was writing a tag-based filesystem for that sort of thing. Imagine, e.g., using an entity component system and being able to choose a view that does a refactor across all entities or one that hones in on some cohesive slice of functionality. In practice, it wound up not quite being worth it (the concept requires the same file to "exist" in multiple locations for that idea to work with al…

Oops: important -> import
Post reply on HN