Comment by Lerc | Hacker News Reader

Comment by Lerc | Hacker News Reader

I used haxe a lot in the past, but with the newer enhancements to JavaScript I found that I ended up using JavaScript. Destructuring assignment arrow functions and more concise object literals, ... operator enable much more concise and readable code.

Haxe seems to be much more conservative in development. Haze is aquiring arrow functions but I think there was quite a degree of initial resistance to the notion. I proposed a change to allow the new Javascript style consice object literals (simply allowing {fish,cheese} instead of {fish:fish,cheese:cheese} but was shut down with a 'we don't like it'

I would prefer to use a independent language over one developed by a megacorp, but I fear Haxe will fall behind TypeScript due to their resistance to change.

My own personal experience has motivate me to move to something else. The proposal I mentioned above left somewhat of a bad taste. The process went contrary to the processes listed. Notably The proposer is supposed to call a vote after discussion had concluded. Instead it was just shut down with a "we had a meeting and decided against it". I could give no counterargument because there was no argument to counter. I'm not against languages having a dictatorial model for development, but having a facade of an open process that carries no weight seems wrong.

Similar experience here. I've proposed a few changes to the language and none have been accepted. Rejecting convenience features with no downside like concise object literals is unfortunate. It literally took over four years to finally get arrow functions into Haxe, which had overwhelming community support.

Change proposals are subjective, so people can have different opinions on whether a change should be accepted or whether it was well-formulated enough. What bugs me though is that the Haxe team has a documented process for considering and voting on these proposals, which they don't follow. If Nicolas doesn't like a feature, it's essentially vetoed. If he changes his mind later, it'll be implemented without any further discussion. Most discussion happens in an internal Slack channel so there's no transparency. It's essentially a BDFL masquerading as a democracy, and it can be frustrating to try to contribute as an outsider if you don't realize that. See inline XML for example (https://github.com/HaxeFoundation/haxe-evolution/pull/26) - a lot of discussion, open questions remaining, seemed like Nicolas was generally resistant. Then suddenly, there's a PR and it's merged, and it will be in the next version of Haxe.

IMO, this is not the way to run an open source project. And in my experience, the team is resistant to feedback and takes things personally, so I've lost confidence that it will change.

Hi ben, it's clearly not the best place to discuss this, but I still wanted to leave you some message here, hope it'll reach you.

I don't think that you get a good language by having design by committee. I'm all for democratic process and contributions in many different areas, but you simply can't apply that to language design, but you really need a way to understand and see the big picture, and not only reason about a particular local feature.

The only thing we could do better here would be to spend more time motivating my decisions so they seem less random to people from outside, but it's time consuming to do so and I'm sadly lacking the time for it.

I understand how this can be badly perceived but you shouldn't put ill intend behind what has happened to your proposals.

Also, I saw you started designing your own language, which is very different from Haxe from what I have seen, so it seems to me what you wanted Haxe to be was simply not what it is and will be.

Thanks for the response Nicolas. I'm not reading any ill intent into this. I do think that it's time for the Haxe Foundation to make time to be more transparent, or it will continue to stunt your growth as community members get frustrated and leave. As you know, criticism like this isn't new, and it isn't going to go away.

If you don't feel design decisions can be made effectively by a committee and prefer to steer these decisions yourself, that's understandable - just remove the language about the core team voting on proposals or reaching consensus, because in practice it's not how the process actually works.

Sucks to hear about your experience. Like you said yes arrow functions are slated for the next major release.

As for the process, I think it has become a little more stringent for sure. To submit a request for consideration you’d need to submit a proposal on GitHub with attention paid to impact to existing code and impact on future Haxe features- perhaps your feature request wasn’t deemed to be thought out enough? It also looks like you’d get more explicit consideration if you are a sponsor of the language (https://haxe.org/foundation/support-plans.html)

So yes, while it isn’t a completely open vote, I also think most languages’ directions are decided by committee in a similar way. I’m sure the Haxe community would love to see examples of other communities with better practices to learn from.

> perhaps your feature request wasn’t deemed to be thought out enough?

In which case surely it should be discussed, rather than shut down with "no"?

This thread had me interested in Haxe, but reading these comments about the unfriendly, negative responses to proposals has put me right off.

To play devils advocate: if every feature request had to be thoroughly discussed you’d never get anywhere.. the onus should be on the proposer.

That said, you can always file an issue in github and have a discussion there. For Haxe it’s a very active location for discussion there.

>the onus should be on the proposer

I'll bite: what should @Lerc have done differently in his proposal (https://github.com/HaxeFoundation/haxe-evolution/pull/51)?

It seems like there’s some leeway in ‘After reaching general consensus or voting takes place, the PR is merged by someone from the Haxe developer team, and the proposal becomes "active". When merged, the proposal will receive its number from the corresponding pull request. If the proposal is rejected, the PR is closed with a comment explaining the reasons.’

I think general consensus was reached without a formal vote. Discussion was limited but explanation was given: language clarity would be impacted. A few main contributors agreed. @lerc didn’t provide much of a counterargument.

That said, what would you have wanted to see done differently? A formal vote held? This proposal seemed to be a matter of preference, with no real consensus on clarity. Workarounds were even proposed. What would be your ideal resolution? Not shutting down the discussion as haphazardly? How much further should it have gone?

I didn't give much of a counterargument because there was hardly any argument to counter. If the issue had not have been closed so quickly I would have pressed people for specifics of what they thought were wrong. At the time I believed I was the person responsible for calling the vote so I was prepared to give them time to provide a coherent argument.

I think at the end of the day there was simply no interest in the proposal. Nadako was "not opposed to it" but that was about it. Personally, I would have liked to not have seen the conversation ended with a "that's what we decided elsewhere" message.

That being said, this particular proposal seems like a matter of opinion (on the level of tabs vs spaces) to which no amount of argument would have really swayed people. Definitely something to learn from here. Thank you for sharing your story!

I feel like you are missing the point here. Project maintainers can behave like absolute arbitors if they want to. Many projects successfully work by this mechanism. The issue as stake here isn't how they decided on the proposal but rather that the way that they decided on the proposal is different to the processes that they specified.

They are soliciting contributions by promising an open process ( see https://github.com/HaxeFoundation/haxe-evolution#voting-proc... ) but disregarding those processes when they feel like it.

Ironically, the discussion we are having here is much closer to the level of engagement that should have happened there.

As a sidenote, I'm just curious, what do you personally think of the proposal? Would you like to have the concise object literal notation in Haxe?

I think I posted in a parent comment that I think they did follow the (somewhat arbitrarily defined process) if you give leeway to the phrase "After reaching general consensus or voting takes place"; whereas it seemed like a general consensus was reached in that situation. I think a clearer process that's a little more transparent would definitely be beneficial, including clearing up that phrasing.

On the sidenote, I personally don't run into many (if any) situations where I would use concise object literal notation. I'm on the fence as to the issue of clarity and whether it would help/detract/be neutral for Haxe.

The style of concise object literals is fairly inconsistent with the rest of the language at the current time, and I could see how it could lead to clarity/confusion issues. Because I believe it's more of a syntactic sugar than anything else I am leaning to agree that macros may be the way to go for it.

I just checked the link to the proposal and I don't think there was anything wrong.

A little discussion about the proposal. Some didn't seem to like it because of 'language clarity'. Some group of core developers discussed it and rejected it.

I don't know what one expects but I have seen quite some language proposals (rejected) and this didn't seem inappropriate to me. They don't want it.. accept it or move on. They gave a reason. If you think it's sufficient is another thing and mostly about opinion.

>perhaps your feature request wasn’t deemed to be thought out enough?

Why the automatic defense of the Haxe team? Frankly, small communities like this sometimes come across as cult-like in their response to criticism, and it isn't a good look.

Here's the proposal in question: https://github.com/HaxeFoundation/haxe-evolution/pull/51

Here's the process which wasn't followed: https://github.com/HaxeFoundation/haxe-evolution. Very little discussion, no public vote, even though the proposer put in the effort and clearly wanted to engage.

When someone puts in the effort to make a proposal like this, this bait and switch is not a way to keep them around, and insulting them in HN comments isn't any better.

Where’s the insult? I can’t speak for the community or who did what. If anything I’m looking to see what can be done going forward.

To quote you again:

>perhaps your feature request wasn’t deemed to be thought out enough?

Why jump to finding fault with the OP, rather than accepting feedback about the process? AFAICT you didn't actually check OP's proposal before assuming it was lacking. And OP's experience isn't unique.

You're evangelizing Haxe in this thread, but here you just paper over valid criticism:

- "arrow functions are slated for the next major release": sure, it only took four years!

- "I also think most languages’ directions are decided by committee in a similar way": I'm not aware of any other language that has a proposal process inviting community participation, but doesn't follow it and discusses those proposals in private. Point me to one. Surely you can understand that this can be frustrating when someone tries to participate and is shut out.

- "I’m sure the Haxe community would love to see examples..."

I would be pleasantly surprised if I saw the Haxe Foundation engage in some introspection and actually take steps to change or at least be more transparent. So far I don't see any introspection, only defensiveness.

And FWIW, I used to be part of that internal Slack channel for team members and was a Haxe contributor. I tried to make progress on these issues for years before giving up.

I’m sorry if I’ve come off defensive or as finding fault. I’m not trying to defend the action, merely trying to gauge the entire situation. There’s reason for why I used the word perhaps and asked for more info. If the process is as bad as it is from what you and others are saying, I’d love to hear more about the efforts made to fix the process and details on where/ why you think they didn’t pan out? Is it a problem with the leadership? Something else?

I do evangelize the language and have not myself run into these issues as of yet. If they do exist my hope is also to have them resolved, not to justify them away and keep the status quo.

Reply on news.ycombinator.com