81–90 of 171 posts
Earlier quoted context omitted.
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?
That I've noticed: Twice on that page, once in the readme, again in dev/readme and lobster/readme.
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…
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…
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…
Is there a list somewhere of games written in Lobster?
Is the first example's last line: var i = find [ 1, 2, 3 ]: _ > r the same as?: var i = find ([ 1, 2, 3 ]) a: a > r i.e. argument parantheses are optional for one argument; and _ is an implicit argument for a block. Would multiple functions arguments be done just with parentheses, like this?: var i = find [ 1, 2, 3 ] (: _ > r), (: _ Seems like the syntactic generality of lisp or haskell, with the predictability of pe…
Multiple function arguments require a keyword in the caller, much like "else" introduces the second function argument in an if-then-else. So if "find" would take two functions, one for even and one for odd list elements, it would look like: "var i = find_even_odd [ 1, 2, 3 ]: _ > r odd: _ > r"
There are no features that prevent it from "approaching" C's speed, merely a question of implementation work. The language started out as very high level, so code generation needs to be improved to not do as many things at runtime as it currently does. The language semantics are totally able to be within 1.5x of C.
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…
Very personal opinion and matter of taste: Many lambda syntaxes are a bit weird. map(my_array)element:element*2 //lobster my_array.map{|element|element*2} //ruby Arrays.stream(my_array).map(element -> element*2).collect(something list something) //java? Lobster feels a bit unbalanced. Ruby has "pipes" which are a bit confusing substitute parentheses. Java has the cool arrow syntax but otherwise it feels very glued on…
Your Lobster version has a stray comma, it is: map(my_array) element: element * 2 Note how if you write this example with multiple statements instead of "elements * 2", suddenly the Lobster syntax looks a lot more consistent, and the Ruby example doesn't look that great as it looks completely different from the built-in for loop.
That said, the Ruby syntax can be a bit bulky. Your syntax feels pretty clean TBH.
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…
Is the first example's last line: var i = find [ 1, 2, 3 ]: _ > r the same as?: var i = find ([ 1, 2, 3 ]) a: a > r i.e. argument parantheses are optional for one argument; and _ is an implicit argument for a block. Would multiple functions arguments be done just with parentheses, like this?: var i = find [ 1, 2, 3 ] (: _ > r), (: _ Seems like the syntactic generality of lisp or haskell, with the predictability of pe…
Yes, those are equivalent. Multiple function arguments require a keyword in the caller, much like "else" introduces the second function argument in an if-then-else. So if "find" would take two functions, one for even and one for odd list elements, it would look like: "var i = find_even_odd [ 1, 2, 3 ]: _ > r odd: _ > r" There are no features that prevent it from "approaching" C's speed, merely a question of implement…
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 stage it's best to select for developers interested/capable enough to handle it!
EDIT if : is used for both blocks and code structure, could everything be one-line (or is \n significant?) Not great style, but helps in understanding the syntax. Maybe returns and vars need their own lines?
def find(xs, fun): for(xs) x, i: if fun(x): return i return -1
var r = 2 var i = find [ 1, 2, 3 ]: _ > r