Show HN: LiteScript
luciotato.github.io
luciotato.github.io
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.
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.)
You mean like those at Google (dart), Microsoft (typescript), Mozilla (asm.js) and the developers of dozens of other languages that compile to javascript, I guess: https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
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.
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.
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.
Just being capable of being a translation target for other high-level languages is totally insufficient to be considered similar to assembly language.
(Disclaimer: I've worked on compilers that target both assembly language and compilers that target Javascript)
That being said, we now have asm.js, which isn't that bad of a compile target.
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.
[1] http://www.chromium.org/nativeclient/pnacl [2] http://liuliu.me/ccv/js/nss/
I applaud you for building something cool, but what are the "huge advantages" that you laud in the title?
- if you have a "class Token" and later do "var token", the type is guessed by name affinity.
- if you do:
token = .getToken()
other = token
2. Type annotations: you directly state type
var other:Token
var read: Token array
See https://github.com/luciotato/waitfor ,node-fibers, and the same with generators: https://github.com/luciotato/waitfor-ES6
But I must say I found this link more informative http://coffeescript.org/#literate
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.
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.
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.
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?
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.
"55"
This is why people don't like JavaScript.
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.
e, data = fs.readFile! 'data.dat'
console.log data.toString()---
Real use cases so far
On the server: LiteScript itself
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?
Anyway, this does look cool. Good job.
[0]: https://github.com/luciotato/LiteScript#real-use-cases-so-fa...
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.
https://github.com/luciotato/LiteScript/tree/master/devel/li...
Thanks for the explanation :)
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?
To PHP: If you have only PHP in your hosting, you can have LiteScript source and compile for node.js or PHP.
To C: (node native module/nginx module), when you need a ultra-fast service, and js/V8 is not fast enough.
Any of this two compiler targets make sense for you?
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.
A few questions:
- 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?
Sounds intriuging, anyway...
I meant: LiteScript is designed with the Grammar https://github.com/luciotato/LiteScript/blob/master/source/G... separated from the "production" of target code https://github.com/luciotato/LiteScript/blob/master/source/P...
I "want" to (and think I can) add new "producer" modules other than "producer_js", but I've not even started.
The idea -so far- is to compile to a node native extension http://nodejs.org/api/addons.html#addons_hello_world so most C answers are: V8's
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.