BringTheTanks's comments

> realistically a proprietary standard library – however huge – just can't compete with the open source ecosystems of Python and friends.

It's not competing with Python, it's language as a service. Instead of downloading dependencies, you just have them. They're hooked to live data sources, zero configuration.

This has a lot of potential, and it doesn't need to be its own language, but it doesn't hurt much.

"Imagine you've implemented world peace. Now let's try to drop couple of nukes in the middle of this..."

Anyway, the point of functional programming is to have as many "immovable parts" as possible, because mutation stands in for parts in motion. And everyone in engineering knows parts that move are usually the first point of failure.

You might need a moving part here or there in a usable design eventually (not always) but you should do you darn best to have them isolated and as few as possible.

Well, there are non-ironic alternatives:

    declare(strict_typehints=TRUE); // not ironic, not short
    declare(strict_types=1); // ironic, short
    declare(strict=true); // not ironic, even shorter

JS has one strict mode, this could've been an opportunity to introduce an umbrella mode for strict coding in general.

Also the declare syntax could've been augmented to support passing implicit boolean parameters without setting a value:

    declare(strict); // oh yeah.

So... you know. Not that it matters what you call it, but choosing ugly (and ironic) over pretty (and sane) shouldn't be taken so lightly.

I'm curious, is there a reason to avoid using .NET for web services deployed on *nix?

I'm interested in using it, I love .NET as a platform, I just have this vague sense of worry that I can't quite rationalize. Mostly based on Microsoft's past performance with cross-platform efforts.

Thoughts? Is my gut feeling right or wrong?

With RoR it's pretty much in the description. Monolithic web apps with relatively standard and simple domain logic (i.e. CRUD). Lots of presentation code (HTML templates, handling of static assets and what not).

Go is for writing small, focused, paralellizable and likely distributed services. If I wanted to crunch data, I'd try Go.

I'd expect, say, a RoR app to connect to a Go service for some of its heavier domain logic. I'd neither write a RoR-type app in Go, nor a Go-type service in RoR.

This is not a change in Apple's policies, it's a fluke. The reviewer is interpreting the rule incorrectly.

The rule is intended to avoid descriptions which refer to future plans for alternative platform support, or different ports of the app available on other platforms. The rule does not intend to withhold information on platform support for this app instance, or ban said platform support.

For example:

- "Also find our app on the Pebble Watch Store" (violation)

- "This app syncs with Pebble Smartwatch" (not violation)

Other examples:

- "This feature is only available on our Windows Phone version of Office" (violation)

- "We're moving to the Google Play store for Android" (violation)

- "This app allows you to share files on all popular mobile platforms" (not violation)

- "Tap together your iPhone to another iPhone, Android phone or WM phone to share contact info" (not violation)

My guess is Apple will be reversing decision on that rejection soon.

Odd. RoR and Go address entirely different app domains.

The only thing that connects them is that RoR was trendy yesterday, and Go is trendy today.

If this is the rationale for replacement, the author will be writing plenty of "replacing" articles in the years forward.

One'd hope that the "values of modern society" have enough capacity to accommodate both ambition and relationships.

Painting ambition in negative tone and putting too much focus on relationships causes the same myopia that focusing only on ambition does.

It's never just one thing that matters.

Thanks, this was informative :)

What's your opinion on "popular frameworks".

> Well human have higher moral value because of higher ability of pain, emotions and cognition.

Those are arbitrary categories. Let's say I decide you have lower ability to feel pain, emote and have inferior cognition.

How exactly do you prove me wrong. By grimacing a lot when I cause you pain? Well animals absolutely clearly demonstrate they hate pain, too. Yet, here we are discussing your opinion to the contrary.

Truth is... they don't speak, so we can speak for them whatever is convenient for us.

You have a somewhat naive view about how our moral compass moves as a straight lines from bad to good.

Before the Nazis performed experiments on humans, it was considered horrible to perform experiments on humans.

What Nazis had that allowed them to perform experiments on humans was a carte blanche to do whatever they want by contemporary law, and the ideology that those human beings were in fact "inferior" human beings.

I don't know if you eat fish, chicken and so on, but probably you don't think of yourself as a Nazi if you would. Because you don't consider a chicken at the same level as a human. And this gives you carte blanche to have chicken for dinner and feel absolutely no remorse.

Is it right or wrong? I don't pass judgment. I know all beings have a sense of self and we shouldn't cause pain and take a life for no reason, yet, killing each other and eating each other is part of the cycle of life.

I know that if we consider life sacrosanct and we eat chicken fingers at Chipotle, we need ideology to justify our actions, and so we'll consider animals inferior. If we consider them inferior, they'll be target for experiments, because medical science will continue to evolve.

