Flow-sensitive type inference with static type checks is, IMHO, a massively underrated niche. Doubly so for being in a compiled language. I find it crazy how Python managed to get so popular when even variable name typos are a runtime error, and how dreadful the performance is.
All the anonymous blocks lend themselves to a very clean and simple syntax. The rule that 'return' refers to the closest named function is a cute solution for a problem that I've been struggling with for a long time.
The stdlib has several gems:
- `compile_run_code`: "compiles and runs lobster source, sandboxed from the current program (in its own VM)."
- `parse_data`: "parses a string containing a data structure in lobster syntax (what you get if you convert an arbitrary data structure to a string) back into a data structure."
- All the graphics, sound, VR (!), and physics (!!) stuff.
- imgui and Steamworks.
I'll definitely be watching it, and most likely stealing an idea or two.
> I find it crazy how Python managed to get so popular when even variable name typos are a runtime error
Tangential point, but I think this might be one of the reasons python did catch on. Compile checks etc are great for production systems, but a minor downside is that they introduce friction for learners. You can have huge errors in python code, and it'll still happily try to run it, which is helpful if you're just starting out.
What about when you have a long-running program. You can't both brag about NumPy, Django, and the machine learning library ecosystem while also promoting "It's great for when you just want to get the first 100 lines out as soon as possible!"
I am guessing that Python, like Ruby, is dynamic enough that it's impossible to detect all typos with a trivial double-pass interpreter, but still.
Wonder if there was ever a language that made the distinction between library code (meant to be used by others; mandates type checking [or other ways of ensuring API robustness]), and executables: go nuts, you're the leaf node on this compilation/evaluation graph; the only one you can hurt is you.
i don't think typing was the issue. at the time there didn't exist any typed languages that were as easy to use as python or ruby. (ok, not true, there did exist at least one: pike (and LPC which it is based on). pike failed for other reasons. otherwise if you wanted typed your options were C, C++ and then java. none of which were as easy and convenient to use as python or ruby. java was in the middle, much easier than C/C++, and that did catch on.
This is made by aardappel/Wouter van Oortmerssen, semi-famous OS game developer (Cube/Sauerbraten) and programming language designer. It's probably related to his recent game development work.
He also made Treesheets which is where I first heard about him. I recommend people interested in Personal Knowledge Management or related stuff check Treesheets out because while uglier compared to Obsidian there's some really great ideas in there. I won't spoil the fun but if you've got 15 minutes it's pretty easy to go through the tutorial.
Lobster's design where the borrow checker/lifetime analysis automatically inserts reference counters if it can't statically determine lifetime is so vastly superior to Rust's approach (force you to do it by hand like it's 1980 and you are the compiler) that it's not even funny.
Readit News
Flow-sensitive type inference with static type checks is, IMHO, a massively underrated niche. Doubly so for being in a compiled language. I find it crazy how Python managed to get so popular when even variable name typos are a runtime error, and how dreadful the performance is.
All the anonymous blocks lend themselves to a very clean and simple syntax. The rule that 'return' refers to the closest named function is a cute solution for a problem that I've been struggling with for a long time.
The stdlib has several gems:
- `compile_run_code`: "compiles and runs lobster source, sandboxed from the current program (in its own VM)."
- `parse_data`: "parses a string containing a data structure in lobster syntax (what you get if you convert an arbitrary data structure to a string) back into a data structure."
- All the graphics, sound, VR (!), and physics (!!) stuff.
- imgui and Steamworks.
I'll definitely be watching it, and most likely stealing an idea or two.
Tangential point, but I think this might be one of the reasons python did catch on. Compile checks etc are great for production systems, but a minor downside is that they introduce friction for learners. You can have huge errors in python code, and it'll still happily try to run it, which is helpful if you're just starting out.
I am guessing that Python, like Ruby, is dynamic enough that it's impossible to detect all typos with a trivial double-pass interpreter, but still.
Wonder if there was ever a language that made the distinction between library code (meant to be used by others; mandates type checking [or other ways of ensuring API robustness]), and executables: go nuts, you're the leaf node on this compilation/evaluation graph; the only one you can hurt is you.
As long as warnings are clear I’d rather find out early about mistakes.
https://github.com/aardappel/treesheets
https://news.ycombinator.com/item?id=47239042
> Dynamic code loading
This is what good language design looks like.
I admit this was mostly out of simplicity/convenience/familiarity.
If you're a Rust person, you'll appreciate that Lobster lets you use similar exhaustive switches to Rust's enum instead: https://github.com/aardappel/lobster/blob/master/tests/types...
https://m.youtube.com/watch?v=fjtVsYqAR3s