| > You do the promise-as-a-pyramid example, then say you still have to nest and leave it at that, misrepresentation if not malice. Basically, you have a solution through promises you're not showing either because you were unaware or because you chose to, I _hope_ it's the former. Not all promises libraries support `call`. This isn't an article about the differences between particular promises libraries and the cooler features of some of the fancier ones. It's about returning proxy interfaces to seamlessly chain asynchronous operations. If I were writing a critique of bluebird and left out `call`, then you would be right to accuse me of ignorance and/or malice. > and your proxy queues don't make sense for someone who understand promises. Proxy queues aren't for someone who understands promises. The point of the proposed framework technique is to negate the need for the end user to understand promises, by simplifying the interface as much as possible. It's about making things more accessible for beginners and hobbyists. > I only used that because that's the library you used in the question. With bluebird it would have been significantly nicer. No doubt, but it's not an article about bluebird. It's an article about creating frameworks which hide their complexity from the end user by using some interesting techniques. > Your technique added an _extra layer_ on top of an _existing layer_ that already _solves the problem you're solving_. Promises were designed to be callback queues from the 80s by Barbara Liskov and Mark Miller. Reinventing the core concepts is insanely cool but it does a big disservice to the existing tooling. I'm under no moral obligation to provide any service to existing tooling. You seem to have that front covered nicely enough. My goal is is to prompt people to think creatively about their libraries and how their users interact with them. A lot of people use technology these days to enhance their main profession, and making the code more accessible to them is not a disservice. > I think it conflates promises with values, The point is to allow the user to use asynchronous responses as if they're normal values. Promises can be used as a powerful building block to this end, but not the end itself. > I apologize for this, totally my bad. Is there anything you made that I'd recognise from JS land? http://mootools.net/developers Why not just be respectful of other developers, though? It's a creative profession, and not everyone will write their code in the exact same way that you would write your code. > I don't want to turn this into a pissing contest but I'm pretty sure I understand promises, proxies and all that. I'm pretty sure you understand those things as well. Good for you. Perhaps my article is different than the article that you would have written because we don't share the same opinions, backgrounds, goals, or operating principles. > I apologize for the tone in the original comment (I'll edit it if you'd like) it was uncalled for but I really think there is a lot to improve in the article. I also agree there's a lot to be improved in the article, but it's a rather complex topic and I wanted to target the widest audience possible. However, an in-depth discussion of how developers who are intimately familiar with promises write their code when utilizing their own frameworks would not be one of my improvements, as it has nothing to do the topic I set out to tackle. What is your goal here, exactly? Should I send a letter to the Code Words editors begging them to retract my article? Would you like to publish a replacement? Do you want me to refrain from producing any work in the future, lest it fail to meet your lofty expectations? If there's a viewpoint that you'd like to get across that's not contained in my article, by all means, write your own. Don't just go around telling other people their work is shit because it's not what you would write yourself, or because you wouldn't need to use it yourself. This went through several rounds of technical review, and took quite a lot of work from many different people. There's no community benefit to discouraging alternative viewpoints, and considering the article's title isn't How Ingor Writes JavaScript, I don't feel particularly bad for not explaining that particular nuance of the topic. |
As I said twice before, the `call` bit is irrelevant, I used it because you used Q in the article. It would have worked with bluebird or When just as well - library is really not the big deal here. It's promises as they were designed.
> Proxy queues aren't for someone who understands promises.
You might want to mention that in the article. Or at least not represent them as a solution to a non-existing problem.
> I'm under no moral obligation to provide any service to existing tooling. You seem to have that front covered nicely enough.
Of course you're not, you can write incorrect statements about existing tooling all day long. However, do expect people to call you out on it when you misrepresent tooling, and do expect other people that agree to upvote those comments.
> Why not just be respectful of other developers, though?
Not once did I disrespect you, your code however in the promises example was very misrepresentative and frankly I stand by calling it terrible. It seems like that was intentional to show a point but it's still true.
> Perhaps my article is different than the article that you would have written because we don't share the same opinions, backgrounds, goals, or operating principles.
Of course, we don't have to agree on everything! However I do get to post my opinion about your article when you publish it (as I did above).
> What is your goal here, exactly? Should I send a letter to the Code Words editors begging them to retract my article? Would you like to publish a replacement? Do you want me to refrain from producing any work in the future, lest it fail to meet your lofty expectations?
My goal in the comment was to make sure people who reach your article through Hacker News realize that the way you use promises is not representative of how one would actually use promises in their code nor that the problem you're "solving" doesn't necessarily need that solution.
It would have been entirely possible to show that solution without misrepresenting solutions with promises or other concurrency mechanisms. Moreover, it would have been possible to implement in a much simpler wrapper function way (like the link to the API.md file in bluebird above).
> If there's a viewpoint that you'd like to get across that's not contained in my article, by all means, write your own. Don't just go around telling other people their work is shit because it's not what you would write yourself....
Well, if you don't want criticism on things you publish - don't put them on the internet. I don't have an obligation to be particularly nice - especially when I have what I believe is valid criticism.
If you publish something and make it accessible to the public - be sure people are going to respond to it, especially if you make mistakes in the content. You asked why I don't write my own? The above comment is me writing a response to your article on the discussion about it so basically I'm already doing what you're suggesting :)
By the way, I still warmly recommend http://dl.acm.org/citation.cfm?id=54016 and http://www.erights.org/talks/thesis/markm-thesis.pdf the reason libraries like Q have these functions like `call` in the first place is exactly in order to use them as proxies :D
Anyway, I'm heading out - thanks for the discussion and happy coding :)