msteigerwalt

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.

The promise usage here is so terrible it's not even funny.

Unnecessary hyperbole aside, I think you're confusing two conflicting goals. One is to provide code examples in order to explain a particular concept to an audience not already familiar with that concept, by building upon examples previously explained in the article. Another is to explain how to write production code using existing promises frameworks.

For the purposes of explanation, I used a similar code flow as the standard callback example previously described, except that I included the chaining of error handling with parallels to synchronous try/catch/finally flows.

The promises excerpt you've derided is an example of what promises bring to the table over straight callbacks for simplifying complex chains of asynchronous operations, not an example of how to use promises in production code.

Additionally, this is an article about framework design, not how to use them, making your corrections (which involve using a framework with chainable proxy queues) somewhat tangental to the discussion.

var users = connection.call('collection', 'users');

You seem to have the generic concept of a promise confused with a particular promises implementation with some extensions that you particularly like.

Not all promises libraries support `call`, and many don't support the return of the expected proxy interface from another proxy interface, which is the very technique described in the article.

The Promises/A[0] specification barely touches upon the subject and specifies that call "returns a promise to provide the return value of the requested function call," not a chainable proxy to the expected return interface. Even the Promises/A+[1] spec seems to ignore the subject of `call` entirely.

it's hard to take a criticism on a model seriously where the OP doesn't understand the model.

This isn't a criticism of the model, it's an explanation of the model and some suggested extensions.

Considering I clearly stated both in the intro and the conclusion, "This approach builds on promises and standard callbacks" and, "The great thing about this technique is that it can compose really well with existing promise frameworks," I'm really curious as to how you managed to miss that point.

To demonstrate, here's a simple diff of your "correct" example enhanced using my proposed technique:

https://gist.github.com/Yuffster/4ca84f31cfaef33c4138/revisi...

I think we can both agree that, to a developer not possessing your level of skill, the revised example is slightly easier to follow.

It's awesome that it's a post by someone who just attended the recourse [sic] center and they're a new programmer and already struggling with these interesting issues and trying to solve them

Thank you very much for the encouraging words, but in the future, could you do everyone a favor and either read an author's biography or click on the author link before making wild assumptions about his or her programming background?

The context might make it easier for you to understand the article itself, making your comments far more valuable.

---

[0] http://wiki.commonjs.org/wiki/Promises/A

[1] https://promisesaplus.com/

Interesting idea, but wouldn't the devise register a false hit if the sword hits an obstacle in the environment?

Seems like you're playing a few roles, but the chief ones would probably be:

Product Manager: You take business goals and turn them into technical requirements, then ensure the product gets built.

Project Manager: You take technical requirements and ensure that your team delivers on those requirements.

User Experience Designer: You create mockups for products which can be implemented by the technical team.

I'd put together a portfolio of your work and send it off to a few companies, as that might be good enough to land you a job.

Interesting, but I find the user experience breaks down rather quickly when I try to find out how much I could expect to pay if I moved a webapp to Jelastic. Annoying considering "True Cloud Pricing" is one of the headline features.

The "Pricing" link leads to an FAQ with 16 questions on pricing, each of which have to be expanded individually and none of which answer the question, "How much does it cost?"

The best answer tells me to click on my hosting provider, which is confusing, since I don't have a hosting provider; I haven't signed up for service. When I click on a random one, I get a dumped into the middle of some corporate knowledge base's 500-word article which then has to be scanned for plain text pricing information hidden within it. I'd then have to go make my own spreadsheet and plug in the numbers.

For reference, compare to Heroku's pricing page: http://heroku.com/pricing

Or AWS: http://calculator.s3.amazonaws.com/calc5.html

It'd be more interesting to allow some sort of optional rating system which feeds into something like a gaming matchmaking system. People who consistently send out good reviews will get a rank of "A", for example, and be matched to others with similar rankings.

That way, even low-quality posts ("i liek that u have a logo") can be accounted for, without treating them like spam. As the reviewer becomes better at reviewing, they will see an increase in their ranking and better reviews.

I've worked with managers who could successfully drink with employees as well as fire under performers (often in a way which didn't end the beer relationship), but all of them had multiple decades of experience.

I suppose it's much, much easier to avoid the need for a line entirely than to learn how to draw it.

