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).

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.

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?)

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

   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))
     }
   }

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.

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

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.)

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

Lapidary:

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

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.

  ++  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
    ==                  ::

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...

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

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!

It's amazing how quickly words you know lose their meanings, or rather acquire new and distinct ones, in a functional context. When the iPad was released, I remember distinctly the number of people who thought the name was funny, because it reminded them of a female hygiene product. It reminded me of a female hygiene product. But it doesn't anymore...