31–40 of 50 posts
> for v in values: { Both colon and {... why? And it seems very mixed in the example.
I see this so often in new languages, making poor choices seemingly only to distinguish themselves from existing languages
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.
The .Net VM now supports AOT compilation.
The future is now-ish :)
What I really want to see from a "*-programming-language" post on HN is _why_. Why Lily?
> why Building a program language is like poetry. Everyone does it at some point, just most of us know never to share it.
I would like to understand the motivations for building another programming language when in fact, firstly, a lot of code is being written by Claude and the like, and secondly, the existing languages and low level options like C, Assembly have become more accessible now thanks to AI coding tools.
Earlier quoted context omitted.
Is Ruby easy to embed in a C program?
Yes -> https://mruby.org It's also incredibly easy to extend the main Ruby implementation with C, C++, Odin, Zig, Rust, Fortran, etc... Literally a few lines.
What I really want to see from a "*-programming-language" post on HN is _why_. Why Lily?
Has anyone yet designed a language with the explicit goal of being cheapest/easiest to use by an AI coding agent?
Earlier 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.
This is a dated prejudice that I shared.
To get started coding with AI I made a dozen language comparison project for a toy math problem. F# floored me with how fast it was, nearly edging out C and Rust on my leaderboard, twice as fast as OCaml, and faster than various compiled languages.
Compiling could in principle be fastest, if we had compilers that profiled hours of execution before optimizing code, and only then for "stable" problems. No one writes a compiler like this. In practice, Just In Time interpreters are getting all the love, and it shows. They adapt to the computation. My dated prejudice did not allow for this.