Some Suggestion

[JoyKrishnaMondal]

LiveScript is an amazing language and I keep in mind that making some suggestion and implementing them will take valuable time from the developers.

However I though I should still provide some suggestion to improve it since I like it so much !

Is it possible to bind operators to functions. A good example is --> currying. ls compiles a function for every script.

I use _.curry from Ramda and avoid using -->. It it possible to give users the ability to bind operators to functions so that people can use the curry implementation they like. It will make ls a lot more general and make it possible to introduce haskell like operators like <$>, <> - since the functional crowd in js are standardizing around the fantasy-land specs it will allow ls to be the first to make it possible to closely use those specs to build libraries.

Introduction of simple types would be awesome - but I know it will be hard given the current implementation of the lexer. Something like flow would be a boon since it brings a bit of typescript into ls.

lexical scoping using let

I am really excited to see how ls 2.0 turns out !

[vendethiel]

I am really excited to see how ls 2.0 turns out !

I'm not sure where you're getting there'll be a "ls 2.0", though...

[JoyKrishnaMondal]

not sure what you mean, do you mean there wont be a ls 2.0 ?

[vendethiel]

I know of no one working on that, at least.

A few people are sending patches (thank @rhendric , @summivox , @misterfish, etc), but no one has looked at them yet. I'm not working on LS anymore (and I've never been sending out that many patches), and @gkz's last commit that touched ast.ls (outside of styling & merges) was 3f362b0, Apr 28, 2015. Before that, the previous commit that added any code in this file was d3fab21, Oct 19, 2014.

[WreckedAvent]

Well, that's kind of sad.

[morningrat]

Is LiveScript over?

We can't let this happen. We need to start working on LiveScript 2.0.

[rhendric]

Who's ‘we’ though? With @gkz largely silent, and @vendethiel stepping down, there doesn't seem to be much in the way of leadership guiding what LS 2.0 should be.

Specifically, I see a few potential options ahead (with different requirements for level of leadership and development effort):

• LS 2.0 is a hardening of LS 1.5—no big rewrites (except maybe the lexer, which has needed one for a while) and no big new features like types, just being a little less conservative about making breaking changes in the name of introducing more consistency to the language in the spirit of the features and syntax that already exist. This is the easiest path, and requires the least leadership; any of us who've worked in LS for some time probably has a good enough nose for what would and wouldn't be okay. Unfortunately it also limits the potential audience for LS going forward; I've started to feel the language's limitations and would prefer to work in a language that is more amenable to modding.
• LS 2.0 adds some big feature to LS 1.5 and shakes up the feature set—here I'd be looking at proposals for types, Babel interop, different operator handling (including overloading in the more traditional sense, not the sense that we in LS use it to refer to 'string' * 3, and/or handling user-defined operators), language modularity, or macros, but with the goal still being to end up with a language that is largely the LS we have today plus some goodies minus the things that get in the way of us having those goodies. This is probably the most leadership-expensive option; someone needs to decide what big feature(s) to include, guide the design for their inclusion, and own the responsibility of making sure the legacy of LS remains alive enough in 2.0 that the community comes along. I wouldn't feel qualified to do that, and of the people remaining active in these conversations I'm not sure who would.
• LS 2.0 is actually a total rewrite or fork, a spiritual successor the same way LS was of Coco and CoffeeScript before it, preserving much of the aesthetic but permitting sweeping changes to the language. I've mused about doing this; if there are others interested in this level of project I'd love to brainstorm with you about what directions this could go in.

Might I propose an emoji reaction poll? 👍 if you want LS 2.0 to be the first option, 😀 if you want the second, 🎉 for the third?

(@gkz, not trying to incite mutiny; feel free to lay down the law at any time.)

[vendethiel]

With @gkz largely silent, and @vendethiel stepping down

As one can expect, those are mostly tied together. I prefered stepping down to mutiny...

LS 2.0 is actually a total rewrite or fork, a spiritual successor the same way LS was of Coco and CoffeeScript before it

If option 2 is the most leadership-expensive, this one is probably the most developer-expensive. Again, you can find me on IRC or Gitter if you want to chat.

