> "Everything is ease-of-use optimized, to the point that you can query Mongo via the browser console."

meteor remove autopublish

meteor remove insecure

The Mongo-accessible frontent is genius. This makes your prototyping much faster, and you can totally skip the "model" layer of your frontend. It matches your backend automatically. No further configuration needed. No REST endpoints, no callbacks. And yes, it's secure.

Meteor's security model is very well-designed. The list of things left for the developer to do, security-wise, is very short.

It's still important to learn your tools and understand how security works.

http://docs.meteor.com/

http://security-resources.meteor.com/

https://github.com/themeteorchef/security-essentials

https://www.youtube.com/watch?v=6_3pomxyp8M

This makes sense. But would you say that there could be easier shorthand descriptors to supplement the terms? Or perhaps terms that are used to describe the utility of currying, but don't actually replace the specific (and useful) term?

I think it's fair to say that pithy ways of explaining the point and mechanism of currying are important. The terms you've been exploring here are definitely in that bucket.

Your path will be your own, but here's what has helped me:

Try Meteor (meteor.com). That way you start from a complete development environment, and you can focus on actually using JavaScript, as well as feel good about being productive. Bring in new libraries to play with using atmospherejs.com. Try to think of a small website that you can build (a todo list, a checkbook balance sheet, a notetaking app), so that you can have real problems to wrestle with and a real goal to strive for.

Use Meetup.com or other community groups to find other people to talk with. Be honest about where you are at ("I'm a total beginner"), ask people about what they're working on, be nice and apologize for not knowing much. Be confident about your ability to learn. Talk about what you're doing. ("I'm working on a small pet project so I can learn"). Go into detail if you can.

Be patient. Be persistent. Also practical. The JavaScript world is vast, you can't know about everything. Ask yourself, do I need to know about this cool library/technology right now, or should I spend my time doing something else, like actual coding? Think about the bikeshedding problem, i.e. "shipping" (finishing your project) is better than bikeshedding (https://en.wikipedia.org/wiki/Parkinson%27s_law_of_trivialit...)

Read an authorative book on JavaScript (e.g., JavaScript: the good parts). There's no substitute. No website or blog article will get you familiar with the "deeper" concepts of the language. Don't worry if you don't remember everything, just try to understand each of the concepts and then plan on re-reading it again 6 months from now. Plan on reading more than one of these books.

Have fun!

Again, your description refers to "partial application", which is different from currying. I think that many people are comfortable with "currying" only because they think it's the same as partial application. The fact that this is incorrect is good reason to revisit the term.

> I think that many people are comfortable with "currying" only because they think it's the same as partial application.

If currying was the same as partial application, I'd say we don't need the name "currying" and can just use "partial application". So I guess you could say that I am comfortable with currying only because I don't think it is the same as partial application.

Good point. It's a bit of a wonder why so many people think of them as equivalent (perhaps they thought currying was a convenient shorthand for partial application). I'm comfortable with a simple campaign to clarify the difference, and I think my suggested terms would be helpful to accomplish that (so rather than replacements, simply informal descriptions of the term).

From the perspective of a non-functional language, it is argument deferral because you're composing your sequence of functions first, which can then be used by later adding inputs for evaluation.

Were you thinking of partial application (not the same as currying)? I would agree that this is not argument deferral, rather it's more like argument presetting.

No, I was thinking about what I said: evaluation order and evaluation method.

For instance, if I had a function like

    func(a,b)

with the semantics that a would be evaluated before b, it would be perfectly reasonable to allow someone to evaluate argument b first instead. Thus 'argument deferral': you defer the evaluation of a until after b.

The second case is about when the arguments are evaluated: do you evaluate them when the function is called, or do you defer evaluation until when they are used? This is obviously 'argument deferral' as well, but we usually call it lazy evaluation.

http://en.wikipedia.org/wiki/Evaluation_strategy

The term 'Argument deferral' could apply perfectly well to a discussion of Evaluation Strategy, even though that has little to do with currying.

"Argument deferral" of the type you describe (like partial application, for that matter) is something currying can be used to achieve, but is not what currying is.

So, even if it was proposed when "currying" wasn't well established as the name for currying, it wouldn't be a particularly good choice.

I agree, I've revisited my position. Argument deferral and partial application (my term: argument presetting) is something that currying can achieve, but it's not what currying is.

Thanks for this clarification. The fact that these are widely confounded is evidence that many people are comfortable with the term "currying" only because they think it's the same as "partial application", so they appreciate the connotation that you're "adding spice".

So in this case, not only CAN these people stop calling it "currying", but in fact they should, because it's the wrong word.

In my other comment I'm suggesting calling currying "sequencing", and partial application "presetting".

Your description refers to "partial application", which is different from currying. I think that many people are comfortable with "currying" only because they think it's the same as partial application. The fact that this is incorrect is good reason to revisit the term.

See my longer comment. I'm suggesting "sequencing" and the opposite, "bundling".

Thanks everyone for the comments. It is interesting to see how widely "currying" is conflated with "partial application". I have to say, I still find the name to be a stumbling block. Perhaps this discussion can help to reverse that trend.

I have also learned a good deal more from these comments and further research. It seems my idea of "currying" was not entirely complete. Per the comment herein: "Currying turns polyadic function into a sequence of unary functions". Practically speaking, this means a curried function is a single-input function that will return a function which is still awaiting an argument, so that other functions can be added to the "currying chain".

I would call this "function sequencing". This term could be equally intuitive for functional languages (ML / Haskell) and non-functional languages alike. However, I think that non-functional language users will still appreciate an explanation that references "argument deferral", since this is one of the practical benefits, and is also the key part of the "functional" context-switch needed to understand the concept (i.e., you can compose functions without providing the arguments/inputs).

Is there an equivalent to "uncurrying"? (un-what-ing??) This verbiage sounds like we're trying to unpluck a chicken. On Wikipedia (the world's collective brain dump), we understand uncurrying to be "the dual transformation to currying, and can be seen as a form of defunctionalization." Crystal. I'll losely interpret this as flattening the unary (single-input) function sequence into one polyadic (multi-input) function. So can we refer to this as "function bundling"?

To summarize, I'm submitting "sequencing" and "bundling" as the two simple verbs that better describe "currying" and "uncurrying".

> To summarize, I'm submitting "sequencing" and "bundling" as the two simple verbs that better describe "currying" and "uncurrying".

"Currying" and "uncurrying" are widely understood by programmers, and "sequencing" and "bundling" are often used in programming for other things, so your idea reduces clarity in favor of some aesthetic preference to avoid turning proper names into verbs when creating new technical terms.

So, I think we're better off just sticking with currying and uncurrying.

Good thoughts. I'm interested to see if there are other opinions.

As a related extension, though I don't think "partial application" is a bad term, I can also think of it as "presetting arguments", so there you go, my last submission is to call this "presetting".

You can weigh the trade-off between needing to configure your environment with what Meteor gives you. I would say Meteor has a value proposition that's definitely worth looking at. The list of things it helps you with is more than most other frameworks, and at the same time it's modular so you can swap in components that are better for your use-case. You also have the benefit of still being in the JavaScript/NPM ecosystem, which is easy to take advantage of.