Lily Programming Language
lily-lang.org
Lily Programming Language
1–10 of 50 posts
Re: Lily Programming Language
#2What I really want to see from a "*-programming-language" post on HN is _why_. Why Lily?
Re: Lily Programming Language
#3What I really want to see from a "*-programming-language" post on HN is _why_. Why Lily?
The README on gitlab at least has a sentence or two on that: https://gitlab.com/FascinatedBox/lily
> An interpreted language with a focus on expressiveness and type safety
Personally I think typed scripting languages could be the future. They should support AOT compilation where necessary.
Re: Lily Programming Language
#4What I really want to see from a "*-programming-language" post on HN is _why_. Why Lily?
From the link:
> Key features of Lily:
> Built-in template mode
> Embed/extend in C
> Single-inheritance classes
> Exceptions
> Generics
> Algebraic data types (with Option and Result predefined).
Re: Lily Programming Language
#5What I really want to see from a "*-programming-language" post on HN is _why_. Why Lily?
The README on gitlab at least has a sentence or two on that: https://gitlab.com/FascinatedBox/lily > An interpreted language with a focus on expressiveness and type safety Personally I think typed scripting languages could be the future. They should support AOT compilation where necessary.
Why do you think that's the future?
Isn't a waste to essentially reinterpret an entire program that may be run 5000 times a day?
AOT compilation, how is that different than make && run?
At some point, you have a compiled language, if it's quick to compile, you're doing the AOT yourself, the scripting is an illusion. Pun intended.
Re: Lily Programming Language
#6What I really want to see from a "*-programming-language" post on HN is _why_. Why Lily?
From the link: > Key features of Lily: > Built-in template mode > Embed/extend in C > Single-inheritance classes > Exceptions > Generics > Algebraic data types (with Option and Result predefined).
That’s what. Not why.
Re: Lily Programming Language
#7What I really want to see from a "*-programming-language" post on HN is _why_. Why Lily?
The README on gitlab at least has a sentence or two on that: https://gitlab.com/FascinatedBox/lily > An interpreted language with a focus on expressiveness and type safety Personally I think typed scripting languages could be the future. They should support AOT compilation where necessary.
a statically typed aot compiled scripting language is... not
Re: Lily Programming Language
#8Earlier quoted context omitted.
From the link: > Key features of Lily: > Built-in template mode > Embed/extend in C > Single-inheritance classes > Exceptions > Generics > Algebraic data types (with Option and Result predefined).
That’s what. Not why.
The reason it exists is to provide those features when programming computers.
Re: Lily Programming Language
#9Earlier quoted context omitted.
The README on gitlab at least has a sentence or two on that: https://gitlab.com/FascinatedBox/lily > An interpreted language with a focus on expressiveness and type safety Personally I think typed scripting languages could be the future. They should support AOT compilation where necessary.
Why do you think that's the future? Isn't a waste to essentially reinterpret an entire program that may be run 5000 times a day? AOT compilation, how is that different than make && run? At some point, you have a compiled language, if it's quick to compile, you're doing the AOT yourself, the scripting is an illusion. Pun intended.
Isn't it a waste to run a test suite for a program that would run 1M times a day in production?
The key adjective here is successfully run. You want to detect any errors as early as possible. Ideally even at the early stages of writing the script, when a typechecker is already able to point at certain errors, and thus help avoid missteps in further design.
Re: Lily Programming Language
#10Earlier quoted context omitted.
The README on gitlab at least has a sentence or two on that: https://gitlab.com/FascinatedBox/lily > An interpreted language with a focus on expressiveness and type safety Personally I think typed scripting languages could be the future. They should support AOT compilation where necessary.
a statically typed aot compiled scripting language is... not
"Scripting" is a role: an embedded, human-friendly, compact language, also suitable for interactive work / REPL.
(Laugh all you want, but Haskell has a rather nice REPL, and can work as a scripting language.)