From my experience, "most" of those JavaScript developers who "hate JavaScript" are in fact front-end developers who hate writing JavaScript for websites, since they struggle daily with issues such as cross-browser compatibility and inconsistent DOM implementations, which have nothing to do with JavaScript at all, and can't be fixed by a different syntax.

It's also compounded because the majority of front-end developers write their code procedurally for each application component, which creates a terrible nest of repetitive and error-prone code.

They feel the pain, don't know how to solve it, so switch to a different syntax, blaming that as the root cause of the problem.

But feeling enough pain to viscerally HATE a language, as many front-end developers do, is not something that can simply come from the syntax of the language and the fact that the equality operator does type conversion and whatever small list of gripes users have. Most other languages (including CoffeeScript!) have a similarly-sized set of flaws and aren't nearly as derided.

"Regarding privacy, promoters say the video isn’t clear and isn’t recorded, so it’s not archived."

I wish people would realize that everything on the Internet can be subject to unexpected storage. The fact that they're not recording doesn't mean it's not being recorded.

Makes sense. How many of the plugins sites try to install are actually useful?

I wonder if Google will whitelist the page once this comes to their attention.

The product rep in those videos is brilliant.

You'd probably be better off adding a little bit of equity to the offer.

Easiest way is to just ask really simple technical questions in the submission area as a captcha.

Not sure which technical questions would be 100% answerable to everyone around here, but it is Hacker News.

PHP makes it possible for people to use it poorly, yes. Blame bad developers, not the language that lets them write bad code.

If I want to write a widget that a majority of designers can easily plug into their own sites, I write it in PHP, because it's portable.

Maybe that makes me an amateur, but sometimes I can't just code in the pretty, pure languages all day.

If by access to a professor, you mean someone who knows the material extremely well and can help you with questions or steer you in the right direction, you can get that for free from IRC.

I've been leeching off my friends' college educations for years, and although I'd agree that it would be impossible to learn some things (like advanced programming topics) strictly from books, someone who knows the material and exactly how to explain things to me is just as good as a traditional instructor.

It's also better training for the real world, where I don't have time to take a course on everything I need to know.

I like how the article suggests that the cost of developing a viral Facebook application is $200 for outsourcing to India.

I agree with the premise of the article, though. Except for the $400,000 price tag. Where does that come from?

I was a little worried about Bowie's performance of Tesla before I saw the movie. In the end, however, I was very pleased.

I'm just hoping Battlestar Galactica's last season can be salvaged. I'd hate to see it mucked up forever by something so temporary as a writer's strike.

That's quite possibly the greatest thing I've ever seen.

Does anyone else just get a Mephisto login prompt?

Can I have an account please, Eric? :D

This might be better titled as Frameworks vs. Languages. Of course, since most people writing modular code will end up making a framework for their application, it's really Shelf Frameworks vs. In-House Frameworks.

Of course, there's also a third option, niche open source frameworks (every PHP developer and their dog has a PHP framework, and not all of them suck). Chances are, if you look hard enough, you'll be able to find an OSS framework in the language you need that would be fairly similar to one you'd make yourself. If the code is well designed, you can simply cut out what you don't need and add what you do.

Exactly. This is something a user of Google Toolbar might have cause to gripe about (assuming they weren't told in advance), but not someone who owns a website with 404s that get redirected.

However, for people who like to put sensitive user data in GET variables (coughMonstercough), this is yet another reason why they shouldn't do that.

I attempted to delete my Facebook account over the last week and it has been a grueling experience. I tried to change my name to "Delete Me", but that name is on the list of names you're not allowed to change your name to.

I've had to go directly to Facebook "customer support". I was asked what email address I used to create my account. I answered with the email that I was using. I was then told that I couldn't have my account deleted because I needed to respond from one of the email addresses associated with my account. Yet, presumably they had some way to confirm the security question they gave me, regarding the address I used to set up the account. Doesn't that mean that the sign-up email is associated with the account? (Sorry to be repetitive here; it makes me dizzy, too.)

I'm slightly concerned that the reason they won't delete my data is that they've already sold it to Satan.

All I know is that OSX users without a Linux background do not find "sudo rm -rf /" jokes funny...