[summivox]

The reason I've been silent these days is I'm moving to Bellevue WA (new job at Microsoft).
Regardless of the consensus, I'd like to keep this project going.

That said I am all for rewrite. We are left behind by the babel/typescript people.
Unfortunately we might be left with a python2/3 situation, but we can discuss this later.

[morningrat]

I'm interested in 🎉. Count me in.

[gkz]

I won't be doing any more major work on LiveScript, or working on "LS 2". I will merge in pull-requests, and occasionally fix a bug or release a new version on NPM.

The competitive landscape has changed. LiveScript is still better than JavaScript, but how much better has changed. ES6 has closed the gap considerably, decreasing the relative benefit of using LS over JS. Simultaneously, developer costs (in time) have increased dramatically. ES6 brought huge changes, and JS is now rapidly evolving, and in order to keep up, a very large amount of developer time needs to be invested.

Compile to JS languages (CoffeeScript, LiveScript, etc.) have "won" - they inspired changes and the evolution of JavaScript, and I think that's something to be happy about.

[gkz]

If you would like to create a fork or other related project, feel free. Just please use a different name other than "LiveScript" so people do not get confused - just like I chose a new name when I forked coco.

[austinfrey]

While ES6 seem to be including a few of the things that LiveScript, Coffeescript, etc have been using, I much prefer the syntax of Livescript. So whether it's a complete rewrite or some kind of breaking change, I hope this project continues. I come from more of a Python background and it seems to be doing just fine with having two versions and switching back and forth from one to the other really isn't bad.

[WreckedAvent]

It's already hard enough finding people who know and about and are willing to use livescript - forking and fracturing the community further seems like it would cause way more harm than good.

[vendethiel]

@gkz well, thanks for making your stance clear!

[gkz]

The development of LiveScript will continue - I will continue merging in pull-requests, and have merged some substantial ones in the past (eg. adding source-map support).

If you want to rewrite the lexer so it isn't so hacky, and send in a pull-request, I'll merge that.
If you want to add a new output mode adding ES6 output, I'll merge that.

As long as the pull-request is reasonably explained, and it passes the existing tests (or if it has needed to remove a test it is explained why), I will merge it.

[JoyKrishnaMondal]

I strongly agree with @aafrey.

Livescript is different then ES6. ES6 is also moving more towards classes and Object Oriented Programming in general.

If you want you can write code that looks really low level in Javascript or you can write code that looks a lot like OCaml/Haskell.

Sometimes just writing a piece of code in LiveScript makes it clear what is going on - prior to which I might have spent a lot of time not sure what is going on.

Just like with mathematics - a small change in notation can give you new ways to think about a problem. LS allows me to think clearly in a way that javascript really cannot compare.

[JoyKrishnaMondal]

@vendethiel @gkz

Just out of curiosity - it is possible to create a plugin system for LiveScript ? Similar to Babel. So people can write small plugins to make their own "LiveScript" - similar to babel but without some of the noise of babel.

Increasing livescript/core might cause breakage like so many languages.

by having a core and then various extensions will be really cool.

[gkz]

I had a thought of creating a series of Babel plugins that added back LiveScript functionality. So, people could have their ES6, but then add a function composition operator, piping, backcalls, etc. I don't know how much is possible, but it could be worth exploring.

[Delapouite]

A set of Babel plugins is a great idea. A few attempts have been made in this direction, like babel/babel#3159 for instance to implement piping. Could serve as inspiration.

[benjaminhon]

I love coffeescript, and am just reading and playing around with livescript now. Even though ES6 is nice, it still isn't coffeescript. To me the point has always been readability. I think all advancement in programming paradigms and frameworks is to just solve this single problem - READABILITY. Big organizations would prefer compatibility and conformity though.

So even though ES6 is nice and adds some new features. Coffeescript and Livescript still adds much more to the game, because it makes code more readable and thus facilitating more complex programs.

I think Livescript just needs more tutorials, IDE plugins (im using sublime text, but the syntax highlighter seems to have some bugs? and there is no coffee-compile like plugin at the moment which would be super convenient esp for learning). Maybe even a Udemy course would be great.

