TODO: Add Doc
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?
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's not like they submitted this to HN themselves.
Why would you write documentation if your language implementation is still rapidly evolving?
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."
What alternative do you suggest? Not putting it out there until it's production ready?
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." $ ls -lh /usr/lib/x86_64-linux-gnu/liblua5.3.so.0.0.0
-rw-r--r-- 1 root root 219K Apr 13 2016 /usr/lib/x86_64-linux-gnu/liblua5.3.so.0.0.0
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.
2, What problems are you trying to solve?
A: 1, easily integrate with C. 2, stable and modern syntax. that's all I wanted.
I have asked a few more questions about the language: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.
type
methodName(args...)
Is this a common C-ism? I'm not familiar with this code style.
Return type on separate line is shared by many other coding styles.
Personally I've come to find it nice to read, particularly when you're returning complex, long types.
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.
That should be the top link
It can do multiple assignment and unpacking collections into them too, though unlike with named arguments, that will treat the collection as an Array:
def foo bar:, baz:
p [bar, baz]
end
h = {bar: 1, baz: 2}
foo(h)https://github.com/lemon-lang/lemon/blob/master/src/peephole...
It's not a programming language if there's no documentation. It's just a compiler implementation for a dialect of something amorphous and ethereal.
That said, I kind of like the examples on http://www.lemon-lang.org/documentation and I wish the author(s) well in fleshing this out.
Would like to see how it compares against Lua in performance.
Uh, thanks for posting this strange link, I guess.