Looks very nice! The templating and server support makes Lily look like a nice "next step" for PHP developers/shops/projects. PHP's "installed everywhere" feature is pretty hard to beat, especially for host-it-yourself projects like Wordpress. I could see such a language catching on for custom, in-house development though; for example to implement microservices.<p>It's nice to see that there's a trend for such small, (relatively) simple languages to include nice features like first-class functions, convenient lambda notation, sum types, type inference, etc. A few years ago it seemed most new languages were just nitpicking over syntax, without bringing much to the table. I'm glad to see we're leaving the local minimum of "class-based OO with slight different static method mechanism"!
Love it. It's like someone used C# a lot and got fed up with how much cermony goes into making a simple sum type and exhaustive handling of the variants.<p>A pet peeve of mine is the sloppyness by which .NET allocates things like iterators etc. I'd very much like to see zero-cost abstractions in a new language, so that there is no surprise differences between various ways of iterating over collections. I read it only quickly but couldn't find anything related to how enumeration/iteration works under the hood.
Hello jesse, it is one hell of an inspiring work!<p>I read from your blog that you are self-taught programmer. Would you mind sharing something about yourself? In particular, I'm interested in area like what do you do for your day job? Is it programming related? What resources did you come across that you find particularly useful in making lily? Anything would be appreciated!
I like some of the things they're doing here but I have a big problem with the language design choice of having multiple valid syntax doing the same thing (e.g. declaring a new class as Cat('Spike'), Cat.new('Spike') or 'Spike' |> Cat.)<p>I tend to subscribe to the philosophy that language designers should be as strict as possible; choose the "best" syntax for doing something and only allow that unless there's really compelling reasons for alternatives.
The language itself might be quite different, but a few of the design parameters remind me of Wren[1], another language that's on my "try to embed it somewhere" list...<p>[1]: <a href="https://github.com/munificent/wren" rel="nofollow">https://github.com/munificent/wren</a>
I wish we had more actually decent statically typed interpreted languages (ones that are easily embeddable, to be precise), this looks very interesting.<p>And no, AngelScript REALLY does not count as anything interesting. (unless you really really like C++)
I really dig the syntax of this language, I must say. Great job. I'm interested in the embeddability of this language. There doesn't seem to be any documentation on the API features, short of looking through the source code. I would be greatly interested in this. Specifically, how to add calls that the Lily code can call, or how to call Lily code from within the interpreter.
Is Lily a cat?<p>Anyway, somebody hire this guy. I'm sure someone that can do this is qualified to make web CRUD for lots of money (should he so desire).
• Have you considered allowing returning multiple values, like in Lua and Go, and also returning errors through them? esp. instead of exceptions? (Though I suspect this could be problematic to match with the sweet |> pipe operator)<p>• Have you considered supporting Lisp/Scheme-like or Rust-like macros? or Rebol-like DSLs? (though I suppose the latter are probably strongly tied to Rebol's minimalistic syntax)
I don't like this syntax: "if: {".
Using ":" for a one line statement is ok, but in most cases you have to use multiple lines and end up with two identifiers that represent the same thing.
Maybe you can make the "{" for multiple lines and ":" for one line.
I like to have an indentifier for one line statements, unlike the C approach.
I registered #lily on Freenode if you want it.<p>Impressive work! I think this is the first relatively conventional language that I've gotten really excited about in a while. It's a really nice blend of features and a quality implementation. Definitely going to use it next time I embed a language.
Does it support operator overloading? I tried it quickly (`define +(...){...}`) but it didn't work. Maybe there is a notation for it but I couldn't find it in the tutorial.
This looks pretty cool.<p>When ever I discover a new language, I try to find out why it was created.<p>Why did you make Lily? Are you aiming to solve any specific problems, or is it a fun project you wanted to do?
<p><pre><code> print($"My name is ^(@name).")
</code></pre>
I don't understand why anyone would still require special notation for interpolated strings, when we have the awesome and unambiguous string interpolation syntax introduced by Swift (granted, this project was started in 2011, before Swift).<p>> Reference counting has the benefit of giving consistent, and more easily measured performance. There's no fear of the garbage collector suddenly leaping into action right at the worst time, or having to tune the collector to minimize pauses.<p>LoL. Refcounting can lead to just as long pauses as GC, if your reference is the last reference to a huge object graph.