[lumpypua]

https://github.com/urbit/urbit/blob/master/urb/zod/arvo/ames...

There are hundreds of lines of noise. This makes perl and forth look absurdly readable. What on earth do the directory and file names mean?

I dunno how familiar people on HN are but the original author of urbit is Mencius Moldbug, a neoreactionary blogger. His style of writing is absurdly obfuscated and purposely impenetrable if containing some interesting ideas. The exact same thing is true of urbit. Interesting ideas but obfuscated the point of utter inaccessibility.

Here's sort of the wider group of blogs he philosophically aligns with:

http://rationalwiki.org/w/images/d/d5/Scharlachs-visualizing...

His views are likely unpopular around here but I am a fan of a bunch of those other blogs, and I've tried to dive into Moldbug's blog Unqualified Reservations a few times. It's kind of insane—the guy is clearly very intelligent—yet writes in his own discursive style that is absolutely opaque.

[urbit]

Stepping away from the Algol keyword tradition is obviously a risk. At the same time, after using a keyword-free syntax for a while, reserved words feel really weird.

Someone just emailed and pointed out that he couldn't check out Urbit on Windows, because it has a file con.c. Oh, right, reserved filenames. How are reserved words different? The difference is - you're used to them.

Also, perceived usability (while it matters for marketing) is not the same thing as actual usability. Actual usability is something you only find out when you try to actually use something. We have a good bit of experience inflicting the syntax on coders of various abilities and backgrounds, and we're pretty satisfied with the result.

It helps that the syntax is quite a bit more regular than it appears at first glance. It's much more regular than Perl, and it also comes with a vocalization model that makes it easy to say out loud.

For instance, "=+", which more or less declares a variable, is "tislus." A lot of things like "=+" also start with "=", ie, "tis." You wind up learning about a hundred of these digraphs or "runes," which is a lot less than, say, Chinese.

Speaking of Perl, have you heard - Larry Wall is a Christian? I don't think this makes Perl a Christian programming language, though.One of the joys of our engineering inheritance from the 20th century, which was really humanity's golden age of political insanity, is that we get to stand on the shoulders of loons. We fly Christian astronauts into space on Nazi rockets programmed by Communist physicists. And it works...

[jrochkind1]

> it also comes with a vocalization model that makes it easy to say out loud. > For instance, "=+", which more or less declares a variable, is "tislus." A lot of things like "=+" also start with "=", ie, "tis." You wind up learning about a hundred of these digraphs or "runes," which is a lot less than, say, Chinese.

Uh... you realize this isn't helping to convince anyone?

The project may well be brilliant rather than ridiculous, but if so I suspect you're gonna have to come up with a better pitch to get people interested enough to invest the time to see it.

Your made up language where every punctuation mark is a phoneme or something... it's not helping.

And I should hope any programming language would indeed be easier to learn than Chinese (or just about any natural language).

[urbit]

Don't worry - the test of a system is what it can do. If we were ready to show you what it can do, we'd have released it intentionally instead of unintentionally.

It's very difficult for a language, good or bad, to compete on its own merits or even demerits. C is a better language than Pascal, but people didn't start programming in C because of that - they started programming in C because the native language of Unix was C, and they wanted to program in Unix. Why did they want to program in Unix? Because, relative to its competitors in the minicomputer OS market, Unix was a better way to solve their problems. This is the normal way that new languages achieve adoption - they ride on the back of a new platform, which rides on the back of new solutions to (typically) new problems.

Today you see a lot of apps like Buffer and Slack, which are very successful in terms of userbase and even revenue. From a certain perspective, the value these apps are adding is very minimal - Buffer is... what, cron? And yet, there is a considerable distance between an AWS box in the cloud and a Buffer instance. A lot of value actually is being added.

Most of the code in a product of this type is actually the (usually somewhat) general framework that sits between the Linux ABI and the application logic/UI. Essentially there's a type of Greenspun's Law in play. If you build a layer like this, but as a true operating environment rather than an internal framework, the result is a VM in which the distance from a virgin instance to many of these kinds of apps is much smaller. In a familiar Valley pattern, they then become commoditized and have more trouble extracting rents.

If it's possible to provide this kind of value, which we certainly haven't yet demonstrated, I can assure you quite confidently that a flashcard or two is not an obstacle. I'm in my 40s, so I know how hard it is for a middle-aged dog to learn new tricks. But it's not that hard.

