
Hoon's Moronic Type System - somedude99
http://www.urbit.org/2013/08/22/Chapter-5-types.html?s
======
tikhonj
This might be an interesting project if not for the constant misguided
crusading against a PL theory straw man. It's a sort of anti-intellectualism I
find particularly galling, but it seems lamentably common in some nooks of the
programming world.

~~~
urbit
For the record, not that it matters, Sergey Brin was born in 1973 and started
a CS PhD at Stanford, specializing in OS, in 1993. I was born in 1973 and
started a CS PhD at Berkeley, specializing in OS, in 1992. Alas, neither of us
finished.

Intellectuals are no different from anyone else - they live in the same
reality and must be judged by their results. I don't think anyone would
disagree that PL theory, as a body of work, has produced a set of languages
whose penetration in the real world is oddly small both given (a) the
investment in these technologies, and (b) the many real advantages of typed
higher-order programming.

As a general pattern, usually when I see this outcome explained, it takes the
form of blaming the user. We wouldn't let anyone else get away with this
excuse, so why should intellectuals be treated as a privileged class?

To be anti-intellectual is to judge intellectuals more harshly than they
deserve. To be pro-intellectual, also a cognitive bias, is to judge them more
leniently than they deserve. In a world whose bias is generally pro-
intellectual, it's easy for a neutral assessment to seem relatively anti-
intellectual, but perhaps what you are perceiving is not an exceptional bias
but the absence of a systemic bias which you've grown used to.

~~~
tikhonj
Yes, your background isn't relevant--and Brin's even less so--but it does make
for some nice anchoring.

PL theory, as a "body of work" has produced a wide range of languages ranging
from Agda to Scala to Java. Some of these have actually seen use! Everything
from classical music to Justin Beiber. TAPL, for example, is certainly not
limited to the less popular languages: it talks about the foundation for Java-
style types as well. Some of the same people working on ML and Haskell are
also behind designs of Java and C#.

The point of a language like Haskell is to be expressive and useful, not to
appeal to a large base population. Popularity and industry uptake are not the
only measures of success. (This is, coincidentally, one of the things I don't
like much about Berkeley's graduate program, or at least the systems lab I
spent a bit of time in: they _did_ seem to think industry uptake to be the
only metric that mattered.)

Beyond languages, PL _theory_ serves the role of all theory: it's the
foundation upon which everything else is built. Things like the JVM memory
model are based on the theory themselves and designed with tools stemming
directly from that theory. Sure, the average programmer on the street is never
going to use a theorem prover, but they _will_ use the JVM where the memory
model _has been_ verified with one.

All this reminds of nothing more than the usual arguments that Linux is a
complete failure because nobody uses it on the desktop. But I think that
argument is not true even if you limit yourself to "Linux _on the desktop_ is
a failure": sure, not many people use Linux on the desktop, but the ones who
do find it very useful and are exceptionally productive. Same principle
applies to PL theory and functional programming languages.

There are many different ways to have an effect in the world, and the most
obvious and direct one is not necessarily best. Even if it _feels_ best.

~~~
urbit
s/the foundation upon which everything else is built/ _a_ foundation on which
everything else _can be_ built. If you'll accept this change, we don't
disagree at all.

(Also, it is a serious overstatement to attribute Java and C# to PL theorists.
Gilad Bracha is not James Gosling. PL theorists have contributed to some
extensions to these languages. Typically, the extensions that confuse people
and make them feel stupid.)

The difference between _the_ foundation and _a_ foundation is enormous,
because (with your very large expensive foundation) you are asking programmers
either to program without knowing the foundations of their work, or to learn a
large and challenging body of mathematics.

And you know, higher-order typed programming is good enough that it's almost
worth it. For most potential customers, however, learning PL theory does not
seem to be worth it. Nor are they comfortable in programming in Haskell, a
very powerful and complex environment, without understanding it.

It's this "the customer is just wrong" attitude that makes some of us sense an
area ripe for disruption. Pride goeth before a fall.

~~~
effn
> It's this "the customer is just wrong" attitude that makes some of us sense
> an area ripe for disruption. Pride goeth before a fall.

Doesn't this apply to syntax as well?

~~~
urbit
It does. And the best I can say is that I'm genuinely interested in the
results of my experiment.

