8 ms·

Show HN: LiteScript

76 points by lucio 13y ago

switz 13y ago
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. I applaud you for building something cool, but what are the "huge advantages" that you laud in the title? [0] http://ashkenas.com/literate-coffeescript/ http://ashkenas.com/literate-coffeescript/
- lucio 13y ago
  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)
  - peq 13y ago
    How does the type guessing and the type system in general work?
    - lucio 13y ago
      1. Type guessing: - 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 the type of "other" is guessed from assignment (:Token) 2. Type annotations: you directly state type var other:Token var read: Token array The compiler does a "pseudo-execution" of the AST, guessing types and validating property access.
  - ulisesrmzroche 13y ago
    Does this depend on using --harmony? Or are you faking the generators?
    - lucio 13y ago
      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). See https://github.com/luciotato/waitfor https://github.com/luciotato/waitfor ,node-fibers, and the same with generators: https://github.com/luciotato/waitfor-ES6 https://github.com/luciotato/waitfor-ES6
      - ulisesrmzroche 13y ago
        It's good that it's not faking generators though, stick with harmony. Fakes slow to a crawl after a while.
- bliker 13y ago
  I did not know about Literate Coffescript. Thanks! But I must say I found this link more informative http://coffeescript.org/#literate http://coffeescript.org/#literate
- lucio 13y ago
  The compiler is PEG-based, very easy to extend. Check the grammar: https://github.com/luciotato/LiteScript/blob/master/source/Grammar.lite.md https://github.com/luciotato/LiteScript/blob/master/source/G...
- mistercow 13y ago
  >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.
SimeVidas 13y ago
With ECMAScript 6 around the corner, let's confuse everyone by inventing a new syntax. Makes perfect sense.
- Pacabel 13y ago
  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.
  - kybernetikos 13y ago
    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 https://github.com/kybernetikos/gulp-es6-template
deleted 13y ago
[deleted]
brodo 13y ago
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.
- Artemis2 13y ago
  Yeah, comment-centric languages are not my preference, as over-commented code tends to happen way more often.
- spo81rty 13y ago
  Comments blend in with the code too much for me.
- rsl7 13y ago
  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.
  - brodo 13y ago
    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)
    - rsl7 13y ago
      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.
- dclowd9901 13y ago
resu_nimda 13y ago
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.
- sheetjs 13y ago
  Relevant: http://blog.izs.me/post/10213512387/javascript-is-not-web-assembly http://blog.izs.me/post/10213512387/javascript-is-not-web-as...
  - Pacabel 13y 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.)
marukokinno 13y ago
Congratulations and Parabens!
basicallydan 13y ago
From the GitHub Page [0]: --- 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-far https://github.com/luciotato/LiteScript#real-use-cases-so-fa...
- skymt 13y ago
  It's quite common for compilers to be written in the language they compile. http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29 http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
- Kronopath 13y ago
  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.
  - basicallydan 13y ago
    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. Thanks for the explanation :)
  - yeukhon 13y ago
    But this is still in Javascript. I thought the whole point was to produce a LiteScript compiler in LiteScript to compile to LiteScript. https://github.com/luciotato/LiteScript/tree/master/devel/liteCompiler-v0.6 https://github.com/luciotato/LiteScript/tree/master/devel/li...
moron4hire 13y ago
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.
lucio 13y ago
to HN readers: I can make LiteScript compile to PHP or C. 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?
- deckiedan 13y ago
  Sounds... incredible. 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...
  - lucio 13y ago
    Great questions!, I guess I didn't express myself correctly. I meant: LiteScript is designed with the Grammar https://github.com/luciotato/LiteScript/blob/master/source/Grammar.lite.md https://github.com/luciotato/LiteScript/blob/master/source/G... separated from the "production" of target code https://github.com/luciotato/LiteScript/blob/master/source/Producer_js.lite.md 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 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.
- TazeTSchnitzel 13y ago
  Is LiteScript much simpler than JavaScript, and so you're able to compile it to C more easily?
igl 13y ago
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
drawkbox 13y ago
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?
- brandonhsiao 13y ago
  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.
  - drawkbox 13y ago
    True, I guess we'll continually make our way to Python syntax. It is the same reason I love writing Python, less typing, more correctness and power.
- lucio 13y ago
  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.
kybernetikos 13y ago
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.
- lucio 13y ago
  I knew that dimension of 'literate'. 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)
  - kybernetikos 13y ago
    I was referring to essentially this view: http://www.perl.com/pub/tchrist/litprog.html http://www.perl.com/pub/tchrist/litprog.html 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?
ilaksh 13y ago
If you like the way LiteScript works, check out literate CoffeeScript and ToffeeScript which allows async to be coded like this: e, data = fs.readFile! 'data.dat' console.log data.toString()
- lucio 13y ago
  Not exactly the same. LiteScript uses ES6-generators, handling also try/catch and making a readable js output code.

