Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Joy of Haxe

medium.com

Post reply on HN
Print view View original

81–90 of 91 posts

Re: The Joy of Haxe

#81

Post by dyarosla »

bendmorris wrote: post #79
dyarosla wrote: post #75

Earlier quoted context omitted.

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 nex…

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.

Re: The Joy of Haxe

#82

Post by dyarosla »

bendmorris wrote: post #80
dyarosla wrote: post #70

Earlier quoted context omitted.

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?

Re: The Joy of Haxe

#83

Post by Lerc »

dyarosla wrote: post #82
bendmorris wrote: post #80

Earlier quoted context omitted.

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

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.

Re: The Joy of Haxe

#84

Post by dyarosla »

Lerc wrote: post #83
dyarosla wrote: post #82

Earlier quoted context omitted.

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

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!

Re: The Joy of Haxe

#85

Post by Lerc »

dyarosla wrote: post #84
Lerc wrote: post #83

Earlier quoted context omitted.

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…

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?

Re: The Joy of Haxe

#86

Post by ncannasse »

bendmorris wrote: post #49
Lerc wrote: post #30

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 prop…

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 o…

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.

Re: The Joy of Haxe

#87

Post by dyarosla »

Lerc wrote: post #85
dyarosla wrote: post #84

Earlier quoted context omitted.

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…

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://githu…

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.

Re: The Joy of Haxe

#88

Post by bendmorris »

ncannasse wrote: post #86
bendmorris wrote: post #49

Earlier quoted context omitted.

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 o…

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…

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.

Re: The Joy of Haxe

#89

Post by damoebius »

giancarlostoro wrote: post #40

I want to love Haxe but tooling outside of Windows seems limited, although I havent looked at how good VS Code is with it yet, so maybe I'll look into that. Otherwise I am going to stick to D and Python.

IntelliJ plugin is also pretty amazing.

Re: The Joy of Haxe

#90

Post by ncannasse »

mlthoughts2018 wrote: post #78
jdonaldson wrote: post #55

Earlier quoted context omitted.

I'm shuddering over the thought of porting and maintaining the scala and js code. Are you using Scala.js?

Scala has many problems as well, but I’d say at least two orders of magnitude fewer than what we encountered in haxe. Scala was chosen for various business compromise reasons, not any particular preference for Scala.

That would surely help if you could tell us what Haxe specific problems you had.
Post reply on HN