[jrochkind1]

On the other hand, if people had found C very difficult to program in, it probably would have hurt the adoption of unix.

In fact, if I understand the history, developers and sysadmins generally found C an improvement on their previous tools, and generally saw how it was so fairly quickly, without a lot of convincing.

You keep insisting that the... oddities of your language aren't really barriers, aren't as difficult as they seem, really aren't much worse than the conventional way to do things. But I think I've missed it if you've tried to explain why they are supposed to be better, what the justification is for such an unconventional approach, what it's supposed to actually accomplish to be worth it.

(beyond no reserved keywords in the domain of a-zA-Z, only reserved punctuation instead... which I don't think is convincing many people, who haven't really had much of a problem with reserved keywords).

(And the 'reserved keywords' thing doesn't even apply to your "lapidary" thing, which you insist really isn't that hard to deal with once you get used to it, which may or may not be true for people... but what makes it _better_, what's the point? Why not just use meaningful variable names everywhere, instead of taking an extra step to decide if it 'needs' meaningful variable names, or if instead obfuscated 'lapidary' variable names are sufficient? Maybe they're sufficient maybe they aren't, but what's the point, what's the harm in just using meaningful variable names in case they are helpful for a future reader?)

[urbit]

If you look below I've made arguments for all these things, but let me try to address them here. Compare

  ++  add
    |=  [a=@ b=@]
    ^-  @
    ?:  =(0 a)  b
    $(a (dec a), b +(b))

to

   attribute add {
     function(left-operand: atom, right-operand: atom)
     produce atom
     if equals(0, left-operand) {
      right-operand
     } else {
        recurse(left-operand (decrement left-operand)), 
                right-operand (increment right-operand))
     }
   }

As for the variable names, I can think of very few programmers who would insist that "left-operand" and "right-operand" are better names, in this context, then "a" and "b".

Using "a" and "b" accurately expresses the simplicity of the algorithm, and nothing could be easier to read. OLV in "add" says: there is nothing interesting here. "left-operand" and "right-operand" says: there is some semantic meaning here, which you have to trouble your brain to understand. But actually, it's just pointless wordiness - in this case.

As for the syntax, you no doubt can read my wordy example better. But a programming language is a professional tool, not a toy. Anything new demands a genuine investment to learn - this investment has to be paid off by actual productivity.

And people are, as I've said, much better at learning random associations than they think. Again, we've taught this syntax to everyone from Haskell jocks to JS cruft-jockeys to innocent CS 101 victims. The biggest problem - and it is a problem - is not that it it is hard, but that it seems hard.

[Locke1689]

Is the given text your attempt at eliminating reserved keywords by using nonsense as keywords?

Other languages have simply decided to use contextual keywords, which preserves familiarity and flexibility.

[urbit]

Good lord, no! Hoon has no reserved words at all.

The nonsense words are all names. This is entirely a style choice. The actual name syntax is roughly Lisp's - for instance, (my-long-function arg1 arg2) does the same thing (roughly) in Hoon as in Lisp.

In the "lapidary" Hoon in which most of the kernel is written, facets (variable names, roughly) are meaningless TLV strings, usually CVC (consonant-variable-consonant).

The user experience is much the same as with Greek letters in math: you remember the binding between symbol and semantics if you know the code you're looking at. If you are learning the code, your first task is to learn that binding. Once you know the code, there is no quasi-semantic intermediary - a meaningful name - between the symbol and the concept.

I think our small sum of experience with this daring idea is that sometimes, it works better than other times. Basically, TLV naming is appropriate for code that is simple, but not trivial. (Trivial code, like "++add", is "ultralapidary" and gets OLV names - like "a" and "b".)

Ideally all of the Arvo kernel and Hoon self-compiler would meet the TLV standard of quality. All of it is written this way, though. In general, if you should be writing lapidary code, you know it, and if you don't know you shouldn't. (And should use more or less normal names as in any Lisp.)

[Locke1689]

In the "lapidary" Hoon in which most of the kernel is written, facets (variable names, roughly) are meaningless TLV strings, usually CVC (consonant-variable-consonant). The user experience is much the same as with Greek letters in math: you remember the binding between symbol and semantics if you know the code you're looking at. If you are learning the code, your first task is to learn that binding. Once you know the code, there is no quasi-semantic intermediary - a meaningful name - between the symbol and the concept.

Have you been reading a lot of Heidegger or was this an independent decision?

