12 ms·

Spider Programming Language

117 points by alongub 12y ago

izolate 12y ago
This is exciting. I've been experimenting with languages to replace JS with, and have only liked Rapydscript so far (due to an existing familiarity with Python). Syntactically, I see some inspiration in Spider from both Python and Go. As this is still in alpha stages, any chance you'll remove the semicolons? That would push the syntax into "beautiful" realm for me.
- alongub 12y ago
  This is definitely possible. Can you open an issue in GitHub?
  - vanderZwan 12y ago
    I'm sure you are well aware of this, but just to be safe: Go has more sensible semicolon insertion rules compared to JavaScript, avoiding pretty much all issues JavaScript has with it. Be sure to take a look at it!
    - alongub 12y ago
      Of course. Swift does this as well BTW.
  - izolate 12y ago
    Done and done: https://github.com/alongubkin/spider/issues/30 https://github.com/alongubkin/spider/issues/30
FreezerburnV 12y ago
The website states that Spider is still a work in progress. How complete is it at this point? Is it usable for hobby projects at this point in time?
- alongub 12y ago
  Hobby projects - definitely, but I wouldn't use it for production projects yet. Even though Spider currently has 92% test coverage, I believe Spider still needs more testing and feedback. Make sure to report any bug you encounter so I can fix it as quickly as possible!
  - FreezerburnV 12y ago
    Awesome, thanks. I'll see if I can squeeze in some time to poke around at Spider, (I'm sure you understand how hard it can be to prioritize hobby projects :) and I will definitely file any bugs I come across.
Jaecen 12y ago
This looks to be an implementation of the concepts (but not the language) proposed in http://www.walkercoderanger.com/blog/2014/04/what-coffeescript-should-have-been/ http://www.walkercoderanger.com/blog/2014/04/what-coffeescri.... Several of the terms used are exactly the same.
- alongub 12y ago
  Spider was highly inspired by this article. In the original "Introducing Spider" article I wrote, I referenced it
drewying 12y ago
Kudos to the creator. Writing something like this takes a lot of effort and it looks like they did a great job! Well done! With that said, on wider level, what's the allure of these JavaScript replacement languages? Is JavaScript syntax really that difficult for some developers to wrap their head around? I can understand something like Dart that has an underlying goal of performance, but the purposes of things like this or CoffeeScript genuinely confuse me.
- alongub 12y ago
  It's not that JavaScript syntax is difficult. It's that there are some common patterns that repeat themselves so much times. For example, safe object navigation. This code in Spider/CoffeeScript: var x = a?.b?.c?.d; compiles to something like: var x = typeof a !== "undefined" && a && a.b && a.b.c ? a.b.c.d : void 0;
  - bsimpson 12y ago
    I've been using node-jsx and jsx-loader to bring JS Harmony syntax into projects I'm working on now. The last great hurdle to make JS a language that's easy to express in is the existential operator. It sucks how often you have to manually null-check in JS. I'm mighty tempted to write a Webpack plugin to make `?` usable in vanilla JS.
  - joshuacc 12y ago
    You can also handle problems like this via libraries. For example, underscore-contrib [1] does it this way: var x = _.getPath(a, "b.c.d"); There are definitely advantages to having this pattern baked into the language, though. [1] http://documentcloud.github.io/underscore-contrib/ http://documentcloud.github.io/underscore-contrib/
- tdumitrescu 12y ago
  The main reasons I reach for Coffeescript for my personal projects are: * built-in support for comprehensions and other array/object operations * simple syntax for context binding * automatic module isolation. These eliminate a lot of boilerplate littering my JS code. At my company gig we use JS but rely heavily on Underscore to address the same pain points; I prefer to have it built into the language syntax instead. ES6 probably has enough of this built in to make me switch back eventually.
wiremine 12y ago
I'm still a bit unsure about these sorts of projects. I like the idea of improving Javascript's rough edges, but whenever I start a new project, I always seem to stick with plain old javascript. That said, Spider feels like it is heading in the right direction: - It embraces JS's prototype OOP. I've never liked how CoffeeScript tries to add traditional classes. Not sure the syntax is right, but I appreciate the goal. - It adds just enough "modern" features and syntax to feel like Javascript without requiring me to learn a whole new language. Feels like modularity is missing, though. Is there any support for "require" or "import" or something similar?
- alongub 12y ago
  I'm still unsure how to add modularity while maintaining compatibility with CommonJS, AMD, etc. I thought about adding a require statement such as: require "vm" require ( "util", "io" ) That would also support git repos, inspired by DuoJS (https://github.com/duojs/duo https://github.com/duojs/duo): require "alongubkin/phonertc"
