4 ms·
Welcome to the fray. I kind of like that there are so many JavaScript wrapper languages turning up. It allows for cross-pollination of ideas and hopefully in
by Lerc 12y ago
Welcome to the fray. I kind of like that there are so many JavaScript wrapper languages turning up. It allows for cross-pollination of ideas and hopefully in the long term those that work the best for people in practice will establish themselves a niche.
That said, I don't think this is the one for me.
I think I would lean towards halfway between Spider and JavaScript
I'd prefer to keep some bits from Javascript
* function instead of func.
* bracketed if and while conditions.
* no list comprehensions (but I could just choose to ignore).
* no ranges (unless only in case conditions)
* not sure about # for int div.
From spider I'd keep
* Default parameters
* splats
* ?
* ??
* * *
* logical operators
* for loops (but bracketed)
* extends and super.
and I'd add sugar.js http://sugarjs.com/ http://sugarjs.com/ as standard
- sanderjd 12y agoI'm always curious why people don't like list comprehensions - care to expand on that? I'm also the opposite of you on `function` vs. `func` - I think `fn` would have been even better! The verbosity of `function` is one of my least favorite things about javascript. It seems superficial, but I think it makes it noticeably more awkward to program more functionally.
- alongub 12y agofn is a often used as a variable name
- sanderjd 12y agoIt 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.)
- warble 12y agoI never mind verbosity in a programming language. Making things succinct at the expense of readability is a poor choice in my mind. If you don't like to type, any decent IDE can fix that for you.
- ptx 12y agoBut list comprehensions make things both more succinct and more readable. Compare: "Give me one scoop of ice cream of each kind that is chocolate-flavored." ...to: "I would now like you to prepare for looking over the ice cream flavors, and also to prepare a new list which I will later fill in. Consider the first ice cream flavor. Is is chocolate? If that is the case, I would like ... once that is done, consider the next flavor ... now add this flavor to the end of the list which we prepared earlier ... consider the next flavor..."
- sanderjd 12y agoI didn't complain about the amount of typing. Programming involves so little typing in general that bringing it up is always a red herring. I often don't mind verbosity in a programming language, but not never. The distinction is basically verbosity that makes common patterns noisy to read. The `function` keyword is that sort of verbosity in javascript. I think explicit returns are also that sort of verbosity in javascript. The language lends itself to using lots of anonymous functions, but because of the `function` keyword and implicit return, anonymous functions are very noisy. It doesn't help readability, it just results in long lines or stacks of lines to express simple concepts. I find this type of syntax discussion pretty superficial, but, for better or worse, syntax has a big impact on how programs are written in a language.
- Lerc 12y agoI've used list comprehensions in Haxe, but not much more than in tests to try them out. I haven't yet had an opportunity to use them as best solution for the job. It's not that I'm against either func or comprehensions in principle, it's more that they are a departure from JavaScript. My preference would be for a JavaScript[FIXED] than a complete style change. For something with "all the features" that compiles to JavaScript I prefer Haxe, but for something that has squishy dynamic and prototypey feel of JavaScript (which spider seems to be going for) I think I would want it to resemble JavaScript a bit more, if for no other reason to pretend that they got it right the first time.