Lobster, a New Game Programming Language, Now Available As Open Source

Aardappel writes "Lobster is a new programming language targeting game programming specifically, building on top of OpenGL, SDL 2 and FreeType. The language looks superficially similar to Python, but is its own blend of fun features. It's open source (ZLIB license) and available on GitHub."

Comments

Dynamically Typed?

[Wattos]

Dynamically Typed with Optional Typing

Thanks, but no thanks, I prefer to stay with statically types languages. I know that the "kewl" kids love dynamically types languages, but it becomes a horror for maintenance. Ill be sticking with UDK in the meantime

Re:Dynamically Typed?

[buchner.johannes]

It really depends what you are doing. For many projects, scripting with some OOP is good enough (all those web projects, RoR, etc.). Having short code in an expressive language leads to less bugs.

Static typing is extremely useful because it catches all mistakes of a certain class. However, other mistakes you still have to unit test for. So if you are unit&integration testing well, the benefit of static typing is small, and you are capturing more mistakes than static typing would.

For projects where you have contract-like, long-term stable interfaces/APIs, yes, use static typing. But don't pretend it's for every project.

Re:Dynamically Typed?

[Xest]

"It really depends what you are doing. For many projects, scripting with some OOP is good enough (all those web projects, RoR, etc.). Having short code in an expressive language leads to less bugs."

Are you sure you're not conflating two different things here? It sounds like you're saying some languages are better for short, more expressive code, but that's not the same as static vs. dynamic typing.

The only increase in code from static typing is explicit conversion, but I do not see how this extra code can increase bugs, on the contrary, it's what often decreases bugs in applications written with static typing because the developer has to explicitly declare and perform the possible conversions. In contrast, with a dynamically typed language you're relying on the interpreter to guess, which is much more error prone.

If you perform a conversion in a statically typed language and it's wrong, you know the second you try and execute, but in a dynamically typed language you may not know there's a problem until you hit some edge case input, which is more likely to get out into production due to the subtle nature of it.

Do you have any examples of the classes of problem you believe dynamic typing avoids but static typing doesn't? You make the assertion that if you unit and integration test a dynamically typed language you capture more mistakes than you would with a statically typed language. I don't think that's ever the case, because static type makes capture of certain errors explicit in the implementation, the faults are unavoidable when you attempt execution, whilst dynamic typing relies on you stumbling across the error during execution, which means to capture it with unit tests means it's only as good as your unit tests which will rarely be as good as explicit and inherent capture of errors.

I agree that dynamic code has it's place - where you want to make quick changes, dynamic changes and want to see change instantly or where you don't care about code quality because you're just doing prototyping or proof of concept. But I think dynamic code is always inherently more error prone, I think it's a fallacy to pretend otherwise and I've never seen any evidence to suggest dynamically typed code is less error prone than statically typed code so I'd be intrigued to see it because I don't see how inherent ability to capture a certain class of errors coupled with tools for finding every other class of errors can ever be worse than no inherent ability to capture that class of errors with the same tools to find the other classes of errors. It just doesn't make sense.

Re:Dynamically Typed?

[Anonymous Coward]

How many games have you written, exactly? I've worked on AAA games from 1995 to today, and most of the industry is using dynamically-typed languages for scripting, and has been since the days of QuakeC. The iteration time is so much faster because the compiler doesn't have to work all that shit out up front. Iteration time is king in game production. Runtime is important too but we all know (right?) that only 10% of your code is reponsible for 90% of your runtime. The other 90% of your code can bloat by 2-3x if you get that 10% right. Premature optimization is still the root of all evil, and avoiding languages with fast developer iteration times because they are slower at runtime is a classic example of this. Plus, remember, your processor time is not going to ALU ops. ALU ops are free except in very specific cases (that 10%). For the other 90% all your time is going to memory waits. You might be waiting for dozens of cycles so what difference is it if you run 1 ALU op or 12 ALU ops in parallel with that? Interpreted code is free if your memory access patterns are bad enough. And they are, believe me.

"Fun features"?

[Viol8]

Languages don't have "fun" features, they either have useful features or bloat.

Looks like yet another me-too language that's someones pet project that will be forgotten about this time tommorow.

Re:gag me with a shift button

[fph il quozientatore]

Still looks like a step forward from Perl.

Re:Not needed, thanks

[SuricouRaven]

We've had a perfect programming language since C.

That's why everything since has copied the syntax and half the operators.

fuck me slashdot cant display unicode

[decora]

oh well

Re:fuck me slashdot cant display unicode

[CastrTroy]

This is one of my favourite things about .Net. All strings are unicode (utf-16) by default. You don't have to do any fancy trickery to get the language to interpret your string as UTF, and all the functions (assuming no bugs) work properly for international characters. In most other languages, you have to remember to precede the string with some character to signify that it's unicode, and the strange things start happening when you mix unicode and non-unicode strings, and have the functions don't work properly with unicode strings to begin with. Same thing goes with base-10 decimal numbers. It's a native type. You don't have to import some library and a= b.add(c) every time you want to add a couple numbers (gets really messy with more complex math).

Re:gag me with a shift button

[tepples]

It also ends lines at the new line rather than at a ;, which means that you're in a position where you can end up with long lines at times, where normally, you would just hit enter and continue on the next line.

Python uses newline as a statement delimiter only if all bracketing constructions (...) [...] {...} are closed. The arguments of any function call, for instance, can be split over multiple lines, as can the elements of a list or dictionary or a long expression. And back when print was a statement (Python 2) as opposed to a function (Python 3), it was my common practice to do something like this:

print ("%s: not raising price because %s"
        % (sku, reason))