As stevedonovan says, the 'Spike' |> Cat is probably contrived. The feature probably exists for the sake of things like

   cats.map{|c| c.name} |> print

Which is more readable to me than

   print(cats.map{|c| c.name})

It's a little jaring that it has both Cat(arg) and Cat.new(arg) syntax. But I wouldn't want to judge that without learning about the semantics that it emerges out of.

They're the same thing. The first (Cat(arg)) is the same thing as the second (Cat.new(arg)). The reason for the distinction is...umm...I'm still not sure if I want to eventually include classes as values the way that other things are values.

If you're grabbing the constructor as a function, for example, then it's a bit more sensible to use Cat instead of Cat.new. I don't know...it seemed at the time neat to allow a shorthand way of constructing something, but it's kinda wonky.

Hey, I just wanted to shout out and say that your reply here is refreshing. I appreciate that you admit that the feature is "kinda wonky" and that you're still looking at and intellectually rationalizing about such things. There's no harm in trying out the various constructor approaches, and then see how it feels in the real world.

This is refreshing from other newish (cough golang) languages which pick the "wonky" path, but go on to defend it tirelessly. Keep up the good work.

My instinct is to say that you should allow classes as oridnary values. Many interpreted languages do this with success. For example in Python, classes are objects (which happen to be callable) and some nice simplifications derive from it.

On the other hand, Lily is a type-safe language with generics. The kinds of "metaprogramming" that you would try to do with Python classes-as-objects might be done in different ways in Lily.

More theoretically, the whole point of types (as sets) was to was to be a qualitively distinct layer of things that could not be mixed up in logically paradoxical combinations with other objects. That abstruse point of logic might or might not have practical implications for a real-world programming language.

New languages are intriguing, and seems to me Lily definitely has potential, though of course I need to learn more about it.

My immediate reaction to the name "Lily" is positive, evokes a sense of calmness, and suggests an elegant, well-structured set of tools.

Regarding constructor syntax, probably "Cat.new()" is more common or conventional. I kind of like "Cat()" as it's less verbose, noisy. However I see what you mean about allowing classes as values, if not entirely clear to me how that feature would absolutely demand one syntax over the other.

I agree with other comments, Lily is an outstanding one-person effort! That its creator is self-taught only adds to its charm.

Yeah I mean it's personal preference on some level but for me the |> operator is an inelegant, sledge-hammer like solution to cleaning up that syntax which might be better solved some other way that doesn't have so many side effects (|> is much more powerful than just that one instance, and the more powerful an operator is the more trouble it can cause.)

I've heard a few complaints about this now, so I'm thinking of changing it. I wanted to cram a lot into a small space, and it didn't do so well.

The piping is more an example of how piping works with everything and that, yes, the new method really really is a method instead of some magical keyword.

But I stand by piping: https://lorgonblog.wordpress.com/2008/03/30/pipelining-in-f/

I can understand why piping is attractive, and if you want it as a language defining feature as the author that's your prerogative. :)

So is the .new() method in that case an alternate constructor (i.e. constructor code will not run only the contents of the new method will) or is it a method being invoked after the constructor code runs?

No, there's only one constructor for any given class. The body of a class is the constructor of a class, and that constructor is made available through a method called .new. It's sort of like...Python, and imagining that you get __init__ created for you automatically. It's just two ways of doing the same inner call.

Python omits the new() thing, didn't miss it yet.

An alternative would be Uniform Function Call Syntax: https://dlang.org/spec/function.html#pseudo-member

The idea was probably to show off the features; |> as a 'pipe operator' is cute. It was a bit jarring to see those different ways of constructing an object in one list.