- fizzbatter 12y ago
  > Feels like modularity is missing, though. Is there any support for "require" or "import" or something similar? I haven't personally tested it, but i imagine everything is supported, including require and import. It doesn't look like Spider does anything weird to scoping, so to use a global you simply use it with `::global(foo)`, or `use global; global(foo)` I imagine require would be `use require; require('mylib')`, and etc.
  - alongub 12y ago
    Of course, but I think he meant native modularity support, which is important IMO.
    - fizzbatter 12y ago
      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. How would you handle this issue, i wonder?
brandonhsiao 12y ago
i'm always curious, why keep brackets? if blocks can be implied by whitespace (that vi can handle for you), what do explicit brackets buy you in exchange for the time it takes to type them?
- klibertp 12y ago
  Easy copypasteability. Yeah, I don't understand why this would be an advantage either, but that's an argument I see most often.
- munificent 12y ago
  Explicit delimiters compose inside expressions much more gracefully. This is the main reason Python doesn't allow multi-line lambdas: if you have some significant indentation inside another expression, it's hard to tell how the rest of the expression following the unindent should be formatted. CoffeeScript does handle this, but I've always felt it was a murky corner of the grammar.
  - breuleux 12y ago
    You can easily allow both, though. At worst you can simply turn off significant indent inside explicit delimiters.
    - munificent 12y ago
      Sure, but then you need to implement both ways to express the same thing, and then deal with the infinite arguments it will spawn between proponents of each camp.
      - breuleux 12y ago
        Typically, what I do is just map the indent and dedent tokens directly to some suitable bracket pair, so the implementation is trivial. As for the infinite arguments, well, as a language designer, is that really your problem? I mean, that kind of stylistic argument is no different from the endless arguments about bracket placement in C-like languages, or comma placement, "a+b" versus "a + b", and so on. People quibble about the dumbest things, I say just let them.
klibertp 12y ago
> CoffeeScript (and its derivatives: LiveScript, Coco, etc) have serious issues of ambiguous code, alien syntax and scoping problems. How long will programmers think of "alien syntax" as a problem? I don't understand it at all - syntax should fit the problem domain and language semantics first and foremost, NOT expectations of programmers writing in other languages. It makes absolutely no sense - from a language design perspective - to invent a new, interesting language and then try to fit it into some "standard" syntax. In my mind this misses at least half of a point of creating a language in the first place!
- CmonDev 12y ago
  But there is no problem: "programmers writing in other languages" - they will keep using those other languages, while you will use your new language with unusual syntax. Alone. Now if you want to persuade those other developers to use it, then maybe you should meet them half-way?
  - 14113 12y ago
    You're assumming that programmers will only switch languages if they already "know it". What about other benefits to other languages, such as different paradigms, type systems or other semantic features? Surely to someone who actually writes code they're just as important as the syntax?
    - AnimalMuppet 12y ago
      > Surely to someone who actually writes code they're just as important as the syntax? They're more important. I don't switch tools just to get better syntax (unless the syntax is really horrible). I switch to get a tool that will do something different, or do the same thing better. So: Don't switch syntax just to switch syntax, and expect anybody to care. On the other hand, things that are really different but have the same syntax can be confusing. You subconsciously expect it to work the old way, and it doesn't...
- tomp 12y ago
  IMO, the bigger complaint about CoffeeScript is ambiguous syntax - the syntax tree is very sensitive to even the smallest whitespace changes.
fizzbatter 12y ago
The only thing i don't like so far, is `func` and `->` both expressing functions. I use Coffee a ton, and Golang, so oddly enough i love both syntaxes.. but i don't like multiple ways to declare a core feature like functions. Just my 2c. Fwiw, i'm going to be trying this out asap - I have high hopes for this replacing my very heavy CoffeeScript usage!
- alongub 12y ago
  I actually agree about this - two ways to do exactly the same thing is generally a bad thing when it comes to language design. But I think that a more important goal is to make the transition from Spider to JS as easy as possible.
- 14113 12y ago
  I think it's quite good - it allows a programmer to conceptually separate her "normal" functions from lambda expressions, even if they're essentially equivalent, and one is syntactic sugar for another.
