adgasf

The v1 / v2 split was arguably Apple's fault. v1 launched before Homekit; then Homekit required special hardware authentication; then v2 launched to support this; then Apple walked back on the special hardware and allowed things to be done in software, but Philips had already made breaking changes for v2.

Again, Philips made the wrong call here.

So if Kubernetes makes management simpler and more robust for teams of 500+, but is overly complex for teams of 5, what solution would people recommend for teams of 5?

AFAIK the bulbs are compatible with v1 and v2 hubs, so the bulbs do not need to be replaced. The v1 hubs will continue to work across a local area network. Philips offered a heavily discounted upgrade for v1 hub users to get a new v2 hub.

However, I still think they should support the v1 hubs for the lifespan of a typical bulb (15 years), at minimum.

Google keeps Chrome around because the alternative is just too risky for their core business. If (for example) everyone used IE then Microsoft would be able to shut out Google's ads.

Google Docs solves the 95% case of version-control simply by bringing everyone to the head of master at all times.

Agreed! and the approach to operator overloading is much more pragmatic.

Conversely, it's also one of the biggest pain-points when throwing together a quick prototype.

Aren't most people running a load-balancer in front nowadays?

If the key is not evidence then how can they prove that they got the incriminating files from the encrypted drive?

MS gave Nokia 1 billion usd

If the differences are only minor then what does it enable that the more popular alternative does not?

You're right the familiarity is a good thing though - just look at TypeScript!

This doesn't look sufficiently different to JavaScript with JSX.

> Why do you think it's not a good practice?

I didn't say it wasn't. Docker makes sense because everyone uses it.

However, I would prefer a Docker alternative that is purely local and doesn't require so many permissions.

> it doesn't even solve the problem because dependencies are just downloaded from the package manager.

The advantage of Docker is that you can verify the container works locally as part of the build process rather than finding out it is broken due to some missing dep after a deployment. If you can verify that the image works then the mechanism for fetching the deps can be as scrappy as you like. Docker moves the dependency challenge from deployment-time to build-time.

Docker is designed to push you towards DockerHub, not to be the simplest or best container implementation.

People seem to find |> easier to learn.

I find JavaScript unusable without this operator. Fortunately Babel supports it well.

It makes a great alternative to fiddling with prototypes or wrapper objects when you want to extend something.

For example, this is flat-map implemented as a free function:

    const flatMap = f => {
      if (!f) {
        throw new TypeError('f must be a function');
      }

      return xs => ({
        [Symbol.iterator]: function * () {
          for (const x of xs) {
            yield * f(x);
          }
        }
      });
    };


    // Usage
    const xs = [ 1, 2, 3 ] |> flatMap(x => [ x, -x ]);

If that's how they measure employment, how do they measure underemployment?!

The pipeline operator and some free functions is a superior alternative.

    const map = f => xs => ({
      [Symbol.iterator]: function * () {
        for (const x of xs) {
          yield f(x);
        }
      }
    });

    xs |> map(x => x * 2);

A Hackintosh does not just work. It requires far more upkeep than a Linux system.

I certainly wouldn't do it again!

A short cookie with a browser fingerprint will be enough for tracking.

I was responding to:

> IDE support is much more than just editing text.

In case anyone reading this thread comes away thinking that VS Code + Ionide is only a text editor.

Ionide gives you IDE features like type annotations and auto-complete.

F# allows you to implement such features as libraries using computation expressions.

You can write a type provider that takes a schema instead of example data.

Most of the F# community seems to be using Ionide on VS Code. This works very well, but if Visual Studio is your preferred editor this can be annoying.

In addition to that, the .NET runtime supports tail calls but the JVM does not, IIRC.

I think was true before .NET Core, but now the experience is quite good.

It's also possible to use F# as a compile-to-js language using Fable. This code would run on Node or the browser.

Then there is https://github.com/dotnet/corert which allows ahead-of-time compilation to native code, but it is a bit more experimental.

Presumably you need some functionality in the dependencies that you use. If you don't use a package manager then your options are:

* Import the dependency manually. This is taking a dependency without the formal description a package manager gives you, making it harder to audit, update etc.

* Write the functionality yourself. This guarantees you are not exposed to malicious code, but it takes time and your solution will likely have more bugs than a widely used solution. You also lose the ability to use other dependencies that build on top (e.g. React components) because you are now outside the mainstream.

What is actually needed is better tooling to analyze and prune dependency graphs.

I can't imagine writing C++ without lambdas and auto