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

41–50 of 171 posts

Re: The Lobster Programming Language

#41

Post by Aardappel »

kragen wrote: post #31
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…

Hi! I might be an embarrassingly gushing fanboy about everything you do, so I'm probably biased here. (I wrote the FlatBuffers Wikipedia page, for example.) Lobster is pretty inspiring (despite not being nearly as radical as, e.g., Aardappel) with its lightweight lambdas and (like most of your work) a very minimal core language. Is there a comparison of different versions of Lobster somewhere? I'd like to be able to…

Hah! Thanks a lot for the wikipedia article :)

Yes, Lobster is meant to be a much more pragmatic language, for people like myself to actually get the job of making a game done :) Other languages of mine are much more research-y. Though I will say I think the type system and lifetime analysis are pretty novel actually.

I'd like to think there's really only one Lobster, while older versions are still recoverable, they for practical purposes don't exist anymore :) Have you seen https://htmlpreview.github.io/?https://raw.githubusercontent... ? That actually contains some history.

Re: The Lobster Programming Language

#42

Post by Aardappel »

obastani wrote: post #38
Aardappel wrote: post #19

Earlier quoted context omitted.

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 optio…

Any chance you could you share some references on this kind of type inference? It sounds very interesting!

It is not an implementation of an existing paper or anything.. I am going to write it up soon, promise!

Feel free to email or msg me if you want to be notified.

Re: The Lobster Programming Language

#43

Post by hacksoi »

NikkiA wrote: post #5
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.

Also 'include'? Why would you add the single most awful part of C/C++ to a python-alike.

#include causes the preprocessor to replace it with the specified file. Why is that bad?

Re: The Lobster Programming Language

#44

Post by Aardappel »

steveklabnik wrote: post #26
Aardappel wrote: post #24

Earlier quoted context omitted.

I'm aware of that, I said "add lifetime analysis to ARC", as in, ARC is what I call regular runtime reference counting, and with lifetime analysis some of it can move to compile time.

Yep oops, sorry. Anyway, psyched to see more people experimenting with this kind of thing!

Yes, I frankly feel this design space is the future of memory management. GC, begone!

Re: The Lobster Programming Language

#45

Post by Aardappel »

Empact wrote: post #28
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…

Do you plan to accommodate multi-line lambda? Python is hamstrung on this front thanks to the white-space oriented formatting.

It already does multi-line lambdas (lambdas and built-in control structures share the same syntax), see e.g. the call to "fold" here: https://htmlpreview.github.io/?https://raw.githubusercontent...

Re: The Lobster Programming Language

#46

Post by Aardappel »

gpm wrote: post #29
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…

Btw, you have a bunch of dead links to Google+ (readme, the linked page, etc).

On http://strlen.com/lobster/ I only see a dead link to Google+ (which I'll remove, thanks!), but no other dead links?

Re: The Lobster Programming Language

#47

Post by Aardappel »

fouc wrote: post #40
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…

can you drop the need for the : at the end of the line if there's a newline? i.e. it seems like unnecessary syntax

That would make it much harder to parse in certain cases, both for the compiler and the human, given that it uses this same syntax to parse not just control structures, but also higher order functions / lambdas.

Re: The Lobster Programming Language

#48

Post by Aardappel »

dfox wrote: post #39

Major reason why many game engines used to have native core and then some kind of "scripting" language for game logic (think Unreal Engine before 3, but many engines are similar) is that then you can trivially serialize the simulation state (ie. save game) and even run the whole thing as either lock-step, forward predicted or fully distributed network game without much effort on the part of whoever is writing the "sc…

Agreed, those are nice benefits. But there are also huge downsides, in the sense that you're writing all the glue code in the wrong language :) The amount of speed of iteration you get from having your entire engine + game's structure in a friendlier language is impressive (in my experience).

Also doing savegames by just serializing the entire scripting VM may work in some cases, but can also be problematic, since you're mixing ephemeral data with gameplay state. Last U3 engine game I worked on had explicit savegame serialization :)

Re: The Lobster Programming Language

#49

Post by Aardappel »

nathanielc wrote: post #32
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…

Looks really interesting. Have you done any write ups on the type inference bits? Flow sensitive type inference looks like exactly what I need.

There's an informal description here: https://htmlpreview.github.io/?https://raw.githubusercontent...

But yes, I should really write up a more technical description some day.

Re: The Lobster Programming Language

#50

Post by sonnyblarney »

hacksoi wrote: post #43
NikkiA wrote: post #5

Earlier quoted context omitted.

Also 'include'? Why would you add the single most awful part of C/C++ to a python-alike.

#include causes the preprocessor to replace it with the specified file. Why is that bad?

Because ostensibly we've moved on from that to the concept of actual modules.

'including' stuff entails a whole host of ugly things including multiple definitions, circular dependencies etc. etc..

Most languages use some kind of module resolution, which when specified clearly is usually better. Of course sometimes they forget to define things, and leave us in a lurch ... but hey ...

Post reply on HN