Is this a brand new language or more like Coffeescript (something that makes Javascript look nicer)? Either is fine I just couldn't tell from the post.
I don't want to disencourage good initiatives and experiments, but if is not a technology that creates a "space" where "Everything is a.." then I won't be excited because is not going to be paradigmatic by design.
When "Everything is a.." you're forced to do a lot with little and that's really powerful. And creates a paradigm.
Some examples of it:
LISP: "Everything is an Expression"
Haskell and Miranda: "Everything is a Function"
Self and Smalltalk: "Everything is an Object"
I can't speak for Smalltalk or Miranda, but not everything in Haskell is a function, and not everything in Lisp is an expression.
The case in Haskell is obvious: 2, "foo", (Data.Set.singleton 3); none of these are functions. Functional programming isn't about "everything is a function", it's about (among other things) making functions first-class, and using higher-order functions to build powerful abstractions. (There are also a lot of other things associated with FP, incl. but not limited to: immutability, purity, powerful static type systems, focus on "plain old data" over OO hierarchies, laziness, etc). If you want a language in which everything is a function, you want the untyped lambda calculus.
The case in Lisp is a little less obvious; I've been meaning to write a blog post about this. But consider:
(let ((x 0)) x)
Is `((x 0))` an expression? No. It's a list of binding-pairs.
I'm intrigued by your comment that being forced to do a lot with a little is powerful. Do you have any arguments or evidence for that you could point me to?
"Everything is a String" => you have something Paradigmatic. A "space" or "knowledge body" that can explain a lot using little.
That's what I mean by being paradigmatic.
If you want more reference on this principle and you take the Quantum way, one thing you'll find is that you can explain a lot with little too. There is actually a theorem that deducts Newton's second law using only Schrödinger's Equation as foundation.
But since I've talked about this here I've won 3 downvotes, then you can rest for sure that the Universe is broken.
Ladies and gentlemen we already have TypeScript, Dart, clojurescript, scalajs, coffeescript, PureScript, elm, etc. More innovation in the web language ecosystem is not what is lacking. What is lacking is all the boring stuff like a sensible package management system, deployment mechanism, framework interoperability, etc. You know, all the un-sexy stuff that actual engineering requires.
> Ladies and gentlemen we already have NPM, Bower, Component, Duo, Jam, etc. More package management systems are not what is lacking. What is lacking ...
I find your comment to be snide, ungrateful and most of all uninformed. Personally I think new programming languages are interesting, despite how widely they might or might not end up being used, if they present new ideas, or solve difficult problems. Spider seems to solve a few Javascript problems and does so with a different approach to the other languages you listed.
You forgot jspm.io. So are you enjoying having all those choices and each one being subtly incompatible with all the others? Let me know how your next spider project turns out and how it interoperates with all the existing code written in coffeescript, typescript, dart, vanilla js, etc.
Actually, this looks like it hits a sweet spot (for my taste at least) that none of the others really quite do.
Ironically, I've now filed this in my head as something to look at when adding a web UI to some package management and deployment code I'm working on :)
What we really need is a replacement for Javascript as the 'bytecode of the internet'. It's clear now that people want to have the freedom to write client web code in whatever language they prefer. A web browser is just a VM for running the output of a [dart, coffeescript, scala...] compiler, and we should recognise that, and replace javascript (a language designed for humans to write) with a new bytecode (a language designed for computers to run), and then people can use whatever compilers they want to translate from the code they write to the code the user runs.
People can still write javascript with a JS->Bytecode compiler; people who want to write TypeScript or Dart can get better compilation or performance, and people can easily write a whole load of new languages and new compilers without being constrained by the intricacies and design decisions of Javascript.
I didn't mention asm.js but it was on my mind when I wrote the parent; it's possible that it is 'good enough' and eventually becomes widely adopted enough, but I wonder if we might do better by eschewing the need for compatibility with Javascript.
We might but first someone has to first design and specify the new Intermediate Language. Then submit it to ECMA. Then implement it in a browser.
This new IR better be so much better than JavaScript and asm.js at being a compile target for languages, that it takes no time for web application developers and compiler developers support it with enough tools and applications to dwarf their JavaScript counterparts. Good luck with that.
Currently each browser implements JS compilation different. Some compile to a bytecode, and others do not. Getting them to agree on a single bytecode format is very unlikely.
Yes, and please let this 'bytecode' actually be that used in CLI assemblies. In other words, can we have a .NET runtime in the browser please?
All that Javascript will continue to run beautifully, but I'll be able to write C# or Ruby, and those who favour other languages will likely be able to write them too, as there are so many supported.
I think in most cases, a bytecode solution would just be inserting another runtime layer between JS and hardware. It'd be a rough couple years of transition to get speed back, and not to mention the years spent trying to get everyone to agree to a standard.
Sadly, JavaScript may very well be our bytecode. Unless by some miracle one of the intended JS replacements actually takes off.
I can't help but be confused by the point of your comment (not trying to sound mean).
Are you saying that he (we?) shouldn't be developing new languages, and instead focus on "things that matter"? Ie, don't work on what you want to work on, work on what is useful to others / "solves real problems"?
I mean, that statement, while very useful at heart, seems ultimately close minded to me. It chips away at the soul of trying something new, or doing something fun.
I mean, i don't think anyone would argue that we need more languages, but i would (and am, apparently) argue against the idea that we shouldn't be creating new languages because we don't "need" them. Not everything should be industry scale and immediately applicable to professional needs.
New for the sake of being new is not engineering, it's fashion. Programming fundamentally is a problem solving discipline which means the tools I adopt and use at the end of the day are about augmenting my ability to solve new and novel problems instead of spinning my wheels in place and re-writing yet another old library in the new language du jour. The JavaScript framework/application ecosystem could use less fashion and more engineering.
That doesn't mean I don't think that spider is cool. In fact the list of language features is really well thought out.
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.
I disagree. There's still lacking a good compile-to-JS language that works well in the current library ecosystem (ruling out scalajs and fay) and has ADTs and good static typing.
Well you may want to read this link which may address your first complaint existing languages.
http://spiderlang.org/#why-spider
I think package management is well handled by npm on node and browserify on the browser.
projects like grunt make deployment a piece of cake.
framework interoperability is just like in any other language, it's up to individual library maintainers. Personally I've rarely had issues with interoperability. On the plus side I think on that same link you'll find that Spider works happily interops with vanilla js.
One way we could look at it is this; all these languages mean there is an option for everyone. I think if you look at the list of langs you mentioned (throw in vanilla js as well) you will find one that really speaks to you.
I have to disagree on principle and yet agree. This looks a lot better than the other options and I really hope it catches on. However, I can't really use it until it catches on, because I need all this "other" stuff to be done before I can use it in my projects.
- 'function' renamed to 'fn'
- syntax for message passing (a la Go's channels)
- syntax for promises
- syntax for currying (!)
- everything that coffeescript has
In my opinion that seems to satisfy everything a modern Javascript programmer could want from a new language. I'm a CoffeeScript person myself and I love my super succinct code, but I'm also aware many people are turned off by lack of braces, and possibilities of ambiguity.
That and the fact that I've noticed my colleague has been rewriting callback code I wrote into ugly promise-like objects so they could be more powerful, so I think it's a good time to be exploring for nicer ways of dealing with the issue, preferably with some sugar.
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.
Syntax != semantics. The JavaScript problem is not a syntactic one. Baking "channel <- message" into the syntax only introduces unnecessary syntactic complexity; why not just `put(message, channel)`?
In an implementation that follow's Go's semantics, both reading and writing from a channel can be a blocking operation that causes the current "thread" to suspend until the channel is ready to receive or provide a value.
That in turn means you need to compile it to something like the CSP-transformed JS you use for async/await. It's not just a little bit of sugar for a method call. The compiler needs to be aware of it so it can transform the code appropriately.
However, from looking at the code, it looks like spider currently only does this for channel reads. Writes are always non-blocking, which limits their usefulness.
So much of this is down to fashion.
Are programmers really bound by their typing speed? No.
The only real thing that matters with a language is "can I run this on hardware X", and "How fast does it run / how much memory". Syntax is utterly irrelevant (Unless you're into fashion).
I don't know if it's fashion, really. A lot of web developers aren't using IDEs like WebStorm, so they're missing out on autocomplete for a lot basic tokens, like "function".
I know when I started working on Angular apps after living in my Xcode bubble for so long, the first item on my list was to find a good IDE for web development. Sublime is good, but it's not that good. I don't type very much, I hit Tab key.
That's like asking an author if he writes using the alphabet or ascii.
Programming language debates are like asking Charles Dickens why he wrote in English rather than Russian. Would his books have been any different in Russian? No - it's irrelevant.
Language in literature is certainly not irrelevant.
Any translator (or even bilingual person) will tell you that some concepts are very hard to translate, because the target language was shaped by a different culture.
And in scientific and other non-fictions texts - which are closer to programs than literature - this was doubly so, as the number of important scientists and philosophers writing in non-native languages shows.
For me, it's not really about the amount of typing I have to do. In my opinion, function is so annoying because it takes up way more horizontal space on the screen than it needs to, especially if you get a number of them together.
It's not just fashion or typing speed- syntax affects how readable code is. Common tokens that don't have a lot of meaning intrinsic to the program being written should be smaller or you get mired in bureaucracy when trying to read it.
Which of the following is clearer?
plus(new vector(5, 3), scale(3, new vector(7, 3)))
new vector(5, 3).plus(new vector(7, 3).scale(3))
<5, 3> + 3 * <7, 3>
Probably the second one, but they all look basically the same to me. Perhaps programmers should get better at reading code.
The last one is least readable IMHO. It's like a regexp. It's the most ambiguous and has the most potential for errors also.
It's hard to typo "function" and have a program still compile/run. It's a lot easier to typo "fn" and still have the program compile/run. Smaller tokens mean more potential errors.
"brand new language to avoid JavaScript’s bad side while embracing its good side."
Why don't just use the good side? Well, with all the tools available for JavaScript - static code analysers, type checkers and code coverage tools, is it really _that_ hard to just write this damn code without introducing a new language?
I think it's an excellent learning experience to write a new language (even if it's based off an older one). To me the project is justified on this fact alone. Even if nobody ends up using it in production, who cares? They're having fun ;)
I love almost everything about this and dislike only a few things:
As k__ pointed I see no point in including semicolons, if you already have parenthesis that can be used to delimit expressions and newline characters, why include ";" ?
Another thing that I don't like is how the language is encourages type weakness in circumstances that normally lead to a dozen pointless bugs in my software during the development process:
a = -1
if a { // Actually meant a > 0
console.log("In if");
}
This could be avoided if languages didn't implicitly convert int, float etc values into boolean in the conditional expression of if. The result wouldn't even need a lot more code
if Boolean(a) {
That would probably require more code to implement into Spider in sections that might be performance critical. CG coders love to use those binary shortcuts in their code.
I installed spider-script through npm, but `spider somescript.spider` complains with $traceurRuntime not being defined. I can still compile the script, then require traceur and the script from another file, but I'd rather not have to do that just to try out the language :(
The FizzBuzz example is (still) bugged: it lacks semicolons and []s around [1...100].
Now for my thoughts: I like the way you handle globals, channels and async/await. Currying syntax is nifty, I probably wouldn't have chosen ^ but that's a bit of an arbitrary choice I guess. For integer division I prefer //, but I just realized you use that for comments. The module syntax works, although I prefer to group export declarations in a separate export or provide block.
I think the pattern matching is insufficiently powerful. Normally, pattern matching lets you declare variables as part of the pattern, so that it becomes a kind of switch on the different ways to deconstruct the input. I have an example of what I mean here: http://jsfiddle.net/f1ycatas/2/ . Matching the value of an existing variable could be done with syntax like `== n`.
75 comments
[ 4.0 ms ] story [ 133 ms ] threadWhen "Everything is a.." you're forced to do a lot with little and that's really powerful. And creates a paradigm.
Some examples of it:
LISP: "Everything is an Expression" Haskell and Miranda: "Everything is a Function" Self and Smalltalk: "Everything is an Object"
The case in Haskell is obvious: 2, "foo", (Data.Set.singleton 3); none of these are functions. Functional programming isn't about "everything is a function", it's about (among other things) making functions first-class, and using higher-order functions to build powerful abstractions. (There are also a lot of other things associated with FP, incl. but not limited to: immutability, purity, powerful static type systems, focus on "plain old data" over OO hierarchies, laziness, etc). If you want a language in which everything is a function, you want the untyped lambda calculus.
The case in Lisp is a little less obvious; I've been meaning to write a blog post about this. But consider:
Is `((x 0))` an expression? No. It's a list of binding-pairs.Just by being somehow basically-reductionist, you'll see that the Universe does a lot with just electrons, protons and photons, yes?
Well... if you for example adhere to String Theory then you will be able to model a lot with just strings http://en.wikipedia.org/wiki/String_theory
"Everything is a String" => you have something Paradigmatic. A "space" or "knowledge body" that can explain a lot using little.
That's what I mean by being paradigmatic.
If you want more reference on this principle and you take the Quantum way, one thing you'll find is that you can explain a lot with little too. There is actually a theorem that deducts Newton's second law using only Schrödinger's Equation as foundation.
But since I've talked about this here I've won 3 downvotes, then you can rest for sure that the Universe is broken.
I find your comment to be snide, ungrateful and most of all uninformed. Personally I think new programming languages are interesting, despite how widely they might or might not end up being used, if they present new ideas, or solve difficult problems. Spider seems to solve a few Javascript problems and does so with a different approach to the other languages you listed.
Ironically, I've now filed this in my head as something to look at when adding a web UI to some package management and deployment code I'm working on :)
People can still write javascript with a JS->Bytecode compiler; people who want to write TypeScript or Dart can get better compilation or performance, and people can easily write a whole load of new languages and new compilers without being constrained by the intricacies and design decisions of Javascript.
I think asm.js has proven itself to be a "good enough" solution if we start writing some serious compiler tech
This new IR better be so much better than JavaScript and asm.js at being a compile target for languages, that it takes no time for web application developers and compiler developers support it with enough tools and applications to dwarf their JavaScript counterparts. Good luck with that.
All that Javascript will continue to run beautifully, but I'll be able to write C# or Ruby, and those who favour other languages will likely be able to write them too, as there are so many supported.
Sadly, JavaScript may very well be our bytecode. Unless by some miracle one of the intended JS replacements actually takes off.
Are you saying that he (we?) shouldn't be developing new languages, and instead focus on "things that matter"? Ie, don't work on what you want to work on, work on what is useful to others / "solves real problems"?
I mean, that statement, while very useful at heart, seems ultimately close minded to me. It chips away at the soul of trying something new, or doing something fun.
I mean, i don't think anyone would argue that we need more languages, but i would (and am, apparently) argue against the idea that we shouldn't be creating new languages because we don't "need" them. Not everything should be industry scale and immediately applicable to professional needs.
That doesn't mean I don't think that spider is cool. In fact the list of language features is really well thought out.
Especially compared to Scala.js and Fay, I don't see the point of going backward to a slightly improved JavaScript again.
projects like grunt make deployment a piece of cake.
framework interoperability is just like in any other language, it's up to individual library maintainers. Personally I've rarely had issues with interoperability. On the plus side I think on that same link you'll find that Spider works happily interops with vanilla js.
One way we could look at it is this; all these languages mean there is an option for everyone. I think if you look at the list of langs you mentioned (throw in vanilla js as well) you will find one that really speaks to you.
EDIT: if it _does_ identify the most specific case, I think it's worth pointing out.
EDIT: Fixed
That and the fact that I've noticed my colleague has been rewriting callback code I wrote into ugly promise-like objects so they could be more powerful, so I think it's a good time to be exploring for nicer ways of dealing with the issue, preferably with some sugar.
Take a look at http://spiderlang.org/ :)
That in turn means you need to compile it to something like the CSP-transformed JS you use for async/await. It's not just a little bit of sugar for a method call. The compiler needs to be aware of it so it can transform the code appropriately.
However, from looking at the code, it looks like spider currently only does this for channel reads. Writes are always non-blocking, which limits their usefulness.
So much of this is down to fashion. Are programmers really bound by their typing speed? No.
The only real thing that matters with a language is "can I run this on hardware X", and "How fast does it run / how much memory". Syntax is utterly irrelevant (Unless you're into fashion).
Lisp is just basic with a different syntax...
I know when I started working on Angular apps after living in my Xcode bubble for so long, the first item on my list was to find a good IDE for web development. Sublime is good, but it's not that good. I don't type very much, I hit Tab key.
That's like asking an author if he writes using the alphabet or ascii.
Programming language debates are like asking Charles Dickens why he wrote in English rather than Russian. Would his books have been any different in Russian? No - it's irrelevant.
Any translator (or even bilingual person) will tell you that some concepts are very hard to translate, because the target language was shaped by a different culture.
And in scientific and other non-fictions texts - which are closer to programs than literature - this was doubly so, as the number of important scientists and philosophers writing in non-native languages shows.
Which of the following is clearer?
The last one is least readable IMHO. It's like a regexp. It's the most ambiguous and has the most potential for errors also.
It's hard to typo "function" and have a program still compile/run. It's a lot easier to typo "fn" and still have the program compile/run. Smaller tokens mean more potential errors.
> still got curly braces and semicola
Rust takes advantage of it's braces in good ways, I'd say.
I found myself struggling with whitespace-languages at first.
I'm actually kinda serious. Moving pieces of Python code around is unnecessarily error-prone. I don't consider this to be a good tradeoff.
I wouldn't consider braces the best things in go, swift or c#.
Why don't just use the good side? Well, with all the tools available for JavaScript - static code analysers, type checkers and code coverage tools, is it really _that_ hard to just write this damn code without introducing a new language?
As k__ pointed I see no point in including semicolons, if you already have parenthesis that can be used to delimit expressions and newline characters, why include ";" ?
Another thing that I don't like is how the language is encourages type weakness in circumstances that normally lead to a dozen pointless bugs in my software during the development process:
This could be avoided if languages didn't implicitly convert int, float etc values into boolean in the conditional expression of if. The result wouldn't even need a lot more code That would probably require more code to implement into Spider in sections that might be performance critical. CG coders love to use those binary shortcuts in their code.Type inference: https://github.com/alongubkin/spider/issues/58
The FizzBuzz example is (still) bugged: it lacks semicolons and []s around [1...100].
Now for my thoughts: I like the way you handle globals, channels and async/await. Currying syntax is nifty, I probably wouldn't have chosen ^ but that's a bit of an arbitrary choice I guess. For integer division I prefer //, but I just realized you use that for comments. The module syntax works, although I prefer to group export declarations in a separate export or provide block.
I think the pattern matching is insufficiently powerful. Normally, pattern matching lets you declare variables as part of the pattern, so that it becomes a kind of switch on the different ways to deconstruct the input. I have an example of what I mean here: http://jsfiddle.net/f1ycatas/2/ . Matching the value of an existing variable could be done with syntax like `== n`.