Discussion on adding a REST/SPREAD operator to the Haxe syntax

[Żabojad]

Hi there !

I've just created this ticket on the Haxe issue tracker : https://github.com/HaxeFoundation/haxe/issues/5741

As it's not an issue but an enhancement request, I would love to here from the community about it.

[As the Haxe syntax follows the ECMAScript standard](https://haxe.org/documentation/introduction/language-introduction.html), maybe adding the support of those new es syntax/features (and few others) would make sense ?

I use Haxe for javascript for quite a long time now. I really love it but I recently started to have the feeling that the recent evolutions of ES and the fact that the Haxe syntax gets modernized very rarely makes this language starting to get old and does not catch up with the latest and nice (imo) new ES syntax features...

I do not follow what is being told on this group regularly so maybe you already had that kind of discussion. I've search for "spread operator" in both this group and the haxe issue tracker and have not found anyone proposing it so far...

Please also do not tell me things like "a macro could do that". This, if supported, should be right in the implementation of the haxe syntax itself. Also I've been using macros on several projects and using them too heavily makes the compilation slower and sometimes buggy. Macros are not a solution for everything but that's another subject...

[Dan Korostelev]

I see this as a more general topic than spread operator or other ES features.Haxe (or rather Nicolas) is known to be very conservative about syntax and language features in general. This is a good thing usually, but I have concerns that Haxe can end up becoming Java with regard to syntax verbosity. I know that the reasoning is that Haxe syntax in its current state is very easy to grasp for a newcomer and that's a great thing, but in some cases *cough*short*cough*lambdas* it gets ridiculous not to add things that others have and use for years now.

I can't say I like all the new syntax sugar JS gets lately, but knowing that JS is the most popular language nowadays and people are adopting ES6 fairly quickly (judging by blog posts and job offers I get sometimes), Haxe is being challenged not to become a language for old people. :) Add TypeScript here, supporting all its syntax features while adding static typing and cool features like null-safety and lately even ADTs.

Haxe is still great and very much unmatched in terms of its cross-platform abilities, static analysis, macros, type system features like abstracts, but I'd like to see some process for modernizing the syntax and the language in general. Stuff don't have to be added/implemented in a short term, but at least some discussion that it's possible and won't stay a "proposal" for another 10 years...

понедельник, 10 октября 2016 г., 12:25:00 UTC+3 пользователь Żabojad написал:

[jacek szymanski]

"Haxe can end up becoming Java with regard to syntax verbosity" I think a much more important concern is that it is becoming Lisp with regard to library availability. Java had been the most popular language (and still is, at least when measured with job offers and not number of three commits ten lines github projects) despite (or perhaps because of) its verbose syntax and that before they even added generics. JS gained its popularity because of the web2.0 and later node craze, not because of language features again, it was a torture to write JS without JQuery or some other helper but these helpers were becoming available pretty much daily.

Haxe is a great language, but without libraries it won't be any more popular than Lisp is now, syntax sugar or not (BTW, Lisp had tools to generate Java and JS somewhere around 2006, it didn't help).

This is the most important challenge Haxe faces, not whether to add some operator or not.

js.

---

From: Dan Korostelev
Sent: Monday, October 10, 2016 12:45PM
To: Haxe
Subject: [haxe] Re: Discussion on adding a REST/SPREAD operator to the Haxe syntax

--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.

[Żabojad]

Well I do not think Haxe Faces only one challenge mainly due to the fact that Haxe is multi platform and used for many different kinds of stuff. I'm sure people making game in Haxe cpp have a very different point of view than people making web apps, cordova apps or node.js apps with Haxe js...

I use Haxe mainly for javascript and I think Haxe has the potential to be the best / preferred compiler for javascript among this huge community that is the js community.

But to get there, I do think know those missing operators are a big deal...

[jacek szymanski]

One wonders how you do know it especially when even in JS browser support is not universal, and on Chrome it's quite recent. So it couldn't have been a big deal there, why it would be now, and why it cannot be achieved with macros. Macros may be buggy, but so may be the core, and it's another reason against putting every me too feature into the language. Especially that history of languages, and why they become popular or not, tells us that language features are pretty much irrelevant. (Or maybe even harmful? On JVM and CLR there are tons of languages that have more advanced, anyway cool features than Java and C# respectively, and ready access to every library available for the platform, but they are hardly popular.)

OTOH a language can't get widely used without available libraries. One of the reasons of Python's success was its big standard library, and this is even more the case of Java. Yes, the Java's one mostly sucked even then, but it was there to use, and people did use it. Haxe will not surpass Java or even Python, but if it wants to become language for writing apps (and not only games), libraries are needed way more than me too language features (especially when these can often be achieved with macros).

