BringTheTanks

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