You forgot that Spider embraces JS prototypes instead of just adding classes, ES6 target, explicit global scope usage, string interpolation, splats, `for-in` and `for-of`, list comprehensions, existential operator, ranges, and much more.
Sorry, I edited the last list entry to "everything Coffeescript has" was "syntax for lambdas" before. He is correct, all the features CoffeeScript has are pretty much essential and are in fact in this language, so I edited it to reflect that.
Please don't take my comment as dismissive of your work. I think it's really cool and the list of language features is quite impressive. I only disagree with the dynamic typing statement. Both TypeScript and AtScript are optionally/gradually typed which means your code can be as dynamically typed as you want it to be so you still retain the benefits of dynamic types. For some the backwards compatibility might be an issue but I personally like the fact that any JavaScript code is automatically valid TypeScript code that I can easily migrate to use more and more TypeScript features.
It wouldn't be if it were a keyword! More seriously, there's plenty of precedent for using `fn` and people get by just fine. (I don't think `func` is a bad choice either, my preference for `fn` was just a completely irrelevant aside.)
If it's any consolation, I think spider uses the most sane syntax out of any compiles-to-JS language I've played with so far. And that's coming from an arachnophobe :)
Maybe because I've written a decent amount of C++ I'm more acclimatized to the "::" syntax..
Definitely not the focus! The extends/super keywords are just "shortcuts" to normal prototypal inheritance. I just thought that the time machine example was pretty cool :)
All CoffeeScript's `class` stuff does is set up the prototype chain for the exact way that every JS dev under the sun does their manual prototype stuff.
AFAICT you're doing the same thing you're just making it look more function-y. Not that I hate that I just think it's an incredibly minor semantic difference, and I probably slightly prefer the outright 'call it a class' approach of CoffeeScript as it feels more like calling a spade a spade.
> However, ambiguous syntax is a huge problem of CoffeeScript.
Actually this is also a matter of personal opinion. As the author himself notes in the conclusion:
"The problems described here might not apply to you if you come from a different background. I come from Python, C# and C++. But if you come from Ruby or Perl, you might think these are not problems but actually cool features."
Personally I don't mind, but at least I can agree that Coffee syntax is ambiguous and can be bothersome sometimes.
Yes, CoffeeScript syntax is often ambiguous, but you learn a few simple rules [1] and ignore darker corners.
And I think slightly ambiguous transpiler is okay when the resulting language is not ambiguous. You can always check the output (which is very readable).
[1]: For example, "[t]he implicit call wraps forward to the end of the line…"
Isn't that a huge problem to solve though? I don't think i've seen a consistent model for this that suppots both Browser and Server(Node). Node is simple, but Browser has a lot of possible implementations, and a lot of preferences from userspace on how it should technically be implemented.
Ie, i have a strong dislike for how RequireJS handles this. I much prefer simply embedding with Browserify and the like.
This is a huge issue, and I'm still thinking about it. That's why I didn't add native require support yet. I'm hoping that the community would come up with a good idea.
Take a look at http://spiderlang.org/ :)