76 points by lucio 13y ago

switz 13y ago

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. I applaud you for building something cool, but what are the "huge advantages" that you laud in the title? [0] http://ashkenas.com/literate-coffeescript/ http://ashkenas.com/literate-coffeescript/

lucio 13y ago
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)
- peq 13y ago
  How does the type guessing and the type system in general work?
  - lucio 13y ago
    1. Type guessing: - 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 the type of "other" is guessed from assignment (:Token) 2. Type annotations: you directly state type var other:Token var read: Token array The compiler does a "pseudo-execution" of the AST, guessing types and validating property access.
- ulisesrmzroche 13y ago
  Does this depend on using --harmony? Or are you faking the generators?
  - lucio 13y ago
    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). See https://github.com/luciotato/waitfor https://github.com/luciotato/waitfor ,node-fibers, and the same with generators: https://github.com/luciotato/waitfor-ES6 https://github.com/luciotato/waitfor-ES6
    - ulisesrmzroche 13y ago
      It's good that it's not faking generators though, stick with harmony. Fakes slow to a crawl after a while.
bliker 13y ago
I did not know about Literate Coffescript. Thanks! But I must say I found this link more informative http://coffeescript.org/#literate http://coffeescript.org/#literate
lucio 13y ago
The compiler is PEG-based, very easy to extend. Check the grammar: https://github.com/luciotato/LiteScript/blob/master/source/Grammar.lite.md https://github.com/luciotato/LiteScript/blob/master/source/G...
mistercow 13y ago
>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.

SimeVidas 13y ago

With ECMAScript 6 around the corner, let's confuse everyone by inventing a new syntax. Makes perfect sense.

Pacabel 13y ago
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.
- kybernetikos 13y ago
  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 https://github.com/kybernetikos/gulp-es6-template

deleted 13y ago

[deleted]

brodo 13y ago

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.

Artemis2 13y ago
Yeah, comment-centric languages are not my preference, as over-commented code tends to happen way more often.
spo81rty 13y ago
Comments blend in with the code too much for me.
rsl7 13y ago
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.
- brodo 13y ago
  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)
  - rsl7 13y ago
    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.
dclowd9901 13y ago

resu_nimda 13y ago

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.

sheetjs 13y ago
Relevant: http://blog.izs.me/post/10213512387/javascript-is-not-web-assembly http://blog.izs.me/post/10213512387/javascript-is-not-web-as...
- Pacabel 13y 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.)

marukokinno 13y ago

Congratulations and Parabens!

basicallydan 13y ago

From the GitHub Page [0]: --- 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-far https://github.com/luciotato/LiteScript#real-use-cases-so-fa...

skymt 13y ago
It's quite common for compilers to be written in the language they compile. http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29 http://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29
Kronopath 13y ago
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.
- basicallydan 13y ago
  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. Thanks for the explanation :)
- yeukhon 13y ago
  But this is still in Javascript. I thought the whole point was to produce a LiteScript compiler in LiteScript to compile to LiteScript. https://github.com/luciotato/LiteScript/tree/master/devel/liteCompiler-v0.6 https://github.com/luciotato/LiteScript/tree/master/devel/li...

moron4hire 13y ago

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.

lucio 13y ago

to HN readers: I can make LiteScript compile to PHP or C. 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?

deckiedan 13y ago
Sounds... incredible. 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...
- lucio 13y ago
  Great questions!, I guess I didn't express myself correctly. I meant: LiteScript is designed with the Grammar https://github.com/luciotato/LiteScript/blob/master/source/Grammar.lite.md https://github.com/luciotato/LiteScript/blob/master/source/G... separated from the "production" of target code https://github.com/luciotato/LiteScript/blob/master/source/Producer_js.lite.md 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 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.
TazeTSchnitzel 13y ago
Is LiteScript much simpler than JavaScript, and so you're able to compile it to C more easily?

igl 13y ago

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

drawkbox 13y ago

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?

brandonhsiao 13y ago
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.
- drawkbox 13y ago
  True, I guess we'll continually make our way to Python syntax. It is the same reason I love writing Python, less typing, more correctness and power.
lucio 13y ago
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.

kybernetikos 13y ago

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.

lucio 13y ago
I knew that dimension of 'literate'. 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)
- kybernetikos 13y ago
  I was referring to essentially this view: http://www.perl.com/pub/tchrist/litprog.html http://www.perl.com/pub/tchrist/litprog.html 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?

ilaksh 13y ago

If you like the way LiteScript works, check out literate CoffeeScript and ToffeeScript which allows async to be coded like this: e, data = fs.readFile! 'data.dat' console.log data.toString()

lucio 13y ago
Not exactly the same. LiteScript uses ES6-generators, handling also try/catch and making a readable js output code.