jonlachlan

As advertised, you can roll your own.

> "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?

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

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.

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

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.

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.

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.

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

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

I read it about a month ago, but these are thoughts that have been ruminating in my head for the past few weeks. I have struggled to explain the benefits of Meteor to others, they always try to compare it to React, Angular, Knockout, Node, Express. It's hard to get people to understand that it's a full-stack platform whose purpose is to make programming easier and faster. http://meteor.com/about

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.

I don't understand this comparison. Meteor makes things simpler and removes a lot of low-level complexity. It makes software development simpler. By "some people want Windows", it sounds like you're suggesting that there's a better platform/framework for web development that's "plug-and-play" ready -- so easy that a non-developer could use it. I actually think that Meteor is the closest thing to this, and is the very best starting point for new developers. To this thread's question, it's also great for large applications. But at the end of the day, it's still web development -- you need to learn JavaScript, Mongo, html, CSS.

Been using Meteor for 4 months, and I'm an junior ops guy turned developer. So if I say something that sounds like I don't know what I'm talking about, it's probably because I don't, so take it easy. Having said that, here's my two cents: First and foremost, Meteor is a complete platform for building modern web applications. You get so much out-of-the box functionality that you'll be productive in no time. Also, you will find that your codebase is several times smaller than with other frameworks, because the isomorphic javascript saves you from needing to do a lot of boilerplate and configuration. You also have very convenient ways to organize code, whether through packages or in a /client or /server or /cordova folder, so you'll have an easier time managing your code. So a "big" application is smaller than it would be, and makes for more understandable code.

There are many, many examples of functionality that you get for "free" without further set-up, and in my experience it empowers you, the developer, to build richer, better applications.

I think that the fact that the platform is stable and past 1.0, and the package ecosystem at atmospherejs.com is vibrant and high-quality, the answer is yes you can absolutely build an application with a large code-base. (And, I might add, you may wonder why you ever did it another way.) As for scaling, you're on a non-blocking node architecture, and so you're already doing pretty well. If you can't figure out how to scale it through the community, my understanding is that the folks at Meteor are working on a paid product that will make it dead-simple to scale to your heart's content. I am guessing that by the time you launch your Meteor-built product, there will be ample resources to hold your hand through it.