Hope this project continues, im hoping to use it for single-person projects :)

👍

[janwirth]

I also just found out about LS and will try it out now. Is it just me or does LS seem to gain some momentum? As well, I did not come from python / ruby but just like @benjaminhon and @JoyKrishnaMondal I feel that this style of JS seems way more readable and simply closer to the original intent of JS being a functional rather than an OO language.

[Announcement]

if no one else is interested id be glad to step forward. i have actually already changed a lot of features locally, but im only willing if its a total rewrite because i largely disagree with the current coding style. could probably offer releases every few weeks too! (have loads of free time) as some background i occasionally work on chromium's v8 and now blink. but livescript is very close to my heart ♥ i just hope this project never dies! ~ announcement

[summivox]

@Announcement : @gkz was against a total rewrite due to compatibility and (preventing) fragmentation.

Having worked with the codebase for some time as well and I understand your feelings.

Currently it is agreed upon that we should do big refactors while keeping tests green, which considering the size of the project as well as the lack of a formal spec is near impossible with a rewrite. Behavior in subtle un-tested cases might still change if we do big refactors but likely towards the "expected" direction and break only locally.

[sourcevault]

@FranzSkuffka : I think LS has hit a syntatic goldmine in the world of javascript. There are some issues I have with what gets compiled, but overall Its more readable than LISP, haskell. The closest language to it is OCaml which is quite popular.

@Announcement - you are the hero we need but not what we deserve. 👍

[Announcement]

if no one else is interested id be glad to step forward. i have actually already changed a lot of features locally, but im only willing if its a total rewrite because i largely disagree with the current coding style. could probably offer releases every few weeks too! (have loads of free time) as some background i occasionally work on chromium's v8 and now blink. but livescript is very close to my heart ♥ i just hope this project never dies!

[gkz]

I would be happy to accept pull requests that changed the coding style, I'm not happy with it either.

I would prefer a more functional, more clear, less code-golf style.

[Announcement]

@gkz You're back! how was facebook or google or whatever?

[sourcevault]

@gkz did you challenge Zauberberg to a fist fight ?

[pepkin88]

From my experience with the language in last 9 months, I have collected a long list of bugs and feature suggestions (over 60 items). I was planning to learn how the compiler works and to post some pull requests myself, but I still have trouble bending the code to my will (although I managed to implement 1 feature, yay).
I will be changing job soon, so I may have some time for LiveScript in the meantime.

[ozra]

Though I haven't coded web in about a year now, and hence LS, I've been with it for years and love it. The only way to dig up and restructure the language imo, is to spawn of a new project and a fresh clean slate - designed fully true to the LS-loveliness. Which of course has been mentioned by many in above comments. A new name and code base and strong homage to LS, will lead coders to it, like LS did from Coco, which did from Coffee, which... You get it.
I'm putting my spare time during autumn on a strongly LS-inspired compiled lang, so I can't be of dev-help for "LoveScript 3.14", sorry.

[janwirth]

@ozra and all, are you planning on implementing es2015 support? I think anything else may put the new projects at risk of appearing outdated quickly.

[ozra]

@FranzSkuffka - I must clarify - I'm just a fan-boy; a user of LS. My project is "completely unrelated" (it's syntactically inspired by LS - but it's typed and compiles to machine-code, not JS). @rhendric seems to me as the one to ask :-)

[rhendric]

I'd say the first person to do something besides talk about a successor project would be the one to ask. :-) (I'm not saying I won't be that person, but a few other stars need to converge first.)

That said, if we are talking: what do you mean by ES2015 support? As an output/compile target? Or as an alternate input syntax with backticks or something like backticks? (Just asking because I'm curious about what the community wants; I'm not aware of any plans for a successor project that haven't been expressed in this thread.)

[janwirth]

I think the LS syntax is pretty much perfect.
By support I am referring to ES2015 as a compile target with the future capability to reduce boilerplate code by utilizing standard features.
With all this ES2015 hype going on I think it will be hard to reach that many devs if we use an outdated version of ES as compile target.