[urbit]

The latter. :-)

[melloclello]

Do you have any examples of what "non-lapidary" Hoon might look like?

[zerker2000]

I'm not sure much strictly non-lapidary hoon exists, but for samples marginally less lapidary than the kernel, I would like to point you to a simple algorithm translation at https://gist.github.com/MichaelBlume/17a227cc839f52f68c97, and the twitter library /main/lib/twitter/core.hook in the standard distribution.

[likeclockwork]

Please define "TLV", "OLV", and "lapidary".

[urbit]

Three-letter variable, one-letter variable, http://www.merriam-webster.com/dictionary/lapidary.

[tromp]

Three/One Letter Variables.

Lapidary:

(of language) engraved on or suitable for engraving on stone and therefore elegant and concise.

[likeclockwork]

https://github.com/urbit/urbit/blob/master/urb/zod/arvo/eyre...

What is pimp? What is pest seam marl?

What do any of these names mean? What does any of this do? Forget not knowing the syntax, the names look like gibberish.

[urbit]

I think the classic analogy is "grep." But they are commented, at least:

  ++  pimp              ::  traced request
    $:  ful=?           ::  | === HEAD
        fur=(unit mark) ::  type goal
        hen=duct        ::  event trace
        som=seam        ::  logical request
        pez=pest        ::  request state
        sip=marl        ::  injected scripts
    ==                  ::

I think this is not at all an unusual data structure for one to find in an HTTP server, no?

Now, this style (four-letter lapidary arm names, usually not nonsense strings but nonsense words) works in some places but not others. Frankly, %eyre is not exactly a triumph of the lapidary style...

[likeclockwork]

This Hoon code is very pretty but the English content of the names is extremely low.

I mean.. reading a programming language I don't know, okay.. I don't expect to be able to understand much. But syntax and semantics aside the names are a language of their own with no attempt at referencing anything that might even be a little bit similar.

It's as though every time you needed to name a concept you came up with a unique word for it. This reads like poetry in a language I will probably never understand.

The docs are written in English but I don't see a lot of signal in here and no real explanation of this vocabulary you've created.

I am having a hard time believing any of this. I would need to see an example of non-code communicative writing in this language. An email or chat excerpt, something with someone saying "call pimp with the seam to get the marl" or however you would phrase whatever it is. Do you verb these nouns? DO you use English prepositions and adjectives when discussing them?

I mean this is not just reading a programming language I don't know, it's reading a programming language with all the names in a foreign language. So even if I could understand broadly what's going on here.. I cannot.

Searching around the repo to try to find out wth `marl` is I found this:

    The fundamental hoon structure used to generate XML is a    manx. A manx is composed of a marx and a marl, representing an XML node

Yeah.. this is like esolang-level opaque. I'm afraid to even run this on my computer.

[urbit]

Frankly, it always surprises me that people are willing to randomly run other peoples' C code! It's really quite plausible that I'm just out to steal your Bitcoin wallet.

The above are all data structures - not even functions. So we say "a pimp" or "a marl" or whatever. For precision, we might say "slam a gate on a pimp," but everyone will understand you when you say "call a function on a pimp."

Then, we refer to the comments (written in English) to see what a pimp, etc, is. Documentation is admittedly a problem, but it's not any more or less a problem than in any other language, I feel. Obviously, we could have more of it!

[likeclockwork]

What did you feel when you wrote "slam a gate on a pimp" just now?

[MrBuddyCasino]

He does have really odd political views. I know HN shouldn't be about politics, but this was a really interesting read:

http://www.thebaffler.com/blog/mouthbreathing-machiavellis/

It looks like he thinks that the benevolent-dictator-for-life model is how countries should be run. And Peter Thiel seems to agree with him.

[VexXtreme]

They even seem to have a subreddit: https://www.reddit.com/r/DarkEnlightenment/

The whole "ideology" is basically just fascism and institutional racism dressed up as something else. Despicable. I would never use any software from some Hitler-reboot type of person. Don't empower and feed such people. They are usually narcissistic megalomaniacs who think they are fit to rule and tyrannize others.

[lexcorvus]

Before accusing someone of being a "Hitler-reboot type of person", perhaps you should, you know, actually read what they have to say about Hitler. For example:

Since most people are neither historians nor philosophers, the fact that Hitler was on the extreme Right, and this Reaction is also on the extreme Right, raises some natural concerns. Again: the only way to face these concerns is to (a) provide a complete engineering explanation of Hitler, and (b) include an effective anti-Hitler device in our design.

