It's interesting how the paradigm on "designing a language" has changed. I was very young in the pre-web native-only days, but it seemed like then you would have people writing their own languages and compilers that were pretty independent of each other and could be radically different (Haskell, Erlang, Prolog, etc).
Now that the web is becoming the dominant environment, EVERYTHING is HTML/CSS/JS (on the client side). That little package truly feels like the Assembly of the web (which is bad because that stack is too structured and high-level to be a good compilation target). And so now everyone just writes a layer of sugar on top of HTML/CSS/JS. These little toys that "compile" one high-level syntax to a slightly different one.
On one hand it makes sense, because what else can you do? Any radical non-JS front-end tech you might come up with simply won't be adopted. There's a chicken-and-egg problem, where nobody can adopt it until the browsers implement it, and the browsers won't do that until enough people are using it. Google, one of the few entities that has the power to get around that, has received mostly negativity and disinterest for their efforts (Dart). Is that just because it's Google? It even compiles to JS, because you just can't do anything that isn't JS. Seems like a real problem, and this is coming from a huge fan of JS.
Adding a Dart VM to the browser doesn't really help anyone. Some people, like myself, were excited as we might have been able to get a more traditional bytecode VM in the browser. However, Dart actually just adds a Dart VM, which is really not that different from a JS VM as a compile target, and so doesn't help the situation.
That being said, we now have asm.js, which isn't that bad of a compile target.
I agree, putting one more layer on top of JS does not allow to do substantially different things. But I would argue that this is the only option. Google is pushing its PNaCl [1] clients where you can run C++ code in your browser independent of the platform. Isn't this partially solution to the chicken-and-egg problem? It may get adapted because there is a strong player behind it. It also allows substantially different things to be on the web. For instance you can run some heavy computer vision app analyzing webcam stream directly on client side. Apart from notable JS exceptions [2].
I think there are lots of interesting new things happening in the world of programming languages, and its not all related to the web platform by a long shot. The thing that I find most encouraging is that LLVM and things like pypy make it much easier to create a language that stands a chance of performing half decently even without years of writing your own optimization code. I actually think the world of programming languages is currently more diverse than it was 10 years ago, although perhaps less diverse than 20 years ago.
The "JavaScript as the assembly language of the web" mentality seems to be taken most seriously by those JavaScript programmers who have absolutely no experience whatsoever with any sort of real assembly language. Many of them don't even have experience with something like C.
It's one of those things that sounds good on the surface, but upon further inspection by those who know assembly language it's quite clear that it just isn't true. Yet this doesn't matter when in a crowd that consists of people who, as a whole, don't know assembly language. The claim can be parroted repeatedly, without anyone really questioning it properly.
(I'm not directing this at resu_nimda, by the way. I see his comment more as a reference to the idea, rather than necessarily in support of it.)
The point of "JavaScript as the assembly language of the web" isn't that Javascript is exactly like Assembly was/is.
The point is that Javascript is as low-level as web-programming gets, and you can craft Javascript manually or let a compiler create it for you (with CoffeeScript, etc.).
Of course, the analogy isn't perfect, but that doesn't mean it doesn't fit.
But it's so far from low level, that's the problem. Assembly language represents the raw fundaments of computing, as we have envisioned them. It maps directly to the actual capabilities of the hardware.
If compiling to Assembly is like working with basic molecules, compiling to JavaScript is like working with lincoln logs. And you can build some impressive things with lincoln logs (just like you can build a computer in Minecraft), but you'll always be restricted to things that look like lincoln logs.
I think you're focusing on a different point then the argument. Javascript is often compared to the assembly language of the web because its a) low level web programming and b) its universal; both much like assembly in their own way.
How low level do you need in web programming? Probably not that low, why? Because with web programming it has the potential of being much easier to do something malicious if you have access to the raw hardware like you do in assembly. The whole point of Javascript was to make more interactive sites, and when it comes down to it, Javascript does an awfully good job at being that low level language to do so; It has come to represent the raw fundamentals of web programming as we have envisioned them. So just because its a fully formed language that is much higher level than anything assembly comes close to, doesn't mean that it still isn't 'low level' with in its use case.
Javascript also has the advantage of being universal, much like assembly. Assembly is universal in the sense that different flavors of instruction sets come on different microcontrollers but no matter what, nearly all uc's come with a reference guide which lists out the hex values for each instruction the CPU supports which can be used to build an assembler. These instruction sets all contain a core set of fundamentals such as basic math through the ALU, and storing/reading values and moving the PC and SC around. Which at the end of the day means that all uc's have support for an assembly language in some fashion that shares a common base. The same can be said with Javascript. Every browser comes with its own flavor of the language which supports the common base and then adds some fluff on top, but no matter what, nearly every browser comes with it.
At the end of the day though, trying to compare these is nearly a null-point to me, because they were designed in completely different ages of computing, and are designed for different tasks and are not (not easily at least, although a uc with support for a Javascript vm is possible, and replacing Javascript with assembly is fully possibly, both are rather difficult tasks and as such this argument is, for practical reasons, null also) interchangeable.
Implementing one high-level language (CoffeeScript, TypeScript, etc.) via translation to another high-level language (JavaScript) does not make the target language an "assembly language" in any sense.
It's called the "assembly language of the web" because it's the web's lowest common denominator that languages compile to, just like assembly language is the LCD of native platforms. More accurately, you'd say it's the "machine code of the web".
Sorry, you completely missed the point of the analogy. The point of the analogy is that within the realm of the browser Javascript provides the most natural substrate for compiler code generation, much like assembly is the most natural target for code generation in many other environments. It's a pragmatic point not a theoretical one. It has almost nothing to do with the specifics of either Javascript or assembly language as mediums for writing programs. You're overanalyzing it to the point where I have to think you are trolling.
(Disclaimer: I've worked on compilers that target both assembly language and compilers that target Javascript)
Let's build a HTML5-VM that run assembly instructions; and have a C compiler/assembler that compiles into it. I can put then HTML5-C and HTML5-asm into my LinkedIn and other social media profiles to really rub it into these youn'g faces.
I'm not sure about negativity and disinterest being "most" of the reaction to Dart. From people who actually take the time to learn a bit about the language, the reaction is mostly positive in my experience. Dart is growing, but unfortunately at this time that growth seems to be linear rather than exponential. It will likely take a major (non-Google) app being built in Dart, inclusion in Chrome, or inclusion in Android for it to really take off.
>The only differences from literate coffeescript[0] I see from this demo are that the var keyword is back and print is a macro for console.log.
It has more than that. Check the buttons down at the bottom. It has switch statements that look for a true expression, preprocessor macros, sugar for appending to classes (like Objective-C's categories), sugar for shimming, and "nice functions" for avoiding callback hell.
That's a lot more than you get with literate CoffeeScript.
1. There's a compiler validation phase, it guess types from definitions and assignments, and will caught typos in object properties, saving hours of debugging subtle bugs.
2. No callback hell while keeping async programming ("yield until", node.js --harmony)
today it depends on --harmony (only for "yield"), but it is trivial to add an option to use node-fibers instead (same functionality of ES6-generators for node>=v0.8).
There are a lot of people here complaining about redundancy against other scripting languages, but how many of them are working on anything really unique? They're probably all at some "innovative, gamified social media marketing startup".
Too many people fail to study more than a handful of languages, and they can't understand that how a person's experience in one language can translate to other languages. They spend a lot of time cherry-picking obscure language features and make them out to be make-or-break, everyday-common features of their favorite language, and if you don't know about them, you're doomed doomed doomed. As if the correct selection of StackOverflow postings hasn't already implemented every piece of software known to man in every programming language, already.
I think it will ultimately be good for the world to have more and more new languages come out. For one thing, it will help to blur the lines between languages. Show that languages exist on a continuum by creating that continuum. Show that syntax is trivial, far more important is wise decision making.
"A good workman can make good work with even the worst tools" gets bandied about, especially in response to critiques against PHP. While a good workman may certainly be able to make good work with bad tools, if they are forced to, at gun point, or the behest of their brother-in-law, a good workman would have curated for herself the best tools money could buy. And great workmen have a tendency to make their own tools.
It's also heartening to see so many new languages. It says to me that the quality of the average developer--despite anecdotal evidence--is increasing. It also suggest we live in amazing times that tools have progressed so far to allow anyone with slightly more than a basic CS education to be able to create their own programming languages.
So keep on keeping on, LiteScript. You're okay in my book.
What are you guys think about these 'comments are more important than code' languages/dialects. I'm kind of sceptical because comments can lie but code cannot.
It depends on how much you must work with other people on the code.
Sometimes it's helpful to think about your code as if you are writing it for other people -- which you are, even if that person is you in the future. The choices you make can result in the difference between a love letter and hate mail, even if it does the same thing in the end.
I kind of like the idea of emphasizing the comments in this way, turning the source file into a document, but I have never personally used anything like it. So it feels both kind of interesting/attractive, but also weird.
Interesting. Considering that, I think that it is a fundamental problem of current programming languages that you cannot address both the computer and the human in the language itself. (comments are an escape mechanism)
and my comments are sometimes about what was tried but didn't work, or alternate ideas that were considered, along with commented out code and examples.
I find I have to comment quite a bit with JS because so much can be left up to interpretation, even in the code. It's the only time I wish there was some manner of type safety in JS, even if only in expression -- it sucks when an out-of-date comment gives the wrong type of an incoming param, and it's not until you actually step through that you see that.
I have been developing javascript since the late 90's and love it. I don't understand the hate for it today in the sense that everyone tries to get away from it, why create so many code generators essentially?
Javascript is not that complex and in most cases maintaining the javascript and sugar syntax version with a code map for debugging seems like overkill (depends on the situation but in most cases it is more work). Many of these sugar syntax pre-compile libs/steps to javascript also act alot like Python which is great, but javascript compels people for some reason to stop creating it directly. So in that sense it is a bit like assembly in people wanting to wrap it, but it is very high level in itself.
That being said I do use pre-compile steps for CSS/JS including LESS, SASS, and Coffescript when the project fits which do have some productivity gains, but unless it gives me immense advantages like asm.js and native speeds, why the extra layers for minimal gains?
I guess it depends on the size of the project. I've reached a point, in pure js projects, at which refactoring code was too risky. It's too easy to introduce subtle bugs in pure js, just with a typo.
After hours lost debugging js code. You end up with certain fear to touch code that's already tested.
By migrating some projects to LiteScript I've found bugs lurking in js code I believe was bug-free. Also with LiteScript I found myself coding faster, fearless, trusting the compiler to catch typos and object misuse.
Javascript is great, wonderful. I love it too. Prototypal inheritance is also a refreshing approach to OO. But it was not designed to scale. And that's ok. It was designed to be a script to add dynamic properties to HTML pages. Simple, powerful, global var by default, return undefined if property does not exist (instead of throwing).
This are good decisions for the original purpose, but they do not scale.
Honestly, when I use SASS/Coffeescript it's not performance I'm thinking about. Most of the time it doesn't matter for the stuff I make. The reason I use these things is simply so I can type less. I don't have to type brackets/semicolons, I get all the syntax shortcuts in Coffeescript, whatever. It's so restricting when you can't type as fast as you think, and JS -> Coffeescript gets you closer.
What would you expect the behavior to be there? [5, 5]?
I know that JS has its quirks (to say it nicely), but once you understand it (type coercion, equality, scoping, etc) it doesn't seem to be a huge burden to me.
LiteScript is written in LiteScript, every new version must be able to compile itself to be ready for release. LiteScript is a real-use case of a heavy, server run, text processing, class based program written in LiteScript.
---
I'm must be missing something here, but this kinda blows my mind a little bit. Somewhere in the compilation process there must be somethign which isn't LiteScript?
No, not really, it's the same way that C compilers are written in C. The first one was written in another language like assembly, to be sure, but after that you could use the first compiler to write a second compiler in C, and the second one to write a third one, and so on.
In this case, I'm assuming the first version of the compiler was written in Javascript. After that, they could use the first Javascript-based Litescript compiler to compile a Litescript version of the compiler, and once you have that you never have to go back to Javascript again.
Cool, I did think it might be that, but when I read "LiteScript is written in LiteScript, every new version must be able to compile itself to be ready for release" it just kinda makes it sound like some kind of magic is happening, where a version of the language, before even being compiled, can somehow compile itself in some super clever way that I was just missing.
People throw the word 'literate' around a lot, and while I do like what we've got here, as originally envisaged, literate programming allowed you to lay out your code for narrative flow regardless of how the compiler needs your code to be sequenced.
I like what litescript is doing here (and in my opinion markdown is near perfect as a literate programming documentation language), I'm just worried that people will forget that the vision of literate programming is quite a bit larger than is typically implemented.
LiteScript allows you to "lay out your code for narrative flow regardless of how the compiler needs your code to be sequenced"
..by not requiring a specific sequence.
You can start with "main" code, and define "secondary" code and "helper" functions and classes later in the file.
(the price to pay to allow that is the need to do several passes over the AST to link object declaration to object usage)
In particular, my understanding of the original concept requires that you be able to create and reference macros for arbitrary pieces of code.
I hadn't seen any mechanism in litescript to allow you to split up your code beyond what is normally possible with functions (e.g. to defer the explanation of parameter defaulting or early return code to later), although perhaps you're referring to the preprocessor functionality which is an interesting feature, or maybe you think that you can extract functions for every meaningful lump of code these days?
Yay, another macro compiler. Man... finally a Class implementation for a language without classes.
How could coffee/live/gorilla not solve all of these "problems" already? +1
It has been "around the corner" for far too long now, especially when it comes to real-world usage. It's perfectly understandable that people would try to find alternatives in such a situation.
While personally I have no problem with people inventing new programming languages, I think that with es6 something like 80% implemented in latest firefox and chrome, expected to be properly finished this year and with good transpilers already in use, there's a really strong case for anyone who would otherwise be transpiling anyway to look at es6. Just yesterday I was seeing how far I could get with gulp and traceur: https://github.com/kybernetikos/gulp-es6-template
- Which object model & garbage collector system are you using? (in C)
- How do you handle scoping differences between JS/PHP/C?
- Which bignum and string libraries are you using in C? Is the String library fully unicode happy?
- How do you deal with 'eval', and other JS-specific functionality?
- You mention the classes being easily turned into C++ classes... how does that work with the dynamic nature of POJO objects, when at any time new methods and properties can be added to any object, or prototype?
With respect to PHP, I think it's simpler. The idea is to generate PHP but do not support all PHP quirks, just generate PHP code that is "js-like", (PHP mimics allmost all js functionality) and have support libs in LiteScript unifying APIS.
Some things like "eval" can throw a compiler error, when the target is PHP.
Javascript itself it's not too hard to compile to C.
The LiteScript added value will be to be able to test & debug as js, and then compile to C for production (adding all the boilerplate required for a nodejs extension).
The only thing I see as "easier to compile to C" (LiteScript vs js) is that in LiteScript you define classes & properties, so it's easier to define a C++ class from a LiteScript class.
Now that the web is becoming the dominant environment, EVERYTHING is HTML/CSS/JS (on the client side). That little package truly feels like the Assembly of the web (which is bad because that stack is too structured and high-level to be a good compilation target). And so now everyone just writes a layer of sugar on top of HTML/CSS/JS. These little toys that "compile" one high-level syntax to a slightly different one.
On one hand it makes sense, because what else can you do? Any radical non-JS front-end tech you might come up with simply won't be adopted. There's a chicken-and-egg problem, where nobody can adopt it until the browsers implement it, and the browsers won't do that until enough people are using it. Google, one of the few entities that has the power to get around that, has received mostly negativity and disinterest for their efforts (Dart). Is that just because it's Google? It even compiles to JS, because you just can't do anything that isn't JS. Seems like a real problem, and this is coming from a huge fan of JS.