Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Lobster Programming Language

strlen.com

Post reply on HN
Print view View original

11–20 of 171 posts

Re: The Lobster Programming Language

#11

Post by andrelaszlo »

Aardappel wrote: post #8
c3534l wrote: post #3

I don't really see the point in using Python syntax and then throwing in a handful of random differences that don't have anything to do with the domain you're working in. Syntax level support for vector operations or for shader interopability I would get. Making for loops follow some randomly different syntax, I don't see the point of that.

It is not intended to be Python compatible, it merely has indentation based syntax that is similar. The cases where it differs from Python are actually for good reason: unlike Python that only has built-in control structures, here any function can look like if/for/while if it takes a lambda body.

This seems like a cool way to make an ad hoc dsl. I'm not a game programmer but I imagine it could be useful.

Re: The Lobster Programming Language

#12

Post by threatofrain »

c3534l wrote: post #3

I don't really see the point in using Python syntax and then throwing in a handful of random differences that don't have anything to do with the domain you're working in. Syntax level support for vector operations or for shader interopability I would get. Making for loops follow some randomly different syntax, I don't see the point of that.

I welcome languages that take the idea of indentation as part of the language. I don't see that as belonging to Python, and I don't believe this language aims to be Python-compatible as opposed to inspired.

Re: The Lobster Programming Language

#13

Post by baldfat »

I use Haxe which is a

Haxe is an open source toolkit based on a modern, high level, strictly typed programming language, a cross-compiler, a complete cross-platform standard library and ways to access each platform's native capabilities.

what would be the benefit for using Lobster since I can work directly with each OS with a great scripting language built in?

https://haxe.org

Re: The Lobster Programming Language

#14

Post by Aardappel »

Hi, author of the language here.

Not a great time for HN exposure, as I just added a lot of new functionality, but none of that is documented yet :) But hey, all publicity is good publicity?

For those interested, some recent things that have been happening:

- Compile time reference counting. This does an analysis similar to the Rust borrow checker to infer lifetimes, but unlike Rust doesn't make the programmer jump through hoops.

- "Inline" structs: structs are allocated in their parent, and come at zero overhead compared to individual variables, which is particularly useful for Lobster's heavy use of 2d & 3d vector types.

- Multi-threading that uses separate memory spaces, meaning individual threads can run at max speed with no GIL overhead etc.

- A WebAssembly backend is being worked on.

- A lot of optimization work to make the language run faster.

For reference, it has been on HN before, as early as 2013 (https://news.ycombinator.com/item?id=5904430), but it has changed a TON since then (e.g. it was a dynamically typed language, now it is statically typed, with flow sensitive type inference).

Re: The Lobster Programming Language

#15

Post by kodablah »

c3534l wrote: post #3

I don't really see the point in using Python syntax and then throwing in a handful of random differences that don't have anything to do with the domain you're working in. Syntax level support for vector operations or for shader interopability I would get. Making for loops follow some randomly different syntax, I don't see the point of that.

> I don't really see the point in using Python syntax and then throwing in a handful of random differences that don't have anything to do with the domain you're working in

I don't think it's using Python syntax, I think it and Python share some similarities. Thinking about it in Python terms is probably why the changes appear random/different/useless. But in general not being constrained by Python or another language has value.

Re: The Lobster Programming Language

#16

Post by calebwin »

Aardappel wrote: post #14

Hi, author of the language here. Not a great time for HN exposure, as I just added a lot of new functionality, but none of that is documented yet :) But hey, all publicity is good publicity? For those interested, some recent things that have been happening: - Compile time reference counting. This does an analysis similar to the Rust borrow checker to infer lifetimes, but unlike Rust doesn't make the programmer jump t…

Would you mind elaborating on the "compile time reference counting"? Is this new? How does it handle cycles?

Re: The Lobster Programming Language

#17

Post by steveklabnik »

calebwin wrote: post #16
Aardappel wrote: post #14

Hi, author of the language here. Not a great time for HN exposure, as I just added a lot of new functionality, but none of that is documented yet :) But hey, all publicity is good publicity? For those interested, some recent things that have been happening: - Compile time reference counting. This does an analysis similar to the Rust borrow checker to infer lifetimes, but unlike Rust doesn't make the programmer jump t…

Would you mind elaborating on the "compile time reference counting"? Is this new? How does it handle cycles?

A comparison to Swift's ARC would also be of interest :)

Re: The Lobster Programming Language

#19

Post by Aardappel »

calebwin wrote: post #16
Aardappel wrote: post #14

Hi, author of the language here. Not a great time for HN exposure, as I just added a lot of new functionality, but none of that is documented yet :) But hey, all publicity is good publicity? For those interested, some recent things that have been happening: - Compile time reference counting. This does an analysis similar to the Rust borrow checker to infer lifetimes, but unlike Rust doesn't make the programmer jump t…

Would you mind elaborating on the "compile time reference counting"? Is this new? How does it handle cycles?

It is so new I haven't even documented it yet.. hence why I said the timing for this HN post isn't great.

So imagine the current implementation does a lifetime analysis somewhat similar to Rust, but then where Rust would error out, this implementation simply inserts a runtime refc increase. This gets rid of most runtime refc overhead without the programmer needing to be clever about it.

Then, I intend to add an optional type annotation that gets you the Rust behavior, for those cases where you want maximum control. I don't think its the right default though.

The algorithm is more lenient than Rust, since I don't have any shared memory concurrency for example.

I intend to write up more thorough details about the algorithm, but again, haven't gotten to it.

It does not handle cycles. If you create cycles that you do not manually break, you'll get a cycle report at program exit that prints the kind of values that weren't reclaimed. You're then expected to fix your code accordingly :)

Re: The Lobster Programming Language

#20

Post by Aardappel »

steveklabnik wrote: post #17
calebwin wrote: post #16

Earlier quoted context omitted.

Would you mind elaborating on the "compile time reference counting"? Is this new? How does it handle cycles?

A comparison to Swift's ARC would also be of interest :)

Yup, I will write up the algorithm some time soon.

I've seen Swift's intentions to add lifetime analysis to ARC, but from what I could see it is much more complicated in Swift, requires annotations, and with significant runtime overhead remaining.

Post reply on HN