—Mencius Moldbug, http://unqualified-reservations.blogspot.com/2009/09/gentle-...

In other words, an explicit design goal is to avoid Hitler-like outcomes (because, duh). Thus, the accusation that he's a "Hitler-reboot type of person" reflects either simple ignorance—which you can fix by doing a little reading—or outright mendacity—for which, I'm afraid, there may be no cure.

[VexXtreme]

I mean look, I understand what the philosophy is about, and I think it would never work in the real world. We've learned time and again that entrusting a lot of executive power to one person is a horrible idea - extremely exploitable and subject to corruption.

Looks almost like a product of a deranged autistic mind. I have no interest in such asinine "philosophies".

[Padding]

> I have no interest in such asinine "philosophies".

I bet no one does .. the real issue is how to decide on what is "asinine". After all, why are your views and beliefs any more valid than any one else's?

[VexXtreme]

Normally I'd just tell you that I don't subscribe to moral and philosophical relativism, but for the sake of this discussion, I will oblige in explaining further.

First off, what is the definition of valid and correct? What is the metric that makes a certain belief more "valid" than some other belief? Well, over the millennia, we humans have arrived to certain definitions of what's good and what's bad in the context of preserving life, civilization, society and liberty. In that sense, things that harm those concepts can be defined as bad and those that further those goals are good. History has shown, time and again, that empowering one person with a lot of executive power inevitably leads to tyranny, oppression, genocide, slavery and other completely horrible things that we seem to have been able to get rid of (more or less).

So when someone rejects thousands of years of historical evidence as to what happens with such regimes and where they eventually lead, and proposes instating one again, I can only call it either asinine (if the author is well-intentioned) or evil (if they simply want power over others).

In more practical terms, liberty, self-determination and self-ownership are sacrosanct to a lot of people. In order to take those things away, you will need a lot of people, guns and body bags.

[niels_olson]

What if his engineering concern with Hitler is the the mode of failure?

[loqi]

Would you use software from some anti-gay-marriage person? Do these types of policies sound at all pathological to you upon further reflection?

[jarcane]

That is quite actually one of the creepiest things I've read in a while. I've always been fundamentally uncomfortable with a certain wing of Valley thought, but man, even I didn't think it went that far and in such lofty halls.

[mikeash]

I thought it was pretty common to think that a benevolent dictatorship was a great way to run a country. The problem is in making sure your dictator is benevolent. Nobody knows how to do that, so we try non-dictatorial systems instead.

[MrBuddyCasino]

Exactly.

[javaexpert101]

Yarvin's weird political views aren't really part of Urbit.

[valvar]

I haven't read all of Unqualified Reservations, but what I have read so far (Dawkins, Open Letter, Gentle Introduction) has not been difficult to read at all. Perhaps long and winding, but not opaque. In fact, I find Moldbug to be much more accessible than his sources of inspiration (which are standard fare if you even want to even begin with political theory).

[lexcorvus]

Yeah, people who think Moldbug is opaque should try reading a little Carlyle. A few years back I spent a week powering through Carlyle's main political works (Chartism, Latter-Day Pamphlets, Shooting Niagara, and the Occasional Discourse), and it took a couple of days just to get acclimated to his writing style. By comparison, Moldbug is a breeze.

[ricardobeat]

Wow, now I'm curious about the language. Looks like made-up gibberish at first sight:

    ++  lax                                           ::    lax:as:go
      |_  [her=ship dur=dore]                         ::  per client
      ++  cluy                                        ::    cluy:lax:as:go
        ^-  [p=life q=gens r=acru]                    ::  client crypto
        ?~  lew.wod.dur  !!
        ?.  =(fak.ton r.i.lew.wod.dur)  ~|([%client-wrong-fake her] !!)
        :+  p.p.q.i.lew.wod.dur
          q.q.i.lew.wod.dur
        (haul r.q.i.lew.wod.dur)
      ::

[urbit]

Suppose we wrote this with keywords. I can't stomach a naked keyword so I'll put a colon on the front. We might write:

  :function lax {
    :object :tuple{her: ship dur: dore}  {
      :function cluy {
        :produce :tuple{p: life q: gens r: acru}
        :ifno lew.wod.dur  :error
        :unless (equals fak.ton r.i.lew.wod.dur) {
          :record :tuple{%client-wrong-fake her}
          :error
        } :then {
          :tuple {
             p.p.q.i.lew.wod.dur
             q.q.i.lew.wod.dur
             (haul r.q.i.lew.wod.dur)
          }
        }
      }
    }
  }

