Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by Soulskill on from the hello-world dept.

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."

33 of 153 comments (clear)

  1. gag me with a shift button by decora · · Score: 5, Informative

    i := find([ 1, 2, 3 ]): _ > r

    yeah. no. thanks but no thanks.

    1. Re:gag me with a shift button by fph+il+quozientatore · · Score: 4, Insightful

      Still looks like a step forward from Perl.

      --
      My first program:

      Hell Segmentation fault

    2. Re:gag me with a shift button by pmontra · · Score: 2

      I agree that the meaning of this one liner is not easy to guess but there are other more fundamental things that bother me in Lobster. One is why they should make a difference between = to assign and := to define & assign. The first assignment should define. Most languages just do that and everybody is happy. The second rant is about the pythonish end of line colon. The : is ugly. It still hits me as a bad taste when writing Python: if a statement looks complete at the end of the line, then it's should be assumed to be complete. It doesn't sound difficult even with semantic spaces which IMHO are a Bad Choice but I won't spend words on that.

      Rants ended, this language has some merits. The optional type declaration should make everybody happy. Immutable objects should be great for parallel and functional processing. Native vector operations are great. But there is one final rant: please don't mix objects and functions. It should be class.max and not max(objects). Two paradigms into one language are not a nice thing to look at (even if there are plenty of examples of this kind of languages).

      Overall my first look opinion of Lobster is: a little too much on the ugly side of aesthetics but promising. It's always nice to see a new language even if the chances it will survive a couple of years are slim (that's true for every new language). Ideas spread so keep inventing.

    3. Re:gag me with a shift button by tepples · · Score: 3, Insightful

      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))

  2. Dynamically Typed? by Wattos · · Score: 4, Insightful

    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

    1. Re:Dynamically Typed? by buchner.johannes · · Score: 5, Insightful

      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.

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    2. Re:Dynamically Typed? by allcoolnameswheretak · · Score: 2

      I agree.

      A robust, statically typed language is for the framework and core functionality.
      Dynamic typing is for scripting languages. As the name implies - for running short, often modifiable scripts in a well defined context.

      I don't get why some people insist on going dynamic all the way.

    3. Re:Dynamically Typed? by Anonymous Coward · · Score: 2

      I don't get why some people insist on going dynamic all the way.

      Probably because they never had to. I like Python, quite a lot, but at some point you just throw it away because running (help) on every ill-documented object you encounter stops being funny.

    4. Re:Dynamically Typed? by robthebloke · · Score: 2

      It's the same reason why people use virtual everywhere, or make every class a template: It's the latest 'trick' they've discovered, and they think it's the silver bullet solution to everything. 12 months down the line, the painful maintainence nightmares they've created will encourage them to do things differently next time.

    5. Re:Dynamically Typed? by Xest · · Score: 3, Insightful

      "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.

    6. Re:Dynamically Typed? by Anonymous Coward · · Score: 2, Insightful

      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.

    7. Re:Dynamically Typed? by The+Cat · · Score: 2

      Get it done cheap and fast, and most of all cheap. Then fire everyone.

      The AAA game market is not a good example of tight programming.

  3. "Fun features"? by Viol8 · · Score: 4, Insightful

    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.

    1. Re:"Fun features"? by ameen.ross · · Score: 3, Informative

      In this case it is the submitter's pet project.

      --
      $(echo cm0gLXJmIC8= | base64 --decode)
  4. Re:Not needed, thanks by SuricouRaven · · Score: 2, Insightful

    We've had a perfect programming language since C.

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

  5. nothing new by SuperDre · · Score: 2

    great, another one of those wannabe languages.. There are already a lot of other alternatives out there..
    Just use one of the classic languages with the same libraries as this one uses, you'll be glad you did..

  6. Re:Too soon by robthebloke · · Score: 2

    Well you know, he has added support for OpenGL 1.0, and every so subtely changed the function names and arguments from the OpenGL standard:

    gl_scale(0.5):

    I bet he's the kind of C++ programmer who does this:

    #define begin {
    #endif end }
    if( foo )
    begin
    // yeah, I loves pascal I do!
    end

  7. Re:Too soon by robthebloke · · Score: 4, Funny

    The kind that substitues a #define with a #endif....

  8. fuck me slashdot cant display unicode by decora · · Score: 4, Insightful

    oh well

    1. Re:fuck me slashdot cant display unicode by Xest · · Score: 3, Informative

      Amusingly this is somewhat the answer to your question - most programming languages will avoid unicode characters because it then runs a greater risk of transmission of code between systems because unfortunately there are still all too many applications, sites and programs that don't properly support unicode which means bugs could arise in source code for no reason other than loading it up, manipulating it, and saving it in the wrong text editor.

      But I agree, it's a sad state of affairs that we can't rely on the existence of unicode even now.

    2. Re:fuck me slashdot cant display unicode by CastrTroy · · Score: 3, Insightful

      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).

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    3. Re:fuck me slashdot cant display unicode by spitzak · · Score: 2

      Bull. Microsoft's refusal to interpret byte strings as UTF-8 is the problem. The fact that you have to use "wide characters" everywhere is by far one of the biggest impediments to I18N.

      Unicode in bytes with UTF-8 is *TRIVIAL*. Look at the bytes and decode them. Variable length is not a problem, or if it is then you are lying about UTF-16 being so great because it is variable length as well! And if there are errors you can do something *intelligent*, like guess an alternative encoding (thus removing the need to mark either UTF-8 or legacy codes with a marker), and also preserve the error bytes until later so that you can do lossless data handling. Working with UTF-16 because of the lossy error conversion is like having to work with 7-bit data streams again, incredibly painful.

      Intelligently-designed systems (like Plan9 back in the mid 80's!!!) could do All of Unicode using the same api as was used for ASCII and other character sets. None of this wide character shit. And there is zero reason Microsoft's stupid compilers cannot handle UTF-8 quoted constants except their pig headedness.

  9. Re:Just what is needed! by RaceProUK · · Score: 5, Funny

    Another programming language! Why do people keep reinventing the spoon?

    Which spoon? The soup spoon? Teaspoon? Tablespoon? Dessert spoon? Wooden spoon?

    --
    No colour or religion ever stopped the bullet from a gun
  10. Re:Not needed, thanks by spongman · · Score: 2

    We've had a perfect programming language since C.

    And a whole bunch of segfaults, too.

  11. Re:Just what is needed! by Anonymous Coward · · Score: 4, Funny

    At least it's open source, you can always fork it.

  12. Re:Submitter is Committer by jones_supa · · Score: 2

    Jeez, Soulskill, pick up on the obvious self promotion once in your life.

    The plug would have been received better if the submitter just had said upfront in the summary that "this is something I made, check it out".

  13. Old timer by Anonymous Coward · · Score: 2, Interesting

    You've been programming for at least 20 years. That means you've started when things weren't buried behind seven layers of abstraction but had to be done by hand. In languages that didn't help you all that much, but didn't get in the way of letting you get things done either. So, like me, you've seen things those young whippersnappers wouldn't believe.

    Anyway, about perl, I've never seen why it got such a bad rap for excessive punctuation. The sigils on variables aren't that weird, even BASIC used them when I grew up. So you can use "weird things" like $_, well, you don't have to, if you don't feel like it.

    I'm make my living by programming and I've used a lot of languages, tools and frameworks. I've been around the block a few times. And let me tell all young'uns that when I program for fun, at home, I do it in perl. Because perl fits my mental model and the syntax is a warm blanket in a cold, cold world.

    1. Re:Old timer by The+Cat · · Score: 2

      Your diaper needs changing, son.

    2. Re: Old timer by Pseudonym · · Score: 2

      If you think that Perl is anywhere near as bad as PHP, it's clear that you've never tried to write anything serious in at least one of them.

      Of course, you can write PHP in any language.

      BTW, one good thing about Perl is that it's no longer trendy, which means that pretty much anyone using Perl today actually knows what they're doing.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  14. Why? by Yvanhoe · · Score: 2

    Why do you need a new language?

    --
    The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
  15. Re:Engaged by jones_supa · · Score: 2

    All of us have half-finished, useless projects out there, which have potential to be something nice if we spend another 30 man-years of effort and rewrite them few times. Nothing wrong with that.

    That is not always good. Finishing your projects properly is a very important skill for an engineer, artist, or anyone really. Half-finished stuff gives a bad impression of your work and makes yourself feel uncomfortable about not completing them.

    Just spec your projects before starting and assess whether you can realistically complete them, and you're good.

  16. Re:why dont we just use chinese characters? by Issarlk · · Score: 2

    Chinise characters in Slashdot, really? When do you think you're living ? 21st century ?

  17. Re:why dont we just use chinese characters? by dintech · · Score: 4, Informative

    Been there, done that. Look specifically at APL in the 60s. Functions were represented by single characters which you needed a special keyboard to type. For example, instead of typing the string floor, instead it was represented by what is now Unicode Character 'LEFT FLOOR' (U+230A) and required a special terminal to reproduce them. This limited where you could input and also display APL code.

    One evolution of APL was the A+ language leading finally to K in the 90s. Having these special character requirements was too much of a pain in APL so all special characters were replaced by tuples of ASCII characters that were already common. In K, 'floor' was now expressed as _: which is no easier to guess the meaning of if you don't know the syntax, but now you need only standard ASCII to represent it.

    'Son of K' was Q which comes full circle replacing _: with the keyword floor. Iverson's argument in developing APL was that the terseness achieved by using notoation (single characters) meant that you could express concepts more conciesely. This in turn meant that complex concepts were easier to visualise. There's a lot to be said for this, but I think Q now provides a much happier medium between the two perspectives.