- woah 12y ago
  ES6 already has =>, I think that Spider should probably stay far away from trying to replicate existing language features with different syntax
- tomp 12y ago
  Many functional languages have shortcut syntax for inline functions, e.g. in OCaml: let f = fun x y -> x + y Haskell: let f = \x y -> x + y It looks that Spider uses a similar syntax, but uses uncurried form in line with function invocation syntax.
- rld 12y ago
  It's not duplicate syntax. `func` adds a named function to the current environment, and `->` only describes an anonymous function. It's the equivalent of `function foo(...)` vs `function(...)` in JS.
  - fizzbatter 12y ago
mariusc23 12y ago
Neat! Did anyone make a grunt plugin yet? :)
- alongub 12y ago
  You are welcome to make one! :)
  - mariusc23 12y ago
    I've never built one before, but here's my first attempt: https://github.com/mariusc23/grunt-spider-script https://github.com/mariusc23/grunt-spider-script Let me know if you notice any issues!
notastartup 12y ago
I'm sorry but the syntax is absolutely gash! This is like a horrible lovechild between Python and Coffeescript gone terribly terribly wrong. If that was the selling point then its a no go from me. I know this sounds harsh but I actually thought that this was a language to create web crawlers. func TimeMachine(pilot) { this.pilot = pilot; this.go = func (noise) { ::console.log(noise); }; } func Tardis() extends TimeMachine("The Doctor") { this.go = () -> super.go("vorp vorp"); }
- alongub 12y ago
  Appreciate your opinion! About the :: syntax: http://spiderlang.org/#code-safety-global-scope-usage http://spiderlang.org/#code-safety-global-scope-usage About the extends/super syntax: http://spiderlang.org/#functions-inheritance http://spiderlang.org/#functions-inheritance
  - seabrookmx 12y ago
    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..
woah 12y ago
I'm worried by the focus on OOP in the examples. I hope that OOP is not a focus in the language. This nice and simple enough of a language that I could see JS people getting on board, and using this for real JS stuff. I'm afraid that an inordinate focus on OOP will alienate JS devs, who are already good at writing in a functional style and don't need it. The people who will appreciate the trappings of OOP are more than likely the typical classically trained programmers, who will write 300 lines of Spider on the frontend of their Python hobby project, and not touch it again.
- alongub 12y ago
  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 :)
  - nilliams 12y ago
    Yep, same as CoffeeScript. 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.
- nilliams 12y ago
  Can't agree with your implication that 'real JS stuff' won't get done and 'JS people' won't get on board due to its 'focus on OOP'. I've yet to see a large JS app written in a 'functional style'. Most large client-side apps I've come across are written in Backbone, Angular, Ember etc. which are all frameworks/libraries that embrace OOP. You shouldn't mistake JavaScript's 'prototypal' nature for it being a non-OOP language. JavaScript and OOP are a very good fit. > The people who will appreciate the trappings of OOP are more than likely the typical classically trained programmers, who will write 300 lines of Spider on the frontend of their Python hobby project, and not touch it again. If you're really dismissing __all of OOP__ to that extent I feel like you are seriously misunderstanding OOP and I highly recommend you read/watch at least: - POODR by Sandi Metz [1] - Explores OOP, SOLID principles, testing, more. The best book on OOP I've ever read. Ignore the fact the code examples are in Ruby (by that I mean, they're easy to understand). - Refactoring by Martin Fowler [2] - The definitive refactoring book... which goes hand in hand with OOP. - Boundaries (Talk) by Gary Bernhardt [4]. He talks about the 'functional core, imperative shell' pattern of software architecture that acknowledges the fact that some form of OOP/procedural/imperative programming is unavoidable. It's a great talk. Outright dismissal of OOP really has no place in modern programming. Even if you get into functional languages like Clojure you'll find they're actually embracing a lot of OOP ideas [3], even though they pretend they're not into it :) [1] http://www.poodr.com http://www.poodr.com [2] http://martinfowler.com/books/refactoring.html http://martinfowler.com/books/refactoring.html [3] http://www.youtube.com/watch?v=13cmHf_kt-Q http://www.youtube.com/watch?v=13cmHf_kt-Q [4] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries
DonGateley 12y ago
Is backward transliteration from pure JavaScript to Spider possible so that one can deal exclusively with Spider and not have to learn JS in order to deal with other people's code? If one must know both in order to be an agent in the real world then its utility is somewhat limited.
- vorg 12y ago
  > Is backward transliteration from pure JavaScript to Spider possible Yep, this is important to avoid the "Groovy" problem where Groovy is valid Java, except for lots of little cases where it isn't, e.g. == behaves differently, default member access behaves differently, etc etc. Since Java 8 lambdas, Groovy is now wildly different in its syntax.
  - DonGateley 12y ago
    'Fraid I don't understand your response. What is Groovy and what has it to do with Spider?
    - lbearl 12y ago
      Groovy is a JVM language which is dynamically typed (a la python and ruby). It never really took off, partly because you had to understand java (and the JVM) pretty well in order to do anything other than trivial scripts with it. The point being made is that if Spider wants to take off, it had best not require an intimate knowledge of javascript - and we can look to groovy to see what happens otherwise.
- ryanthejuggler 12y ago
  Interesting comment; it seems to imply that some people will learn Spider before JavaScript. Whenever I come across one of these compile-to-JS languages I take it as "this makes you more productive, as long as you've learned JS first and understand the mapping". Spider does look like it would actually be a really cool first language to learn!
deleted 12y ago
[deleted]
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 ago
  I'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 ago
    fn is a often used as a variable name
    - sanderjd 12y ago
      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.)
  - warble 12y ago
    I 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.
vinodkd 12y ago
Nice! I started on something like this a while ago: https://github.com/vinodkd/betterscript https://github.com/vinodkd/betterscript. You have a slightly larger goal - a better js with some useful syntax from other languages/efforts. Mine was just a better javascript. But: I did have a module syntax. No plug here, btw; feel free to borrow any/all syntax and kudos for getting it done:)
drawkbox 12y ago
One thing for sure is apparent in the new Javascript movement is that every framework tries to script your Javascript and not be Javascript. Nothing against experimentation and there are merits to generation to target platforms, but this is a common theme. The NBL is Javascript yet everything to support it moves away from it? Very strange, do people hate Javascript that much? Try my new scripting language, it will help you script your Javascript.
oweiler 12y ago
Additionally, loose typing can be one of JavaScript's best features if used correctly. For me, this is by far the worst feature of JavaScript.

117 points by alongub 12y ago

This is exciting. I've been experimenting with languages to replace JS with, and have only liked Rapydscript so far (due to an existing familiarity with Python). Syntactically, I see some inspiration in Spider from both Python and Go. As this is still in alpha stages, any chance you'll remove the semicolons? That would push the syntax into "beautiful" realm for me.

alongub 12y ago
This is definitely possible. Can you open an issue in GitHub?
- vanderZwan 12y ago
  I'm sure you are well aware of this, but just to be safe: Go has more sensible semicolon insertion rules compared to JavaScript, avoiding pretty much all issues JavaScript has with it. Be sure to take a look at it!
  - alongub 12y ago
    Of course. Swift does this as well BTW.
- izolate 12y ago
  Done and done: https://github.com/alongubkin/spider/issues/30 https://github.com/alongubkin/spider/issues/30

FreezerburnV 12y ago

The website states that Spider is still a work in progress. How complete is it at this point? Is it usable for hobby projects at this point in time?

alongub 12y ago
Hobby projects - definitely, but I wouldn't use it for production projects yet. Even though Spider currently has 92% test coverage, I believe Spider still needs more testing and feedback. Make sure to report any bug you encounter so I can fix it as quickly as possible!
- FreezerburnV 12y ago
  Awesome, thanks. I'll see if I can squeeze in some time to poke around at Spider, (I'm sure you understand how hard it can be to prioritize hobby projects :) and I will definitely file any bugs I come across.

Jaecen 12y ago

This looks to be an implementation of the concepts (but not the language) proposed in http://www.walkercoderanger.com/blog/2014/04/what-coffeescript-should-have-been/ http://www.walkercoderanger.com/blog/2014/04/what-coffeescri.... Several of the terms used are exactly the same.

alongub 12y ago
Spider was highly inspired by this article. In the original "Introducing Spider" article I wrote, I referenced it

drewying 12y ago

Kudos to the creator. Writing something like this takes a lot of effort and it looks like they did a great job! Well done! With that said, on wider level, what's the allure of these JavaScript replacement languages? Is JavaScript syntax really that difficult for some developers to wrap their head around? I can understand something like Dart that has an underlying goal of performance, but the purposes of things like this or CoffeeScript genuinely confuse me.