Is this better? Arguably, it's easier to learn. But I'm not sure I would regard it as better.

Also, for your convenience we've assigned CVC nonsense names to all the ASCII characters. Pasting from the source:

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

One of the problems with using these handy little glyphs in syntax (and an even worse problem with using Unicode glyphs in programming, btw) is that "semicolon" is not convenient to say. The length of the vocalization matters a lot to how you think about a symbol, even if you don't often say it.

[axlprose]

> Is this better? Arguably, it's easier to learn. But I'm not sure I would regard it as better.

For what criteria of 'better'?

I can't really present an argument either way since I'm not familiar enough with the language, but it does seem like it requires a fairly high amount of cognitive overhead for... I'm not sure exactly. Keystrokes?

There is something to be said about the efficiency of glyph-based writing systems like kanji, so APL might've been on to something, but overloading common ascii characters and creating meaningless words? That seems like a lot of noise for brains without extraordinary working memory to filter out on a regular basis.

I'm sure thinking and writing in it are fine (even brainfuck isn't difficult to write), but for something intending to be the backbone of the internet, I would've assumed maintainability to have been the most important design goal.

[urbit]

Essentially, I'd say most peoples' brains are better at associative memory than they think they are.

When you see a digraph like -> or ?: in C, do you think "hyphen greater-than" or "question-colon"? Your brain long ago learned to treat these as individual symbols, not strings of two characters. And this despite not even having easy-to-say names for them. (In Hoon they are "hepgar" and "wutcol" respectively.)

[gpvos]

The digraph operators are not a large problem for me. I'm used to Perl, so I'm sure I can master them. But what is a lew.wod.dur, and what is lax supposed to mean? What happened to variable names that made at least a nod to descriptiveness? Why do you think adding a two-word comment to a function is enough to make it all crystal clear?

[JDulin]

As a coder of "various ability and background", I found that Hoon source code was a relaxing joy to read and write after a few weeks of dedicated study.

It is, believe it not, designed with readability as a first-class priority. However, a common meme in language design today is that "Code should read like prose." This sounds good, because it means languages are easy to learn. Who wants to learn a bunch of symbols and patterns and junk? I want to code (Python, JavaScript, etc.) now!

But when we program, we aren't dealing with the trivial knowledge English is efficient at exchanging in an email, or the subtly it portrays in a novel. We are talking to a computer. The ideas we explain to a computer are often much more complex than we can explain precisely with English in any reasonable amount of time, so complex we often lose ourselves in them.

Mathematicians and physicists gave up on making human language explain specific technical ideas long ago. Have you ever read a paper on cosmic topology or quantum field theory? There's a comforting padded bumper of English framing the ideas, but the reason the paper is published is in symbols which would appear to the uninitiated as "hundreds of lines of noise." The English is usually just an introduction.

I think Hoon is wonderful [1] because it has both power and predictability. Power lets you express complex ideas concisely and easily, while predictability lets you read and understand someone else's code without frustration. Perl is powerful because it's dense, but it does so at the cost of predictably. Mathematics symbols are terribly powerful, but wildly unpredictable [2]. Python is sort of powerful and sort of predictable. The seductiveness of English simulacra programming languages is that you often don't realize how much power you're giving up because it's just so relaxing to not think about symbols and patterns when your code has the predictability of an email.

Hoon's power is in the zoology of runes (Digraphs) and it's predictability is rooted in its homoiconicity. Every symbol on the keyboard is utilized to build powerful runes, each of which in turn is utilized to append predictable structure onto your AST. When you understand the basic patterns of these constructions and reductions, it's not hard to read someone else's library and understand it in an afternoon. I can't say the same for the Java SDKs I come across. [3]

I'm not saying it isn't inaccessible at first and doesn't take time to learn. I am saying it is worth it.

[1] It's my favorite language - It is just plain fun.

[2] That's why the English frame around a physics paper is there - It tells you what each symbol represents in this paper and what they're trying to do.

[3] The language design also includes several decisions to avoid the pratfalls of other homoiconic languages (Primarily the readability of Lisp), but those are explained in the docs.

[rgrieselhuber]

Is that image of associated blogs generated using some tool?