3 ms·

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.

by ebbv 10y ago

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.) 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.

stevedonovan 10y ago
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.
adrianratnapala 10y ago
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.
- jesserayadkins2 10y ago
  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.
  - taftster 10y ago
    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.
  - adrianratnapala 10y ago
    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.
  - jrapdx3 10y ago
    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.
- ebbv 10y ago
  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.)
jesserayadkins2 10y ago
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/ https://lorgonblog.wordpress.com/2008/03/30/pipelining-in-f/
- qznc 10y ago
  An alternative would be Uniform Function Call Syntax: https://dlang.org/spec/function.html#pseudo-member https://dlang.org/spec/function.html#pseudo-member
- ebbv 10y ago
  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?
  - jesserayadkins2 10y ago
    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.
    - mkesper 10y ago
      Python omits the new() thing, didn't miss it yet.

by ebbv 10y ago

stevedonovan 10y ago

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.

adrianratnapala 10y ago

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.

jesserayadkins2 10y ago
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.
- taftster 10y ago
  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.
- adrianratnapala 10y ago
  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.
- jrapdx3 10y ago
  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.
ebbv 10y ago
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.)

jesserayadkins2 10y ago

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/ https://lorgonblog.wordpress.com/2008/03/30/pipelining-in-f/

qznc 10y ago
An alternative would be Uniform Function Call Syntax: https://dlang.org/spec/function.html#pseudo-member https://dlang.org/spec/function.html#pseudo-member
ebbv 10y ago
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?
- jesserayadkins2 10y ago
  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.
  - mkesper 10y ago
    Python omits the new() thing, didn't miss it yet.