js.

---

From: Żabojad
Sent: Monday, October 10, 2016 1:42PM
To: Haxe
Subject: Re: [haxe] Re: Discussion on adding a REST/SPREAD operator to the Haxe syntax

[Żabojad]

Interesting... The Haxe community still suffers from poor discussions dripping with bad feelings or lousiness behind each and every sentence... That might also be a big deal.

I do not say your point about libraries support is not valid. It very probably is valid. I'm however saying that being a multi platform language, Haxe has very different use cases and your point about libraries is certainly less valid for javascript than for cpp...

Now my point was and remains this : Haxe has all the potential to be the #1 compiler for javascript. And believe it or not, things like those operators are a big deal for the javascript community to adopt a language like Haxe.

ES6 features are definitively not "me too" features for a language that claims to follow the ECMAScripts syntax...

And I did not want to specifically talk about that but even in the Haxe community itself, things like short lambdas seems to be important for a large part of the community.

[Philippe Elsass]

There is a real lack of "cool" factor in Haxe, and syntax is one aspect devs are nowadays very sensible to...

I also can't trust JS source maps in Haxe 3.1.3 (yeah old school) and hope this had improved recently.

Philippe

[Marcelo de Moraes Serpa]

I agree with Philippe. I think the community should be more open to syntax changes such as the one suggested by @Zabojad, specially borrowing cool stuff from ES6/TS. Yes, generally JavaScript used to be a horrible language, but ES6 is actually quite good.

@Zabojad, you might want to describe your proposal here, it looks like it's the new way of suggesting new features for the language: https://github.com/HaxeFoundation/haxe-evolution.

On Mon, Oct 10, 2016 at 12:43 PM, Philippe Elsass <philipp...@gmail.com> wrote:

There is a real lack of "cool" factor in Haxe, and syntax is one aspect devs are nowadays very sensible to...

I also can't trust JS source maps in Haxe 3.1.3 (yeah old school) and hope this had improved recently.

Philippe

[Marcelo de Moraes Serpa]

Haxe is still great and very much unmatched in terms of its cross-platform abilities, static analysis, macros, type system features like abstracts, but I'd like to see some process for modernizing the syntax and the language in general. 

@Dan: Couldn't agree more! 

[jacek szymanski]

Well if you have bad feelings that's your problem, I don't. But it is you that comes here and claims that Haxe somehow needs these operators, and that in the core language, and that it's big deal, and that Haxe has all the potential to become #1 compiler for Javascript. These are quite extraordinary claims, especially given that it's pretty much impossible to show a single example where language feature was a decisive feature in adoption. And no, I don't believe in "Javascript community" massively adopting Haxe if these operators were added, given that so far typescript adoption is, well, quite far from massive.

Because, unless you think these three commits ten lines github projects, it's not programmers who decide what is used, but managers, and they hardly ever care about syntax goodies no matter how nice. What they do care about is language popularity it already has, available libraries and standards, things like these. Not syntax. Haxe has a big advantage here, its native compilation on most platforms, but to get to people who decide it must be able to use it in big (and not only gaming!) projects. And this more or less on its own - so far most of its multi-platform awesomeness is gone when one needs to add that -XXX-lib and thus bind oneself to a platform because there's no available Haxe library for doing something that for other platforms is pretty basic.

js.

---

From: Żabojad
Sent: Monday, October 10, 2016 3:11PM

[jacek szymanski]

If "cool factor" were ever decisive, Common Lisp would have the widest adoption, closely followed by Smalltalk. Or maybe Haskell.

js.

---

From: Philippe Elsass
Sent: Monday, October 10, 2016 7:43PM

[Marcelo de Moraes Serpa]

Jacek, 

The main point here is that Haxe is similar to ECMAScript and the manual claims that Haxe, quoting: "largely follows the ECMAScript standard", so what Zabojad proposes does make a lot of sense. Yes, we should be selective, but not close-minded.

It's also about reducing friction when someone from the JS community wants to jump into our bandwagon. It'd make the transition from ES6/TS->Haxe smoother. And we do need more js-minded people joining the community!

