4 ms·

I feel like at any point this functionality becomes desirable it would be trivial to implement in any language humans actually use.

throwanem 10y ago
There's no reason a more comfortable language can't be implemented on Hoon; it's just that no one has done it yet, because no one has come along who both understands Hoon well enough to do it and finds Hoon unpleasant enough to bother. This may mean Hoon once learned is easier to cope with than it looks (which I doubt, because it looks like vaguely Lisp-flavored assembly) or it may just mean that nobody like that has come along yet.
- davidgerard 10y ago
  Also: * pretty much everything actually useful is implemented as a jet * the jets often don't actually match the supposed code they're accelerating (e.g. the Markdown jet has different bugs)
  - throwanem 10y ago
    Isn't that just the Markdown jet? Or are there other examples I haven't yet heard about?
  - tsukikage 10y ago
    Worse, there is no formal spec or particular commitment to either the jets or the means by which the VM communicates with its host environment or nodes communicate with each other; this makes it impossible, not just impractical, to replace the environment with an alternative rather than merely wrap what exists - Nock on its own is simply not enough to build on. Instead of the stated intent of giving you control of your own environment, the actual goal appears to be the opposite.
    - throwanem 10y ago
      Communication between urbits appears to be well defined, although my lack of close familiarity with the codebase makes it impossible for me to point at precisely where; ask someone at Tlon, or someone in Urbit :talk. Communication between an urbit and its host is precisely defined by the u3 implementation. The C standard library lacked a formal specification for over a decade after its creation. Lisp lacked one for almost thirty years. At least one of these should be an argument in favor of "build it first, formalize it later".

throwanem 10y ago

There's no reason a more comfortable language can't be implemented on Hoon; it's just that no one has done it yet, because no one has come along who both understands Hoon well enough to do it and finds Hoon unpleasant enough to bother. This may mean Hoon once learned is easier to cope with than it looks (which I doubt, because it looks like vaguely Lisp-flavored assembly) or it may just mean that nobody like that has come along yet.

davidgerard 10y ago
Also: * pretty much everything actually useful is implemented as a jet * the jets often don't actually match the supposed code they're accelerating (e.g. the Markdown jet has different bugs)
- throwanem 10y ago
  Isn't that just the Markdown jet? Or are there other examples I haven't yet heard about?
- tsukikage 10y ago
  Worse, there is no formal spec or particular commitment to either the jets or the means by which the VM communicates with its host environment or nodes communicate with each other; this makes it impossible, not just impractical, to replace the environment with an alternative rather than merely wrap what exists - Nock on its own is simply not enough to build on. Instead of the stated intent of giving you control of your own environment, the actual goal appears to be the opposite.
  - throwanem 10y ago
    Communication between urbits appears to be well defined, although my lack of close familiarity with the codebase makes it impossible for me to point at precisely where; ask someone at Tlon, or someone in Urbit :talk. Communication between an urbit and its host is precisely defined by the u3 implementation. The C standard library lacked a formal specification for over a decade after its creation. Lisp lacked one for almost thirty years. At least one of these should be an argument in favor of "build it first, formalize it later".