willyg302

Python (must have). And then Ruby, Lua, R, Go, and C# in no particular order (just suggestions).

R would be huge for statistical computing, which Lambda holds a lot of potential for -- research would never be the same. Lua would be fitting/appealing just because of its speed and small runtime. The others seem to hold relatively happy spots on TIOBE and in Stack Overflow tags and would fit the Lambda model well.

Very good point! Thanks for catching that.

It would be harder in the long run if Lambda decides to support more languages than JS, as the parsing would have to be done on a per-language basis. But anyway, I have created an issue for it. In the meantime you can still use lfm with single files, but you will have to provide all the config via the command line (on the plus side, lfm has shorter CLI options and you get zipping for free!).

> Navigation meshes, visibility graphs, and hierarchical approaches are all worth a look.

Navigation meshes in particular are worth consideration. There is a great reference here [1] from Epic Games about navigation meshes, and why they made the switch from a traditional node-based graph to them for the Unreal Engine. Although for most simple cases, a graph is much easier to conceptualize and implement.

[1] https://udn.epicgames.com/Three/NavigationMeshReference.html

> Frankly, copy/paste is a superior code reuse mechanism at this scale.

The one advantage I see to having borderline-ridiculous packages such as this is that they do One Thing Well [1]. Yes you may copy/paste an isObject() function or roll your own, but then it becomes your responsibility to make sure it works for your project, and arguably far fewer eyes on it when it doesn't. As long as the project's maintainer is dedicated to making this the best way to determine whether a variable is an object, I have no problem using it.

Although, I do find the 57 commits irksome. Most of them are just upgrading dependencies (code style checkers, etc.), "fixing" indentation, and in one case 7 separate tweet-sized diffs to the README on the same day, as if this guy has git commit/push bound to Ctrl+S in his editor.

[1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html

Related: this game grew out of Seth Cooper's PhD dissertation [1] "A Framework for Scientific Discovery through Video Games", which won the ACM Dissertation Award in 2011. Although a lot of the content is Foldit-centric (protein algorithms, etc.), it still has a wealth of information on game design and gamification, well worth looking at for anyone interested in game development.

[1] http://grail.cs.washington.edu/theses/Cooper2011PhD.pdf

I like this idea, but no, clip is about as simple as you can get. Direct greedy parsing one token at a time.

It seems like you could get something like your examples by doing option aliases, so typing "complete" or "metadata" would be parsed as `-l`. However even something this simple starts to complicate parsing quite a bit (e.g. where are the option boundaries?) especially if you allow multiple tokens in an alias, like "with all" --> `-a`.

And at the end of the day, it just helps to learn through repetition. I have no idea what the "plant" means in `netstat -plant`, but I know it generates the output I want. Similarly it's much easier to type `ls -latr` than "ls complete all sort oldest first".

Additionally, this will log all the passed arguments (value, index, and array being traversed), which typically isn't what you want:

    [1, 2, 3].forEach(console.log.bind(console));
    > 1 0 [1, 2, 3]
    > 2 1 [1, 2, 3]
    > 3 2 [1, 2, 3]

> complex parseable options, something that could only be parsed by a parser generator

Could you elaborate on this? Do you mean user input more like natural language? I've seen a few attempts at this such as betty [1], but the reality of it is the input must still be translated into something the CLI understands, and as you might imagine it becomes difficult for more obscure options.

1. https://github.com/pickhardt/betty

shkeleton looks pretty neat too! Amazing that it's 100% bash, as someone who shies away from bash scripting for all but the simplest scripts I can't imagine recreating argparse in it :)

Well, my definition of "embeddable" is a very loose one. All you really need to be able to do is allow the user to specify in/out/err streams, so that they could be anything: a log file, a socket, a Python function, etc. So maybe keep a var for each of these and redirect the echos to them?

You raise a fair point. The only reason I encheferized the readme example was to have a little fun with it, as one of its goals is to demonstrate help screens...but that ends up making the code look like a wall of text no matter what "language" the messages are in.

Anyway, once I think of a better example I'll swap it in. Thanks for your input!

Using Lambda for the slaves is probably not the best idea because, as @saynay mentioned, you couldn't run builds any longer than a few minutes.

You could "wrap" a Jenkins fleet running on EC2 with Lambda functions to set up on a build request event and tear down on a build finish event, and theoretically this would reduce the amount of resources you consume if your builds are few and far between. Think of GitHub webhooks triggering Travis CI as an analogy.

Whether or not that would actually be useful is debatable.

As a tldr, not-quite-right distinction, GAE is more of a platform whereas Lambda is more of a service.

I feel that GAE is a much more generalized solution for building/deploying applications, e.g. it's very integrated with BigTable and has caching/cron/queuing support. To a point you do not have to worry about the infrastructure, but write any GAE app at scale and soon you'll run into questions of caching some content and optimizing DB writes.

Whereas Lambda, at least right now, is a more specific use case: respond to an event by running some code. It's too early to tell whether managing Lambda functions will require fine-tuning the "advanced settings" (in all honesty it probably will) but it seems like it's much simpler.

Lambda function, not lambda function. Capitalization is key (the former is just a brand name).

Having reductions and composition would be really cool, but from what I could glean from the demos each function is containerized. Stateless and idempotent like lambda functions, but right now chaining more than one together requires an intermediary event.

Not exactly revolutionary per se, it's an idea that's been around at least as long as shells, and as mentioned in the keynote it's a natural level of abstraction above AWS APIs. The neat part is how this simple idea has been translated to applications at scale.

IMO what's really going to be revolutionary is what we end up doing with it, but we're going to have to wait a bit to find that out :)

It is completely possible. Consider that the major uses for a server are interacting with clients, storing data (backend database) and manipulating that data. Here the clients can interact directly with S3/Dynamo, this in turn will trigger Lambda functions to manipulate data, and the round trip can be accomplished via SNS.

Of course, it would be much more viable to have some sort of server running (for example I doubt Netflix has replaced their entire backend with Lambda functions), but a great majority of workflows dealing with stateless data manipulation and events can now be streamlined and even replaced.