> Why would anybody use a programming language with zero documentation for anything? Are we supposed to guess the language and its features from a single five-line hello world program?

As someone who has done a handful of compiler/interpreter projects: I don't think that they expect anyone at this point to be using that language. They're targetting it at language geeks like myself (who go and dig around the source, which I just did). Maybe in some years' time this project will reach a stage where end user docs matter.

A little more verbose readme would have been nice, though. Things that I did not find out by looking at the examples/docs, but I care about:

  * what paradigm? imperative, functional, etc?
  * interpreted or compiled language?
  * what's the target? interpreter, a bytecode VM, LLVM, compile-to-C, native codegen?
  * static/dynamic typing? type inference?

By looking around the code, I think that this is an interpreted language with dynamic typing that's implemented with a stack-based bytecode virtual machine. Not unlike Lua, Python or Ruby, that is.

It is dynamic, curly braced, garbage collected, coroutines. Some really squeaky clean C code too. One can immediately tell this is a great code base to read and learn from, at the very least.

What's so squeaky clean about hiding a goto inside a macro?

I guess you're referring to this[1]. I'd actually call that usage svelte. The macro is undefined not far after it's use in the file, and makes the section it's in far more readable.

[1] https://github.com/lemon-lang/lemon/blob/9a0b3dbc854532b31f7...

Why does it have the do-while(0)?

It's a safeguard because {} statement blocks are optional [1].

[1] https://stackoverflow.com/a/923833/2561675

I'm a language geek and none of the above is what I want to see when I read about a new language. What I want to know is, what does this language offer that no other language does? What platform it runs on or whatnot is trivial boring detail that I might want to know afterwards if the language offers something interesting to try out.

>What platform it runs on or whatnot is trivial boring detail

Not caring about actual usage mechanics / acting like they are trivial details makes me question a lot about your perspective.

Language X runs on platform A, it offers little innovative but merely re-expresses what you're already used to doing on platform A in another language.

Language Y has some really innovative features that no other languages are currently doing. There is currently no reference implementation.

Which of these is the more interesting one to a language geek? The former might be more interesting to a "platform A" geek. Or someone who uses platform A in production.

The perspective is being interested in language design rather than "the next big thing". A language that doesn't change the way you think about programming is not worth learning, because you're only re-learning what you already know. In fact, learning such language is trivial and all you really need is a grammar reference from which you can deduce the rest. If it runs on platform A which you're familiar with, you can take advantage of platform A's libraries and become productive in X in no time.

Lua.org's Lua is a VM, but a register based one. Perl 6 is another odd case of register based VM

In all fairness: there seems to be a little bit more of documentation on http://www.lemon-lang.org So, whoever posted this to hacker news should have used that link rather than the GitHub link and of course, it seems to be way to early in development to post it at all. I have some quite unfinished projects of mine on GitHub, but I would never post a link to them until they are in a state where they would be relevant to a larger community.

Wow you're entitled. The author owes you nothing!

It's not like they submitted this to HN themselves.

> Why would anybody use a programming language with zero documentation for anything?

Why would you write documentation if your language implementation is still rapidly evolving?

Regardless, shouldn't you at least write documentation to isolate and identify confusing points of your rapidly evolving language? It's almost a matter of good practices; explaining something is usually the best way to learn it.

It depends. The language's author probably didn't post this, so who knows what stage of development his project is at.

You should write the documentation first. Otherwise what are you writing?

You're writing code for a purpose, obviously. Sometimes that purpose isn't clear from the outset, hence exploratory programming. So what would you be documenting at this point exactly?

Developer: Read the source code!

I've seriously seen this kind of response from developers while looking for help using melt (Media Lovin' Toolkit). You typically see this kind of response for better documentation: "melt is for developers. Use one of the GUI front ends to generate a script for you or read the source code."

> Why would anybody use a programming language with zero documentation for anything?

What alternative do you suggest? Not putting it out there until it's production ready?