
Show HN: LiteScript - lucio
http://luciotato.github.io/LiteScript_online_playground/playground
======
resu_nimda
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
Relevant: [http://blog.izs.me/post/10213512387/javascript-is-not-web-
as...](http://blog.izs.me/post/10213512387/javascript-is-not-web-assembly)

~~~
Pacabel
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.)

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

~~~
ma2rten
Like this

[https://developers.google.com/native-
client/dev/](https://developers.google.com/native-client/dev/)

?

------
switz
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
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)

~~~
ulisesrmzroche
Does this depend on using --harmony? Or are you faking the generators?

~~~
lucio
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
It's good that it's not faking generators though, stick with harmony. Fakes
slow to a crawl after a while.

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

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

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

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

~~~
nilved
> [5] + [5]

"55"

This is why people don't like JavaScript.

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

~~~
nilved
Yes. That's the behaviour in Python, Ruby and just about every other language
with overloaded operators.

------
ilaksh
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
Not exactly the same. LiteScript uses ES6-generators, handling also try/catch
and making a readable js output code.

------
basicallydan
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-
fa...](https://github.com/luciotato/LiteScript#real-use-cases-so-far)

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

~~~
yeukhon
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/li...](https://github.com/luciotato/LiteScript/tree/master/devel/liteCompiler-v0.6)

~~~
lucio
That's the result of compiling
[https://github.com/luciotato/LiteScript/tree/master/devel/so...](https://github.com/luciotato/LiteScript/tree/master/devel/source-v0.6)

~~~
yeukhon
Ah. Nice. Thanks. Need to dig down.

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

------
igl
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

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

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

------
lucio
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
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
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/G...](https://github.com/luciotato/LiteScript/blob/master/source/Grammar.lite.md)
separated from the "production" of target code
[https://github.com/luciotato/LiteScript/blob/master/source/P...](https://github.com/luciotato/LiteScript/blob/master/source/Producer_js.lite.md)

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.

------
marukokinno
Congratulations and Parabens!

