Live data from Hacker News

The Lobster Programming Language

strlen.com

141–150 of 171 posts

Re: The Lobster Programming Language

#141
post #95

I really like the inclusion of basic graphics routines. Not a lot of languages include these out of the box and it's something I've really missed since I first started toying with programming in QBasic.

It's kind of surprising to me that the language is directly tied into OpenGL given that it's a cutting-edge experimental new language and that seems more the domain of Vulkan.

Re: The Lobster Programming Language

#142
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.

> unlike Python that only has built-in control structures, here any function can look like if/for/while if it takes a lambda body

That's absolutely fantastic. I've had to do a lot more Python programming for work, and I've been thoroughly disappointed by Python's lack of support for custom blocks/structures like that (contrast with Ruby or Elixir, where any function can take a do ... end, or with Tcl where "blocks" are just strings).

Re: The Lobster Programming Language

#143
post #95

I really like the inclusion of basic graphics routines. Not a lot of languages include these out of the box and it's something I've really missed since I first started toying with programming in QBasic.

It's kind of surprising to me that the language is directly tied into OpenGL given that it's a cutting-edge experimental new language and that seems more the domain of Vulkan.

It's not tied to, it is implemented in it. I could swap out the rendering code for Vulkan, an no Lobster users would need to change anything.

Also, have you actually programmed in Vulkan? Even a simple primitive can be hundreds of lines of setup code. In Lobster they're often a single line. A direct mapping would not make sense.

Re: The Lobster Programming Language

#144

Earlier quoted context omitted.

Are the coroutines copyable? This is useful if you want to use time-travel netcode (like ggpo) and coroutines attached to game objects in the same game.

I'm afraid they currently aren't, but there's no reason this couldn't be implemented. There's a "copy" function for reference types that currently errors on co-routines.

That sounds great :)

I found it a bit strange that the coroutines run until the first yield at the time they are created, but otherwise I quite like the system.

Re: The Lobster Programming Language

#145

Earlier quoted context omitted.

Heyy @Aardappel Interesting project! I wanted to share your language with a game programmer I know but the links to documentation from your homepage look broken. Essentially https://htmlpreview.github.io/ is dysfunctional. Try accessing the sample links in that project's Github page.

Weird, those links work fine for me. I guess I'll have to change them, though not sure what to.. annoying github doesn't have a way to view markdown pages. I guess for now, to read the docs online you could read the raw markdown here: https://github.com/aardappel/lobster/tree/master/lobster/doc... Better yet, just download the repo and read the html files in docs/

Now all docs served from http://aardappel.github.io/lobster/lobster/docs/README_FIRST... which works much better

Re: The Lobster Programming Language

#146

Earlier quoted context omitted.

Fantastic, thanks. The many uses of : syntax are intriguing - lambdas, functions, control, python-style structure, data, globals. I reckon you've established it works in all cases, but I'm not yet familiar enough to see that for myself. For initial adoption, I wonder if more regular sample code, without the special-case abbreviations, might be more effective? (Followed by the short version.) OTOH, maybe at this early…