It would certainly be an interesting practical experiment to try to adapt a
conventional syntax to the same semantics, or even to discard Hoon and create
a more conventional language targeting Nock (which Urbit would have no trouble
running).

------
archgrove
I'm presuming this is "in joke" that I'm very much out of. I honestly have no
idea what this is about at all, nor can I find any context.

~~~
urbit
More context from the front page: [http://urbit.org](http://urbit.org).

Previous HN discussion:
[https://news.ycombinator.com/item?id=6438320](https://news.ycombinator.com/item?id=6438320)

This is a perfectly serious type system that infers perfectly serious types
all day long. It is moronic, though.

~~~
tsukikage
> This is a perfectly serious type system that infers perfectly serious types
> all day long

...in a submarine.

~~~
samatman
Your desktop isn't wood, your folders aren't manila, and your windows aren't
glass. Why balk at a submarine? It's made of the usual combination of bits and
vivid metaphor.

~~~
tsukikage
My desktop is most certainly not wood, it's %gold ;)

Who's balking? I'm right there under the water. I find myself craving a
destroyer, without quite knowing what I'd do with one ;)

------
samatman
Nock made me suspect Mencius is a Kabbalist. This metal and wood business
confirms it.

Hoon is still far and away the most WTF part of Urbit from my perspective.
Nock: brilliant. Urbit proper: obviously the right thing. Hoon: line noise or
poetry? I remain totally undecided.

Eagerly awaiting comprehensive documentation of the digraphs.

~~~
samograd
My take on hoon is to use[2] the alphabetic names of the line noise operators
to create words and use them to make a non-symbolic (if you take alphanumeric
characters as non-symbolic) functional, executable conlang[3].

To me it's what Liebniz was looking for[1], but with funny looking words that
make no sense to the uninitiated, which use the 'linguistic nodules' that
cgyarvin is hoping to utilize, without the symbolic name decoding that using
line noise requires (if you use the names in [2] rather than the line noise
symbols).

I personally think hoon looks like absolute brilliance, but I can't say yet
that I've had the pleasure to write anything in it, which is the best thing to
take that shiny feeling away by actually trying to use it.

But as art, I think it's perfect.

[1]
[http://sunsite.utk.edu/math_archives/.http/hypermail/histori...](http://sunsite.utk.edu/math_archives/.http/hypermail/historia/may99/0211.html)

[2] As follows from
[http://www.urbit.org/2013/08/22/Chapter-4-syntax.html](http://www.urbit.org/2013/08/22/Chapter-4-syntax.html):

    
    
        ace  space      gal  <          per  )
        bar  |          gar  >          sel  [
        bas  \          hax  #          sem  ;
        buc  $          hep  -          ser  ]
        cab  _          kel  {          sig  ~
        cen  %          ker  }          soq  '
        col  :          ket  ^          tar  *
        com  ,          lus  +          tec  `
        doq  "          pam  &          tis  =
        dot  .          pat  @          wut  ?
        fas  /          pel  (          zap  !
    

[3]
[https://en.wikipedia.org/wiki/Constructed_language](https://en.wikipedia.org/wiki/Constructed_language)

~~~
samatman
The numerous minor nitpicks I have with this scheme are a big part of what
keeps me coming back to Urbit. The basic idea is so right-on that I can't help
focusing on things like this: given that 2 billion people conflate "1" and
"r", how on Urth did he settle on using those as primary distinguishments for
every. single. brace. pair. O right, left and right.

Similarly, every c in that scheme makes me kringe. Unless those are "chab",
"chen", "chol", "chom", "butch" etc. Which, affricates, meh.

This is of course the complement of damning with faint praise.

------
samograd

       (_Gonadic combinators_? Yes - using our gonad rune, 
       semsig or ;~. If you are a sophisticated professor type 
       and understand monads, gonads may seem real familiar to 
       you. Out here in Urbit world we are just dumb country 
       peasants and all we got is gonads.
    

This is the South Park of system design, or at least it makes me laugh just as
much. These guys are great although the software is still a bit fragile.

------
adultSwim
I actually find a lot of arguments he presents compelling. However the general
thrust seems to be that programming language should be accessible.

Hoon seems to fail that test.

I've yet to see how this is better than vanilla ML. I don't see that because
Hoon doesn't use standard syntax or terminology. I can't just read some code
and a language overview to decide if this is worth (a lot of) my time.

I think ML has a fairly steep start-up cost but is definitely understandable
by regular people and has real productivity benefits.

Hoon is sufficiently obfuscated that it has an incredibly high barrier to even
evaluate as a language. I don't think you need to have tons of unintelligible
typing rules to make things familiar. By avoiding standard syntax and
terminology, it puts an enormous burden on the potential user.

~~~
samatman
I'd like to address this obliquely with a question to urbit:

Is it always the case that the vowels may be compressed away without loss of
meaning? It seems to work some/most of the time, but there is a least a %wet
and %wut... I think?

Though this be method, yet there is madness to it.

~~~
urbit
There's %wet but no ++wet. The name of the character is actually just the name
of a parser function for it.

------
adultSwim
By the way, what's with all the hate on Ben Pierce?

Take his Software Foundations book. It opened up Coq in a very practical way.
No crazy typing rules or category theory. Just straight programming and simple
proofs. That's a world where previously the few who entered were sucked down a
rabbit hole of theory, never to return again.

------
comex
A language that has "cube", "face", "stem", "bulb", "coil", "foot", "battery",
"gene", "gold", "iron", "ash", and "yew"...

It's not that other languages don't make up arbitrary terms as well, but it's
hard to understand why a language that claims to be simple and "moronic" does
it so enthusiastically, with the result that anyone trying to learn it has to
first memorize a large number of terms.

~~~
urbit
Basically, I'd say, ordinary human beings are much better at memorizing words
and symbols than most smart people think - and much worse at understanding
highly abstract concepts.

Think of the number of things you need to memorize to be an auto mechanic. Yet
there are a large, large number of people who are capable of becoming auto
mechanics, but not capable of becoming Haskell programmers.

~~~
nnq
Shouldn't we compare the abilities of people vs. computers? Computers can
store a lot in their memory, but it's pretty hard to make them prove theorems,
whereas humans are pretty bad at memorizing anything and pretty good at
abstraction.

...and since a programming language should be primarily designed for humans
(or, as I actually see it, a programming language should be an interface
between the human mind and the computer) and at the same time be executable by
computers, choosing more memorization and less abstract concepts seems like a
bad idea ...most smart people's minds find juggling abstract concepts easier
and more enjoyable than memorizing rules (and when working memory is not
enough to hold all the abstract concepts we're juggling, we use anything from
pen and paper to other more advanced devices - just ask any mathematician),
and those that don't are also those that "just don't get (or like) software",
so they shouldn't be programming anyway.

~~~
urbit
I agree with your goals but not with your observations. Perhaps I'm biased by
the fact that I have small children. I am regularly amazed by their ability to
memorize words, numbers, symbols, etc, combined with complete incompetence at
abstract concepts. Grownups are different, of course, but it's still natural
that most of what I know about learning comes from my own kids.

------
auggierose
I have no idea what any of this means.

~~~
auggierose
Ok, I just clicked on the link and what I saw there just didn't make any sense
to me :-) Still doesn't now, but after reading the comments, I returned to the
site and studied it more carefully. Maybe the link should point to chapter 0,
not chapter 5, to have any idea about what this is about ... After reading
chapter 0 now, I can understand the goal of urbit, and I think it is a great
one! But note that you can work on exactly the same goal without leaving PL
theory and theorem proving entirely behind you. Check out
[http://proofpeer.net](http://proofpeer.net) to see how this might be
possible.

~~~
urbit
That's a truly amazing effort to take on the OS problem from a theorem-proving
standpoint. I of course would try to attack the same problem on a theory-
indifferent substrate. But... +1 for an exciting vision of math uber alles.

------
Vivtek
This is actually Chapter 8 of the punishment book from Anathem, right?

------
andrewcooke
anyone got a summary for people with less patience or an apparently broken
sense of humour?

~~~
urbit
Hoon is a very stupid little higher-order type-inference engine that does not
use Hindley-Milner, category theory, etc. Higher-order functional programming
is so cool it should be accessible to the majority of human beings who
unfortunately happen to be bad at math. Also, layering a type system on top of
an untyped data model has various practical benefits - eg, your types can be
used as validators for untrusted data you got over the network.

~~~
samatman
You appear to be saying, among other things, that a noun is of a particular
type if it may be passed through a function that parses and validates that,
yes, those bits may be treated in that fashion.

Is that accurate? There's clearly more to it, as there's at least one
conceptual leap between that notion and any kind of inference.

~~~
urbit
The type, as a set of nouns, is the range (excuse me, "codomain") of a
function.

So, if we have another function and we call it with a noun of that type, we
know the range of the input, we know the code in the function, we can infer
the range of the output. It's not terribly rocket scientific.

~~~
samatman
This explanation falls apart for me because the third time you use the word
"function", it can refer to either of the two referents you already
introduced.

I think you're saying a type is the range of inputs to function1 which succeed
by not crashing; given function2 and a noun in the type, we may use function1
to infer the range of values which function2 must accept? Maybe?

~~~
urbit
Range == set of _outputs_ which the function can produce.

In any language, a type defines a set of values and some semantics for
manipulating those values. It so happens that our way of defining common sets
is to build a function whose range is some useful set.

Actually any gene (ie, expression) has a product range. It doesn't even need
to be a function. So the range of the constant

[%foo %bar]

whatever the subject is, is always [%foo %bar], ie, the pair [7.303.014
7.496.034].

~~~
samatman
Outputs indeed. I forgot your country willingness to 'normalize' input. I
suppose a bull can be a steer if you're willing to cut the balls off on the
way into the pen.

You're not a big believer in airbags, are ya.

~~~
urbit
An automatic castrator is an excellent safety device for your steer pen.

Generally we don't actually _use_ these functions unless we're normalizing
foreign data. Then, we do. Because anyone on the Internets can send a bull
into your steer pen...

~~~
samatman
I guess I'm hoping there's some snipping noise that lets one distinguish the
two cases.

------
itsuart
First of all, I didn't read linked article. Which is wrong of course. As
usual, I'm basing on comments in this thread. So you want to do type system
without PL theory of modern age. Awesome! Seriously, interesting experiment.
Unless you already have read TaPL in which case I fear you would antagonise
ideas described there. However, there is a non-merit, non-technical problem:
dismissing PL theorists is sounds like dismissing PL theory (wrong
implication, but that is how humans are I believe). And this will put you into
JS/PHP/whatever-back-to-the-trees basket and your ideas will be dismissed just
because of this wrong association. Which means, that you will distorted
results of your experiment. How do you plan to alleviate that? Or I'm wrong
somewhere and it is non issue?

------
humbledrone
I'm disappointed to see the depressingly common male-genetalia-centric humor
in "Gonadic" combinators. I find myself agreeing with much of the forward-
thinking, throw-the-past-away design of Hoon/Nock, but it's jarring to find
this kind of asinine brogrammer mentality mixed in with it. Yet another sling
and/or arrow of discomfort for the half of the human population that already
has to put up with too much of this shit.

[EDIT] As a reply points out, Gonad is gender neutral. I still think that this
humor is distasteful.

~~~
jcburnham
...the term "gonad" is gender-neutral.
[http://en.wikipedia.org/wiki/Human_gonad](http://en.wikipedia.org/wiki/Human_gonad)

------
agentultra
Staring at this until my brain goes fuzzy, but it looks like a kind of sequent
calculus. Is that far off the mark?

~~~
urbit
I don't think so, but I wouldn't know enough to tell you. I can tell you that
I am not very interested in 20th-century formal logic, at least as a way of
defining programming, but you knew that. I think it seems like a logical
equivalent that my approach is not very interesting from the standpoint of
20th-century formal logic.

~~~
agentultra
Must be my monkey-brain trying to explore the unfamiliar by finding
similarities to what I already know.

I may of course simply be looking through a bottle (and constrained by
backwards-tracking logicians).

All of this is starting to smell of an Incompleteness Theorem of Programming
Languages.

~~~
agentultra
I think I get it now. Sort of like a sequent calculus without the logic
backtracking. Instead of proving anything Hoon just defaults it to something.
Or crashes. :)

------
pekk
Perl for type systems?

------
mritun
This is work of pure brilliance!