alongub 12y ago
It's not that JavaScript syntax is difficult. It's that there are some common patterns that repeat themselves so much times. For example, safe object navigation. This code in Spider/CoffeeScript: var x = a?.b?.c?.d; compiles to something like: var x = typeof a !== "undefined" && a && a.b && a.b.c ? a.b.c.d : void 0;
- bsimpson 12y ago
  I've been using node-jsx and jsx-loader to bring JS Harmony syntax into projects I'm working on now. The last great hurdle to make JS a language that's easy to express in is the existential operator. It sucks how often you have to manually null-check in JS. I'm mighty tempted to write a Webpack plugin to make `?` usable in vanilla JS.
- joshuacc 12y ago
  You can also handle problems like this via libraries. For example, underscore-contrib [1] does it this way: var x = _.getPath(a, "b.c.d"); There are definitely advantages to having this pattern baked into the language, though. [1] http://documentcloud.github.io/underscore-contrib/ http://documentcloud.github.io/underscore-contrib/
tdumitrescu 12y ago
The main reasons I reach for Coffeescript for my personal projects are: * built-in support for comprehensions and other array/object operations * simple syntax for context binding * automatic module isolation. These eliminate a lot of boilerplate littering my JS code. At my company gig we use JS but rely heavily on Underscore to address the same pain points; I prefer to have it built into the language syntax instead. ES6 probably has enough of this built in to make me switch back eventually.

wiremine 12y ago

I'm still a bit unsure about these sorts of projects. I like the idea of improving Javascript's rough edges, but whenever I start a new project, I always seem to stick with plain old javascript. That said, Spider feels like it is heading in the right direction: - It embraces JS's prototype OOP. I've never liked how CoffeeScript tries to add traditional classes. Not sure the syntax is right, but I appreciate the goal. - It adds just enough "modern" features and syntax to feel like Javascript without requiring me to learn a whole new language. Feels like modularity is missing, though. Is there any support for "require" or "import" or something similar?

alongub 12y ago
I'm still unsure how to add modularity while maintaining compatibility with CommonJS, AMD, etc. I thought about adding a require statement such as: require "vm" require ( "util", "io" ) That would also support git repos, inspired by DuoJS (https://github.com/duojs/duo https://github.com/duojs/duo): require "alongubkin/phonertc"
fizzbatter 12y ago
> Feels like modularity is missing, though. Is there any support for "require" or "import" or something similar? I haven't personally tested it, but i imagine everything is supported, including require and import. It doesn't look like Spider does anything weird to scoping, so to use a global you simply use it with `::global(foo)`, or `use global; global(foo)` I imagine require would be `use require; require('mylib')`, and etc.
- alongub 12y ago
  Of course, but I think he meant native modularity support, which is important IMO.
  - fizzbatter 12y ago
    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. How would you handle this issue, i wonder?

brandonhsiao 12y ago

i'm always curious, why keep brackets? if blocks can be implied by whitespace (that vi can handle for you), what do explicit brackets buy you in exchange for the time it takes to type them?

klibertp 12y ago
Easy copypasteability. Yeah, I don't understand why this would be an advantage either, but that's an argument I see most often.
munificent 12y ago
Explicit delimiters compose inside expressions much more gracefully. This is the main reason Python doesn't allow multi-line lambdas: if you have some significant indentation inside another expression, it's hard to tell how the rest of the expression following the unindent should be formatted. CoffeeScript does handle this, but I've always felt it was a murky corner of the grammar.
- breuleux 12y ago
  You can easily allow both, though. At worst you can simply turn off significant indent inside explicit delimiters.
  - munificent 12y ago
    Sure, but then you need to implement both ways to express the same thing, and then deal with the infinite arguments it will spawn between proponents of each camp.
    - breuleux 12y ago
      Typically, what I do is just map the indent and dedent tokens directly to some suitable bracket pair, so the implementation is trivial. As for the infinite arguments, well, as a language designer, is that really your problem? I mean, that kind of stylistic argument is no different from the endless arguments about bracket placement in C-like languages, or comma placement, "a+b" versus "a + b", and so on. People quibble about the dumbest things, I say just let them.

klibertp 12y ago

> CoffeeScript (and its derivatives: LiveScript, Coco, etc) have serious issues of ambiguous code, alien syntax and scoping problems. How long will programmers think of "alien syntax" as a problem? I don't understand it at all - syntax should fit the problem domain and language semantics first and foremost, NOT expectations of programmers writing in other languages. It makes absolutely no sense - from a language design perspective - to invent a new, interesting language and then try to fit it into some "standard" syntax. In my mind this misses at least half of a point of creating a language in the first place!

CmonDev 12y ago
But there is no problem: "programmers writing in other languages" - they will keep using those other languages, while you will use your new language with unusual syntax. Alone. Now if you want to persuade those other developers to use it, then maybe you should meet them half-way?
- 14113 12y ago
  You're assumming that programmers will only switch languages if they already "know it". What about other benefits to other languages, such as different paradigms, type systems or other semantic features? Surely to someone who actually writes code they're just as important as the syntax?
  - AnimalMuppet 12y ago
    > Surely to someone who actually writes code they're just as important as the syntax? They're more important. I don't switch tools just to get better syntax (unless the syntax is really horrible). I switch to get a tool that will do something different, or do the same thing better. So: Don't switch syntax just to switch syntax, and expect anybody to care. On the other hand, things that are really different but have the same syntax can be confusing. You subconsciously expect it to work the old way, and it doesn't...
tomp 12y ago
IMO, the bigger complaint about CoffeeScript is ambiguous syntax - the syntax tree is very sensitive to even the smallest whitespace changes.

fizzbatter 12y ago

The only thing i don't like so far, is `func` and `->` both expressing functions. I use Coffee a ton, and Golang, so oddly enough i love both syntaxes.. but i don't like multiple ways to declare a core feature like functions. Just my 2c. Fwiw, i'm going to be trying this out asap - I have high hopes for this replacing my very heavy CoffeeScript usage!

alongub 12y ago
I actually agree about this - two ways to do exactly the same thing is generally a bad thing when it comes to language design. But I think that a more important goal is to make the transition from Spider to JS as easy as possible.
14113 12y ago
I think it's quite good - it allows a programmer to conceptually separate her "normal" functions from lambda expressions, even if they're essentially equivalent, and one is syntactic sugar for another.
woah 12y ago
ES6 already has =>, I think that Spider should probably stay far away from trying to replicate existing language features with different syntax
tomp 12y ago
Many functional languages have shortcut syntax for inline functions, e.g. in OCaml: let f = fun x y -> x + y Haskell: let f = \x y -> x + y It looks that Spider uses a similar syntax, but uses uncurried form in line with function invocation syntax.
rld 12y ago
It's not duplicate syntax. `func` adds a named function to the current environment, and `->` only describes an anonymous function. It's the equivalent of `function foo(...)` vs `function(...)` in JS.
- fizzbatter 12y ago

mariusc23 12y ago

Neat! Did anyone make a grunt plugin yet? :)

alongub 12y ago
You are welcome to make one! :)
- mariusc23 12y ago
  I've never built one before, but here's my first attempt: https://github.com/mariusc23/grunt-spider-script https://github.com/mariusc23/grunt-spider-script Let me know if you notice any issues!

notastartup 12y ago

I'm sorry but the syntax is absolutely gash! This is like a horrible lovechild between Python and Coffeescript gone terribly terribly wrong. If that was the selling point then its a no go from me. I know this sounds harsh but I actually thought that this was a language to create web crawlers. func TimeMachine(pilot) { this.pilot = pilot; this.go = func (noise) { ::console.log(noise); }; } func Tardis() extends TimeMachine("The Doctor") { this.go = () -> super.go("vorp vorp"); }

alongub 12y ago
Appreciate your opinion! About the :: syntax: http://spiderlang.org/#code-safety-global-scope-usage http://spiderlang.org/#code-safety-global-scope-usage About the extends/super syntax: http://spiderlang.org/#functions-inheritance http://spiderlang.org/#functions-inheritance
- seabrookmx 12y ago
  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..

woah 12y ago

I'm worried by the focus on OOP in the examples. I hope that OOP is not a focus in the language. This nice and simple enough of a language that I could see JS people getting on board, and using this for real JS stuff. I'm afraid that an inordinate focus on OOP will alienate JS devs, who are already good at writing in a functional style and don't need it. The people who will appreciate the trappings of OOP are more than likely the typical classically trained programmers, who will write 300 lines of Spider on the frontend of their Python hobby project, and not touch it again.

alongub 12y ago
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 :)
- nilliams 12y ago
  Yep, same as CoffeeScript. 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.
nilliams 12y ago
Can't agree with your implication that 'real JS stuff' won't get done and 'JS people' won't get on board due to its 'focus on OOP'. I've yet to see a large JS app written in a 'functional style'. Most large client-side apps I've come across are written in Backbone, Angular, Ember etc. which are all frameworks/libraries that embrace OOP. You shouldn't mistake JavaScript's 'prototypal' nature for it being a non-OOP language. JavaScript and OOP are a very good fit. > The people who will appreciate the trappings of OOP are more than likely the typical classically trained programmers, who will write 300 lines of Spider on the frontend of their Python hobby project, and not touch it again. If you're really dismissing __all of OOP__ to that extent I feel like you are seriously misunderstanding OOP and I highly recommend you read/watch at least: - POODR by Sandi Metz [1] - Explores OOP, SOLID principles, testing, more. The best book on OOP I've ever read. Ignore the fact the code examples are in Ruby (by that I mean, they're easy to understand). - Refactoring by Martin Fowler [2] - The definitive refactoring book... which goes hand in hand with OOP. - Boundaries (Talk) by Gary Bernhardt [4]. He talks about the 'functional core, imperative shell' pattern of software architecture that acknowledges the fact that some form of OOP/procedural/imperative programming is unavoidable. It's a great talk. Outright dismissal of OOP really has no place in modern programming. Even if you get into functional languages like Clojure you'll find they're actually embracing a lot of OOP ideas [3], even though they pretend they're not into it :) [1] http://www.poodr.com http://www.poodr.com [2] http://martinfowler.com/books/refactoring.html http://martinfowler.com/books/refactoring.html [3] http://www.youtube.com/watch?v=13cmHf_kt-Q http://www.youtube.com/watch?v=13cmHf_kt-Q [4] https://www.destroyallsoftware.com/talks/boundaries https://www.destroyallsoftware.com/talks/boundaries

DonGateley 12y ago

Is backward transliteration from pure JavaScript to Spider possible so that one can deal exclusively with Spider and not have to learn JS in order to deal with other people's code? If one must know both in order to be an agent in the real world then its utility is somewhat limited.

vorg 12y ago
> Is backward transliteration from pure JavaScript to Spider possible Yep, this is important to avoid the "Groovy" problem where Groovy is valid Java, except for lots of little cases where it isn't, e.g. == behaves differently, default member access behaves differently, etc etc. Since Java 8 lambdas, Groovy is now wildly different in its syntax.
- DonGateley 12y ago
  'Fraid I don't understand your response. What is Groovy and what has it to do with Spider?
  - lbearl 12y ago
    Groovy is a JVM language which is dynamically typed (a la python and ruby). It never really took off, partly because you had to understand java (and the JVM) pretty well in order to do anything other than trivial scripts with it. The point being made is that if Spider wants to take off, it had best not require an intimate knowledge of javascript - and we can look to groovy to see what happens otherwise.
ryanthejuggler 12y ago
Interesting comment; it seems to imply that some people will learn Spider before JavaScript. Whenever I come across one of these compile-to-JS languages I take it as "this makes you more productive, as long as you've learned JS first and understand the mapping". Spider does look like it would actually be a really cool first language to learn!

deleted 12y ago

[deleted]

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 ago
I'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 ago
  fn is a often used as a variable name
  - sanderjd 12y ago
    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.)
- warble 12y ago
  I 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.

vinodkd 12y ago

Nice! I started on something like this a while ago: https://github.com/vinodkd/betterscript https://github.com/vinodkd/betterscript. You have a slightly larger goal - a better js with some useful syntax from other languages/efforts. Mine was just a better javascript. But: I did have a module syntax. No plug here, btw; feel free to borrow any/all syntax and kudos for getting it done:)

drawkbox 12y ago

One thing for sure is apparent in the new Javascript movement is that every framework tries to script your Javascript and not be Javascript. Nothing against experimentation and there are merits to generation to target platforms, but this is a common theme. The NBL is Javascript yet everything to support it moves away from it? Very strange, do people hate Javascript that much? Try my new scripting language, it will help you script your Javascript.

oweiler 12y ago

Additionally, loose typing can be one of JavaScript's best features if used correctly. For me, this is by far the worst feature of JavaScript.