Yes, ":" appears a bit overloaded, though many of those cases are actually one and the same. What would be more regular sample code? Do you mean just writing "find([ 1, 2, 3 ]) x: x > r" with explicit () and explicit variables? I agree that is easier to read, though the extreme terseness is also a feature.. Yes, everything can be one line, but in this case it would look a bit ugly: def find(xs, fun): (for(xs) x, i: i…

> Do you mean just writing "find([ 1, 2, 3 ]) x: x > r" with explicit () and explicit variables? I agree that is easier to read, though the extreme terseness is also a feature..

Yes, amd yes it depends on the purpose. For learning, it can be impossible to parse; redundancy helps distinguish parts and provides a check you got it right.

OTOH for showcasing features, IMHO, the generality of : is a more impressive feature to demo.

Anyway, it's certainly intriguing! And maybe that's the true purpose of showcase code...

Re: The Lobster Programming Language

#147
post #86

Earlier quoted context omitted.

I have never understood why people create entire programming language when just creating a nice C++ library would been more than sufficient, desirable, integratable and adaptable. You can always export bindings for any target language and users would be saved from learning yet another beast that would be unmaintained in few years. I'm not saying never developing new language... If you have radically new thought, go a…

C++ is a complex beast and while I quite like working in it, I'm finding that the latest versions (17 and 20) are filled with features that I'm having trouble understanding. The surface for errors is also huge. I've been programming in C++ since about 2002 and I feel quite proficient in it, but, if given the option, I'll use something that is both safer/less error prone and more productive (and I say that as someone…

I'm not against creating new languages. In fact the Lobster language is something I would want (although current syntax is bit repulsive). Python with static types but without getting in the way is pure gold. The problem is that creating interpreter/compiler is one tiny little part of creating language. Much bigger task is creating vast number of libraries that every other popular languages have. Think about everything from numpy to scipy to graphics to networking to web frameworks to OS APIs... Another bigger part is creating tooling and interoperatibility - everything from debugger, refactoring, linting, IDEs, CI, docgen etc. Now put on the top of it all the reusable code that millions of people have already written spending billions of hours in existing languages.

Without large teams working for years, its very hard for a new languages to break in to general use. There are ofcourse outliers and you can get lucky - but then you have to be terribly lucky. So the end result is that 99.9% of languages just die or become hobby project for a person regardless of their features, benefits, beauty or aesthetics. Again, nothing wrong with becoming personal hobby project but if my goal was to create game engines that becomes force in the industry, I would probably not start by creating entirely new language.

I'm not experienced as much as the author, so this is my personal opinion and likely not very well informed. I writing this just because I see several people spending years in creating new languages while their goals have been something else. They dream about repeating success of Java while not realizing how rare it is. After they finish their labor of love, I wonder if they find it depressing to become just line item in the list of dead programming languages. What if they would have actually focused on their original goal instead with emphasis on adding new powerful features that integrates and plays well with existing stuff? It's sure not as sexy and respectable as being father (or mother) of new language but has much higher chance of generating desired impact.

Re: The Lobster Programming Language

#148
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.

So is it a bit like Rebol (or Red, or even Joy if we pretend RPL is not a significant difference), or is it a very different style of implementation?

Re: The Lobster Programming Language

#149

Earlier quoted context omitted.

I suggest people might pick up on that pretty quick, maybe no need to rename given some random comment. That said, maybe you want to have a gander through the various languages and see what words are used for what, and if there's a 'standard' go with that :) Cool language though. I love everything except for the name, sorry :)

Well, every time Lobster surfaces somewhere, I am always surprised how quickly people can superficially reject it because of some syntax issue, so yes, I agree, using predictable keywords where it makes no real difference matters. I've already made quite a few such changes. The name.. I think people will quickly forget about the original meaning. Think of all the languages you know, and how you associate the name wit…

> a french philosopher

If Sartre isn't already an esolang built around the concept that hell is other programmers, then someone should make it.

Re: The Lobster Programming Language

#150
post #102

Earlier quoted context omitted.

Because it is a sufficiently divisive decision that it limits the audience. The threshold before I'd consider working with a language with significant indentation for example, is huge. And for my part at least, I've yet to see an automatic formatting tool that formats how I find things most readable.

> Because it is a sufficiently divisive decision that it limits the audience. Considering Python is the 2nd or 3rd top popular language in indexes like TIOBE and job entries, and within the top-5 for over a decade, that's empirically false. It might put off some insignificant minority (that's superficial like that), but not enough people not to be hugely successful.

Given I personally is unwilling to use Python for that reason, and know other people as well, it is empirically true. We can argue over whether the number of us that refuse to use it is big enough to matter, but for my part I have no interest in the pain of dealing with that, and I have the freedom to choose it away.
Post reply on HN