The documentation [1] appears to come from a very ordered mind. There's something very appealing about simplicity.
I see more similarity with Python than either Java or C, except for the braces and semicolons.
The description says that everything is an object, even types, though there's no way to specify types in the function prototypes so far, it seems. (Whilst that is what you would expect from a dynamically typed language, it can still be useful for optional type checking, or for later optimisation (AOT or Jit), or to make it easier to efficiently add methods for existing "types".)
Actually, what I can't quite see from the documentation is how one calls methods, whether it is necessary to put methods inside the classes, whether they dispatch only on the first argument or an implicit "this", and how inheritance is handled.
So I guess this is all at a very early stage of development.
Submitters here have developed a truly odd habit of posting a github link when a project has a site with actual documentation. And then, we get random, angry posters (visible elsewhere on this page) who don't notice the link to the actual site at the top of the github page.
Could developers please stop doing that? These 'agile development' and 'release early and often' mantras have really gone overboard.
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?
> 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.
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.
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.
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.
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.
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.
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?
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."
Not too much documentation nor examples there, right?
However, the two test files and the documentation website immediately made me think about Python and Nim at the first glance. I might give it a try as an embeddable language, it looks promising.
My guess is a lighter weight (than Lua, Python, JS) embed-able language. A quick build creates a .so that is bigger than lua as reported below, but that is a naive and probably invalid comparison metric.
make DEBUG=0 STATIC=0 USE_MALLOC=0 MODULE_OS=1 MODULE_SOCKET=1
ls -lh liblemon.so
-rwxrwxr-x 1 guest guest 271K Oct 25 08:21 liblemon.so
"Lua - Smaller footprint than Python. e.g. Look at the size of python22.dll, 824kb. A basic Lua engine, including parser/compiler/interpreter, but excluding standard libraries, weighs in at under 100kb."
And that's with Lua having many more bindings--basically, all of ANSI C, including math and stdio interfaces. Lemon only seems to bind a dozen or so POSIX routines--see os.c and socket.c.
There are other things that make it less suited for embedding than Lua. For example, Lua very carefully avoids touching any global process state. But one the very first things lemon_create() does it call srandom().
Those particular things, at least, could be easily remedied. Another reason why Lua is great for embedding is because of it's very carefully designed C API. With just a cursory look I can't tell how well Lemon compares on that score.
Looks like an attempt of a JS programmer to reinvent a lighter weight JS with aim at system programming.
If it is yet again tied to a complex, feature rich VM (a stack based one), then he went the wrong way in achieving his goal. Direct interpretation should've been the way forward for such task.
What's the motivation for this language? It seems like Javascript with destructuring assignment, named function parameters, and a few miner quirks (like sentinal)
It seems like it's meant to be easy to embed in another language's code. Like embedding LUA into a C game engine to provide a convenient way to build higher-level game logic on top of the engine.
It is. It allows to search for function declarations with the regex '^[^( ]+[(]' (or similar) -- while more common in the past, many have adopted it and keep using it.
Personally I've come to find it nice to read, particularly when you're returning complex, long types.
i'd like to see an embedded language designed to not have OO, and for the host system/language to handle the objects. I guess Lua 5.2 kinda fulfills that.
I’m mostly seeing a lot of Python. The examples show that multiple assignment unpacks collections, functions can be called with argument name assignment, and collections can be unpacked into named arguments, as opposed to using collections to replace named arguments.
I see more similarity with Python than either Java or C, except for the braces and semicolons.
The description says that everything is an object, even types, though there's no way to specify types in the function prototypes so far, it seems. (Whilst that is what you would expect from a dynamically typed language, it can still be useful for optional type checking, or for later optimisation (AOT or Jit), or to make it easier to efficiently add methods for existing "types".)
Actually, what I can't quite see from the documentation is how one calls methods, whether it is necessary to put methods inside the classes, whether they dispatch only on the first argument or an implicit "this", and how inheritance is handled.
So I guess this is all at a very early stage of development.
[1] http://www.lemon-lang.org/documentation