Hacker News .hnnew | past | comments | ask | show | jobs | submit | oneseven's commentslogin

> Note this page includes affiliate links. [Amazon will earn less money if you use these links]

Ha ha. I never thought of that as a selling point for affiliate links. I suppose Amazon will make less money if people print their own books as well.


What I really want to see from a "*-programming-language" post on HN is _why_. Why Lily?


I am curious as well. some past readme has Why sections and I am not sure why they are removed/changed

this have "Why" section https://gitlab.com/FascinatedBox/lily/-/blob/d3ace2907747106...

this have "How Lily stands out from other languages:" section https://gitlab.com/FascinatedBox/lily/-/blob/785a88534cced53...


> More importantly, this design makes it easy to compose whole programs that will never be paused by a garbage collection by avoiding cyclical structures.

Or by "breaking" cycles, which will trigger the reference count deallocation.


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.


F# and C# are typed scripting languages. F# is quite similar to python in script form (.fsx), and has OCamls expressiveness, exhaustive pattern matching, and type inference. That results in highly expressive, terse, and ergonomic domain code.

The .Net VM now supports AOT compilation.

The future is now-ish :)


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.


> Isn't a waste to essentially reinterpret an entire program that may be run 5000 times a day?

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.


a statically typed aot compiled scripting language is... not


Luau gets pretty close to statically typed and AOT compiled now. It's still a scripting language.

Even C or Rust can be a scripting language. You just integrate the toolchain to your app, same as every other scripting language.


+1 for Luau which is just realy good.


I script with Rust via cargo-script, it works great. Scripting is a task for when you want to achieve something in one file instead of a full blown application. It is not about the language, you can script in C or assembly if you so chose.


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


> why

Building a program language is like poetry. Everyone does it at some point, just most of us know never to share it.


That just moves the question to "why is this one being shared" then. I don't think "because the authors didn't know better than to avoid sharing it like 'most of us'" is a particularly good answer.


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 why: because Lua, Python, JavaScript, Janet, etc lack many or all these features. And each of these features is known to make life easier for a human programmer.


Looking through that list of features, Ruby (the dynamic language I know best) has all but 1 built-in (and the other can be added with Gems). I'm guessing Python probably has them all too (but I don't know Python that well). They're pretty common. So the why still isn't clear.


Tell me more about Ruby generics….


Want to split hairs eh?

Duck typing achieves the same thing as "generics", just at runtime vs. compile time.


Generics are implicitly compile time checks.

It’s a willful misinterpretation to read otherwise.


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.


The main Ruby implementation is also fairly easy to embed. It's just not easy to embed multiple MRI ruby instances in a single application, and it's also a lot bigger than mruby.


That was originally the point of Ruby


RPG Maker used to embed Ruby before it was cool (and before they switched to JS for web support).


The reason it exists is to provide those features when programming computers.


99.9% of the time it will be "just because"


midges can fly, so presumably they would hit the web at random points. as to why flying would be useful for the midges, if they consume biofilms on the surfaces, that's less clear. perhaps over time the midges will evolve away from flying and the spiders will have to adjust their strategy.


hmmm makes me wonder if you could train llms on gzipped text. would save a lot of tokens that way.


This is based on the Dear ImGui library/framework [0]. It's not intended, strictly speaking, for standard desktop applications. It's intended for applications that use 3d rendering, like games or CAD.

Although you could certainly use it as a desktop editor if you wanted to, I think the real value is in embedding.

[0] https://github.com/ocornut/imgui


Yes I am aware that IM UI's are popular for games - level editors etc.

Just nice to see other possibilities.


Or, concretely, migrating hoverflies. Interestingly they don't appear to be colonial.


You're referring to Evolution, seems to be a CGRA

https://hackernews.hn/item?id=44685050


Yes thank you, so many news these months.


Yes, apparently they've developed new names: Generator and Scorer. This feels a bit like "Tai's Model" https://hackernews.hn/item?id=17863514


Haha "Tai's Model" is absolutely hilarious, that gave me a good chuckle. I checked and it currently is cited 568 times.


The home page is a video of it working. Including throwing gasoline on it when it's already on fire. While it's running.


The practical demonstration in the video are fun and memorable. Realistically I'd take a lighter case without ability to submerge the whole thing in mud and set fire to it, but I'm in urban UK. It seems to be built for a warzone, milled out of solid aluminium?


Or built for a place with only dirt roads, heavy muds during a rainy season, probably very limited ability to get spare parts, and a desire to use it for years after buying it.


I'd have thought reducing weight would provide more utility (in rural monsoon areas, say) if violent contact wasn't part of the problem - it might survive crashes that destroy the bike, maybe that's the design decision.

FWIW, I'm not saying it's wrong, just notable in the apparent robustness.


Which was cool until he littered the bottle of gas into the irrigation ditch behind him


I don't think 64 RFID antennas would be that bad - you can etch them onto a PCB. That would be a pretty large PCB, I guess, but you could segment it if necessary.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: