

Spider Programming Language - alongub
http://spiderlang.org/

======
klibertp
> 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!

~~~
tomp
IMO, the bigger complaint about CoffeeScript is _ambiguous_ syntax - the
syntax tree is very sensitive to even the smallest whitespace changes.

~~~
alongub
Exactly. Syntax style is usually a matter of personal opinion. "Alien syntax"
wasn't very objective and I should probably remove it from the website.

However, ambiguous syntax is a huge problem of CoffeeScript. Read more here:
[http://ceronman.com/2012/09/17/coffeescript-less-typing-
bad-...](http://ceronman.com/2012/09/17/coffeescript-less-typing-bad-
readability/)

~~~
klibertp
> 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.

------
wiremine
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?

~~~
fizzbatter
> 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
Of course, but I think he meant native modularity support, which is important
IMO.

~~~
fizzbatter
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?

~~~
alongub
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.

~~~
woah
I think you should stay far away. It's a solved problem.

------
Lerc
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
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.

~~~
warble
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.

~~~
ptx
But 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..."

------
vinodkd
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:)

------
izolate
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
This is definitely possible. Can you open an issue in GitHub?

~~~
vanderZwan
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
Of course. Swift does this as well BTW.

------
fizzbatter
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!

~~~
rld
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
Can you not `func(foo){}`? Because that is what would bother me.

`func(foo){}` and `(foo) ->` seem too similar, for my taste at least. Sure,
the difference is that one is always anonymous, where as one is _sometimes_
anonymous.. but we've been using `function` as both named and anonymous for
ages

------
woah
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.

~~~
nilliams
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)

~~~
woah
Thanks!

------
brandonhsiao
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?

~~~
munificent
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
You can easily allow both, though. At worst you can simply turn off
significant indent inside explicit delimiters.

~~~
munificent
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
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.

------
drewying
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
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;

~~~
joshuacc
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/)

------
drawkbox
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.

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

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

------
DonGateley
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
> 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
'Fraid I don't understand your response. What is Groovy and what has it to do
with Spider?

~~~
lbearl
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.

------
oweiler

        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.

------
FreezerburnV
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
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
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.

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

~~~
alongub
You are welcome to make one! :)

~~~
mariusc23
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
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
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
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..