This, however, has been discussed a lot of times before, with similar flames being thrown. It's good that Dan created the Haxe evolution project, so I'd suggest to add these as an evolution proposal (please correct me if I'm wrong, @Dan) and I'm sure it'd eventually be picked up :)

- Marcelo.

[jacek szymanski]

Being selective I think also means being realist, so I think it's worth checking claims like Haxe might be #1 Javascript compiler, or that to achieve this Haxe needs some operators, or that the "cool factor" is what is important. New operators might help (but then they might not), but not unless there are "batteries included".

Syntax enhancement tend to light flames, yes, because syntax additions are indeed cool. Libraries, frameworks, standards, implementations are as far from cool as possible, but they are more important. I'm not against syntax enhancements, but I am against treating these as life-or-death issues when they clearly are not.

js.

---

From: Marcelo De Moraes Serpa
Sent: Monday, October 10, 2016 8:34PM
To: Haxelang

[Żabojad]

Hey Marcelo ! I haven't heard about this haxe-evolution project until now. I'll definitively have a look there...

[Nicolas Cannasse]

> I can't say I like all the new syntax sugar JS gets lately, but knowing
> that JS is the most popular language nowadays and people are adopting
> ES6 fairly quickly (judging by blog posts and job offers I get
> sometimes), Haxe is being challenged not to become a language for old
> people. :) Add TypeScript here, supporting all its syntax features while
> adding static typing and cool features like null-safety and lately even
> ADTs.

I don't think that we should do anything for one of the following reasons:

a) because it's cool/trendy/new

b) because JS/ECMA/Scala/you-name-it-other-language is doing it

c) because everybody else do - although it's reasonable to question "why
everybody do so?" in that case

Now if you think that some feature is **actually useful** for a good
portion of developers using Haxe, while integrating nicely into the
language, and not being a showstopper for newcomers, we can start
discussing about it.

But the "OMG LANG-XXX has YYY, let's add it too!" kind of mindset does
not seem like a good way to design a programming language for the next
10 years.

Don't forget that most of the popular languages out there are either
dynamically typed OR from/supported by big companies. Haxe is neither
which I think is the main reason for it not being mainstream, not its
feature set.

Also, imitation will most likely bring a total of 0 new users.

What we really need is innovation. Haxe does already a lot in that area,
from its type system, macros, multiple generators, etc.

And we need successful applications that we can brag were written in Haxe.

Best,
Nicolas

[S.A. Asselbergs]

Hi all,

I just want to add to the whole discussion about some feature and see some connecting it to some thing as big as it being a reason for a succesful language... I mean, come on!?!
Complaniing about why a language isnt succesful, only makes other language succesful. It doesnt motivate anyone of us. Seriously.

Instead of how other languages fail or succeed, it might be more productive to focus on reasonable arguments (as Nicholas gave) for not adding another feature or adding one for the sake of innovativion.

Also to you Nicholas, haxe deserves to be a mainstream language. It really does already. But at least to me I am happy enough it is an innovative language and making me so much more productive and it does really put fun into programming. Thanks for all of that!

Op dinsdag 11 oktober 2016 21:44:21 UTC+2 schreef Nicolas Cannasse:

[Todor Angelov]

i think in the opposite direction, something like relation
javascript -> asm.js

haxe -> (hscript+types)?

and this is what i do right now :)

[jacek szymanski]

Hi,

Haxe deserves to be mainstream language, but it is not one and will not be if it offers so little to non-game developers as it does now. It is not about complaining, it is about understanding. I propose that the acute lack of libraries outside of the game development world is a very important reason why Haxe is not more popular among non-game devs.

I don't think there's anything wrong in learning from other languages' history. Quite the opposite. Nicholas is right that Haxe needs successful appliations to brag about, but for these applications it needs what Python folk calls "batteries".

js.

---

From: S.a. Asselbergs
Sent: Thursday, October 13, 2016 1:08AM

To: Haxe
Subject: Re: [haxe] Re: Discussion on adding a REST/SPREAD operator to the Haxe syntax

[Marcelo de Moraes Serpa]

@Todor What do you mean?

[Tarwin Stroh-Spijer]

@jacek I don't think that's true. Haxe is really great on the server - it's actually why I got into it to begin with. Whether it's as a replacement for Node.js or PHP it is super powerful. I've been using it for ... at least 7 years now with the PHP target, using my own hand-rolled framework, and has been running a system which now serves 40 million users a month with sub 60ms response times. I'd use one of the many server side frameworks that are publicly available if I had started now - but even that said it has been easy to maintain, and that's on a Haxe 2.x system!

The ONLY problem I've had is that because we're using PHP as the backend, and relying on that to store things in memcache, our objects are stored as serialized PHP objects, rather than JSON, so it's hard to get other systems to also work with it. That's PHP's problem, not Haxe.