Depending on how our culture evolves, the moral compass may move in an entirely different direction, where we stop regarding life of any kind as so precious, even human. We'll acknowledge how replaceable we are, and our mortality. This would enable full legalization of humane practices like assisted death for the heavily disabled and terminally ill, and might open the doors again for experimenting on humans to move medicine forward.

You never know.

The statelessness relates to communication state. A client can hold state and it most certainly will hold state (consider your browser: open tabs with URLs, bookmarks, local browser cache; form autocompletion; settings; all of this is "state").

Instead, REST talks about a request being stateless and a response being stateless (i.e. sufficient on its own and not dependent on preceding or future communication between that client and server).

This is, again, done for the benefit of intermediaries, because intermediaries should not be forced to hold state in order to interpret REST communication. Every request, response should be sufficient on its own to be understood.

I'm afraid we're not in a dramatic agreement. You point to an exception which REST allows to claim the exception is RESTful.

The exception is there for practical reasons and it doesn't satisfy REST's constraints nor benefits from REST's properties.

Either way, my point's been exhausted, so, I'll shut up now ;)

I know which phrase you're referring to, but if you read it in context, it's apparent this is an exception case, because the very same section talks about cacheable, stateless requests and responses.

All of REST's constraints are about encouraging cacheability and "visibility" to intermediaries. Intermediaries should in most cases be able to see which resource is being requested/returned, read the method, read the content-type and other headers.

All of this is not available during an HTTPS session. So "HTTP + a bit of HTTPs" is REST + a dose of realism.

But "HTTPs-only" is something else entirely.

My premise is that HTTPs-only and REST have opposing constraints.

You have not demonstrated any flaws in it, REST says communication is stateless and cacheable except for acknowledging some select minority cases when it's not the case.

Turning the minority cases into the only way of communication nullifies most of the benefits of REST, because the whole rationale of the paper is lost. I.e. intelligent shared processing and caching by intermediaries.

I'm taking no stance on what "the reality is". I'm taking no side about which side is more correct. I'm stating what both sides want, and finding it curious they don't see the contradiction.

Let's quote from section 5.2.2:

"All REST interactions are stateless. That is, each request contains all of the information necessary for a connector to understand the request, independent of any requests that may have preceded it. This restriction accomplishes four functions: 1) it removes any need for the connectors to retain application state between requests, thus reducing consumption of physical resources and improving scalability; 2) it allows interactions to be processed in parallel without requiring that the processing mechanism understand the interaction semantics; 3) it allows an intermediary to view and understand a request in isolation, which may be necessary when services are dynamically rearranged; and, 4) it forces all of the information that might factor into the reusability of a cached response to be present in each request."

When the paper was written, the per-user requests were supposed to be an exception, a minority case.

HTTPS will effectively make everything opaque and "per-user", and hence everything I quoted above which refers to intermediaries will no longer matter.

Restrictions in 5.1.3 ("Stateless"), 5.1.4 ("Cache"), 5.1.5 ("Uniform interface") and 5.1.6 ("Layered") would no longer apply either. All intermediaries will see is encrypted data, so shared data and functionality as explained can no longer be moved to an intermediary.

BTW, parent, way to selectively refer to a phrase in Fielding's paper while missing the point of 99% of the rest of it.

"HTTPS-only" goes directly against the architectural principles laid out in "REST", where intermediaries should be able to understand (in a limited sense) the request and responses that pass through, do caching, differentiate idempotent from non-idempotent actions etc.

The ability for intermediaries to see what goes through is in large part why "REST" is said to aid scalability, the same point this article seems to address.

Now, both movements, "HTTPS-only" and "REST" are widely popular in dev communities. Yet I never see one acknowledge the existence of the other, which threatens it. In fact, I'd see people religiously support both, unaware of their cognitive dissonance.

Curious, I think.

I'm talking about map(), and you're talking about filter().

Here's the code in question:

  .map(function(album){
    return {artist : album("vendor")("name")}
  })

If this is simply adding a node to an AST, it could be expressed without a function:

  .map({artist : ['album','vendor','name']})

Using a function for this would be quite superfluous.

It can't work them out because you compose the query in a third party scripting language.

RethinkDB has no access to the structure of the source in order to analyze it statically and work out an optimal I/O read plan. It interacts with the language runtime by providing an API and receiving callbacks to the API from the runtime.

SQL is parsed & analyzed statically at the server, a plan is created based on that analysis and executed. So with SQL it is possible to do so.

With RethinkDB you compose your query in the script, basically, and all of the optimization opportunities end with the exposed API (no function source analysis).

It's not impossible to redesign the API to provide or even mandate static details like requested fields to RethinkDB, and it has a bit of that, but it allows freely mixing in client-side logic and even OP is confused about what it means to have a client-side mapping function.

If they would allow complex expressions to run on the server, it'd become quite verbose to compose that via an API in an introspective way, to the point it'd warrant a DSL in a string... and we're back to SQL again.