13 points | by FascinatedBox 3 days ago ago
5 comments
What 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.
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.
What 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.
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.