Tarwin Stroh-Spijer
_______________________

phone: +1 650 842 0920

Developer at Fanplayr Inc. (Palo Alto)

Original at Touch My Pixel (touchmypixel.com)
_______________________

[S.A. Asselbergs]

Hi js, others,

Haxe is already incredibly flexible, so  most of the things you need you can develop yourself with the current features. So let's just forward back in time, the days flash was popular.

I can remember the old flash community. We had to reinvent wheels many times, because initially flash library was very spartanic. More spartanic than what haxe already is offering now. It was very popular, but mainly used forr games and advertisment, or maybe even more so otherway around.  I think it was so popular because the players was installed on 90% of the computers and that it offered 2 things for which there were no real alternatives:
* more browser agnostic than javascript (javascript wars were still raging if you can remember)
* antialiased display, highly scriptable interactive animation with sound, video, bitmaps and vector graphics

It was so successful because it had no competition from the HTML5, Jobs didn't killed flash yet (as there was no dominant Iphone). Even when lot of people really hated activeX plugins, avoided those like the plague flash was installed as it was so much used. It turned out HTML5 and javascript, with a big help of Jobs killed flash. From that I leraned this:
* Web, games: your stuff has to run on smartphones (these are the most dominant devices). Flash was horrible at it after several attempts.
* web, business: your stuff has to really map well with HTML, css and javascript innovations otherwise even when you have some large business applications made with haxe it will still stay a niche. Adobe didnt really invest enough in flash development when it got traction. It alienated it's (older) users
* In any area of Focus: you have to have focus on few specific area's, not 10. So if it's games stick to that. But if it's something else, you better listen what the needs of developers who are into something else. Otherwise they wil ignore your technology.

I also like to add another thing I know about business:
* you have to be able to convince people haxe is here to stay, that it cannot die and that it will not become abandoned for example if one guy gets hit by a truck or something. There are so many competitors in the area of games. But with business it is all about: to have support, have a say about features, have a structure that get's employees educated/trained/certfied. It's more about such thaings like that than some feature X or Y. If they invest, they want to have a big say.
* Business users dot want to roll everything themselves, you need libraries that also have the promise to be maintained or it has to be inside the language. But what I see, is just like back in the days of flash, libraries that dont enjoy a long life. Businesses can develop such libraries, but that's a catch 42 too bootstrap isn't it?

Right now, haxe has no specific focus to any specific user base at all. It's sells a very impressive toolbox to serious and less serious tinkerers. It isnt  close to a turnkey solution to business, there is no shame in that. But forget about haxe being used by lot of businesses right now. Maybe on the long term. But it doesnt just need more PR to it, it needs serious manpower. Haxe Foundation would have to become a business itself, i mean with many people who are payed to make and maintain libraries and add features as support contracts require it.

The idea that haxe is a trojan horse, with a unifying source that bottum up get's it's gift to businesses, is not going to happen. That's a pipedream. You dont get businesses involved because you have that magic sauce, because your transpiler supports an insane amount of languages. No such magic sauce attracts tinkerers, that's good eough no shame at all, it's just the same as atrracting serious business anytime soon.

The question is if there are many external libraries that have short life cycles like now (but some very good ones stick around :-)), and you get fragmented by many targets and a very fragmented community (as each user who has his own specific targets he uses) and some people in control who make games still dreaming about getting a foot at the business area, how long will it take for all of these to realise that the lack of focus will make it hard to retain developers, will be a catalysator for the sourness as we see it in this tread. If it would be very clear haxe is for games alone, that would make people having clear expectations (people with incompatible expectations would quickly leave) and make its folowers more loyal and happy. No focus in the end devide us all.

I dont use haxe for games, I use it as my advanced toolbox for everything. I am a tinkerer. To me that is fine. I dont know if it's fine for the future of haxe. But people learn (nicholas too), the community is creative in the end it will become clear how much and where focus is needed, dreamers get confronted with reality in the end. Then haxe becomes grown up. It can grow up fast or slow (right now it goes slow) or maybe never. we'll see.

Most importantly we as a community are responsible to not poison eachothers fun with sourness. That is something I hope will stick from my post! You know what killed gentoo...


Op donderdag 13 oktober 2016 18:26:10 UTC+2 schreef Jacek Szymański:

[Todor Angelov]

@Marcelo, i mean subset of haxe like hscript with types and "standard"
language constructs close to c.
full utf8 support and minimal standard library.
with interpreter and compiler to c.
with no changes or very long life cycle.
something like "kernel" of haxe.
with guaranteed compilation to every present or future target...