I agree that is indeed very generous! I am not sure I need it though, as I am fine having the main lobster page be a subpage of my personal wiki for the moment. That said, if it gets popular, it might be useful. Wanna hang on to it for the moment? Or email me about it - my username at gmail
Wouter van Oortmerssen is someone anyone interested in programming languages should be aware of - he's developed a ridiculous number of languages ranging from the very useful to bizarre and novel experimental.
I've been a fan ever since I was programming AmigaE, and it was the first and only development tool I've spent money on.
Dude, it took me like 2 stackoverflow questions to get that working in pygame! (sadly not for a game, just a 3D visualiser for helping me debug my PhD code.)
This language is even more awesome than I thought :)
At first glance it seems like an amazing language. Very few basic building blocks, and yet it manages to capture a good deal of the advanced features of modern languages. Nice, parsimonious syntax too. I especially like the Rubyesque way blocks are passed to functions.
Couple of things I imagine might bother me:
* Lack of upwards funargs. The reason stated is performance. I realise that it's complicated to implement, but it might be possible to start out with cheap blocks and promote them later to full closures if necessary.
* Reference cycles as an error. It's pretty easy to create these in legit circumstances. Maybe something like Python's auxiliary GC could be useful here.
Thanks!
- considering adding "full" closures at some point, so far haven't felt the need. We'll see how unbearable this gets eventually :)
- it does have a GC, which needs to be manually invoked. In games, that means you can decide to run it only on level start/end, etc
The sound system appears extremely primitive. I also don't seen anything that makes game programming particularly "easy" over just using regular, ol' graphics and sound APIs in a general purpose language.
That is such an incredibly miniscule bit of code that it seems ludicrous to pigeonhole yourself into a DSL just for that, especially considering that SDL does that for you, too.
Is it a thought experiment or something that author suggests people use for real-world commercial projects? It would be nice to see some sort of feature comparison table (vs Lua, vs JS etc.).
I tried to find a way to store a function in an object to call later, and after fighting the syntax I hit a bus error. I guess that is only possible with full closures.
I was trying to have a vector of behaviors for my sprites, which would hold arbitrary functions to call when updating the sprite. I don't need to capture any variables, so I don't actually need a closure. But the scope in which the anonymous function was initially created is long gone, so that's probably the issue.
At first glance I love this syntax. I'll have to pull out some of my hypothetical syntax notes to see if any holes I came up with for my language attempts apply here, but I very much like it.
Using high-level function constructs for main language flow control features seems to be in vogue. Rust does it too. I liked it when I learned Scheme and have been wanting it to be more main stream since then. That's probably why I like Ruby, since Ruby's blocks are close for many uses.
I find that one can do object-oriented things, but constructors are a bit of a catch.
struct A : [a, defaulted]
struct B : A [b]
//You can do it this way,
//but each subclass has to init every field (brittle)
function MakeA(a): [a, 99] : A
function MakeB(a,b): [a, 99, b] : B
//Or use the super constructor syntax
//but this uses a copy and is less efficient
function MakeA(a): [a, 99] : A
function MakeB(a,b): [super MakeA(a), b] : B
//Or something in between
function InitA(me::A, theA): a = theA; defaulted = 99; me
function MakeA(a): new := [0,0]; new.InitA(a)
function InitB(me::B, theA, theB): me.InitA(theA); b = theB; me
function MakeB(a,b): new := [0,0,0]; new.InitB(a,b)
I'll keep playing with it and see what else I discover. I haven't gotten far enough to use coroutines, multi-method, or to make my own control structures yet.
the second option is the intended one, yes. I'd only switch that out to first one if you ever found that allocating objects is the bottleneck in your code, which it shouldn't be.
It was like inception going through the superclasses trying to get at some explanation of what a bean is. I decided I don't want to know bad enough when I was 5 levels deep.
