zodiac

"container" can mean other things in other contexts though, e.g. I'm running a configuration of Docker on my machine right now such that the CLI talks about "containers" but it is actually running VirtualBox in the background

I dont disagree with many of your points, but are you advocating "logging into a production system and editing the config file in nano"? Can't tell if you are...

"Leading cause" means that among causes of death obesity would be the plularity, not the majority

Node's packaging story sucks in many ways, but IMO python's is worse. I spent quite some time working with python when there was no first-party dependency sandboxing (i.e. there was virtualenv but no venv) and even today there are tools that work with one but not the other.

That said, PEPs 517 and 518 sound like they're going in the right direction from the article.

I think the terms normally used for this is "completeness" and "soundness", as in, the D type system is "sound" because it rejects all programs with use-after-free, but it is "incomplete" because there are some programs that cannot exhibit use-after-free for any input values, but that the type system rejects.

Given these more precise definitions, the analogous theorem would be that there is no type system (or static analysis) for use-after-free which is both sound and complete.

There are sometimes good reasons to define a mathematical object under study (vector space, real numbers, ...) by an axiomatic list of properties it satisfies instead of constructing it from simpler objects. John Conway's ONAG has an interesting mini-chapter about this.

Having the last index and the length be the same may not be the good thing. for instance, if you translate python's negative indices (x[-i] = x[len(x)-i]) directly the last element would be...x[-0]? But then having the last element be x[-1] in python is also not entirely obvious.

Shouldn't the tuple for 1-based indexing be 1,n,n ?

The "aim" is to cover an interval with "simple" rationals (where a rational with a smaller denominator is defined as simpler)

For French, I've found this to be really good

https://mobile.twitter.com/yggtorrent_com?lang=en

There's also the option of buying DVDs on Amazon

I guess the claim I disagree with is C8:

C8 = function composition is the primary form of composition for functional programming.

Most people consider Haskell to be a language that heavily encourages a "functional programming" style. If you take a look at idiomatic Haskell code, yes, you see a lot of function composition. But I think you also see a lot of composition that are distinct from "simple" function composition:

- Parametric polymorphism

- 'Monadic' composition (i.e. `>=>`)

- Applying higher-order functions

> Is this your whole point? That your definition of OOP, FP and design is different from my definition but you understand what I'm talking about? Or is there another point you're trying to make?

Let C1 be the following claim: "function composition is better behaved than object composition and procedure composition".

Let C2 be the following claim: "the most important part of FP is function composition".

I'm saying that you've provided arguments for C1 (that I mostly agree with). So let's say that I agree with C1. However, you haven't shown why C1 => C2, and I disagree with C2.

So to answer your question, I understand your rationale for C1 (and I agree with it), but I don't understand your rationale for C2, or for why C1 => C2.

My whole point - the one I've been trying to make in every comment in this thread - is that if you want to talk about "FP" as a whole (or "OOP" as a whole), you have to explicitly define it. Relying on intuition or culture is not enough.

Like, I use what I think of as FP features much more than I do what I think of as OOP features. In languages commonly thought of as multi-paradigm, say python, I have lots of higher-order functions, and lots of functions which are just compositions of others (I don't write point-free style though). I try hard to avoid implementation inheritance ("OOP inheritance") if possible. I know people who do the exact opposite thing in python.

But if I write down the definition of "FP" for me and you write down your definition, I 99% guarantee you they'll be different in a substantive way.

So I agree with many of the points you make in the links about how composition works in (what you think of as) FP vs OOP. But I view that as claims about individual design patterns or language features (and very big, fundamental design patterns / language features), not as things called "FP" and "OOP".

> If you follow the links, read and completely understand what I'm writing you will see I covered everything. Right now it appears you didn't read it.

Which one of your links define the terms "FP" and "OOP"?

You're still not defining what a "paradigm" is, which is my main objection. You define "FP" to be (what I claim is) a way that's too narrow. Your splitting the design space into different paradigms is (I claim) not substantiated. There is a large number of (what I claim are) different design choices such as immutability, first-class functions, monads, dynamic dispatch, etc. You're coming along and saying "some of these features are FP, some are OOP, others are procedural" without any reason why you divide them up this way.

I agree that the heart of the matter is abstraction and composition. I agree that function composition is an important part of FP. I agree that FP languages should allow point-free composition

However I think the claim "functional programming is about function composition", together with the claim that "other things commonly associated such as immutability are not defining features of functional programming", is a stronger claim that seems unsubstantiated. There are many design choices analogous to immutability vs mutability that people argue are defining features of or are not defining features of FP. A Lisper might argue that closures over first-class mutable data can be part of the FP paradigm, or even that an FP language must allow that, while a Haskeller might argue that no, this must be modelled on top of immutable data. I see merit in common arguments presented for both viewpoints. A Haskeller might argue that monadic composition and syntactic support for it is a defining feature of FP, because simulating it with only "plain" function composition is deficient in some way. A criticism of this might be that monad transformers don't compose well. They might argue functions that functions should not be strict by default, because non-strict functions compose better than functions which are not. There's a great Quora answer that talks about this (https://www.quora.com/After-Haskell-there-is-no-language-whi...) and I remember a blog post framing this more explicitly in terms of composition that I can't find right now. I'm just sketching arguments that I've heard/thought about, but all these arguments deal with composition, abstraction and functions.

I don't like the framing of "does a procedure or an object compose better" because not all design choices fall into one of those, in fact I think very few do in a useful way. Is multiple dynamic dispatch (e.g. Julia) a way to compose functions or objects?

If you know the type of distribution but not the parameters,you can sometimes go through the data once and estimate the parameter (maybe exactly) without "storing the distribution" via histograms. Eg if you know the data is drawn from a uniform distribution U(a,b) but you don't know a or b.

Do you have a rationale for drawing the line there? Why don't we go further and claim that (say) FP is also about laziness, if your language does not support first class laziness it's not functional. Or first class continuations, etc

I personally find it fun to become better or trying to see how close I can get to being the best at my hobbies.

Is it possible to buy with cash?

Here's a disagreement: you're right that it would be nice if benchmarks included desktops, but I continue to want to do "serious work" on my (expensive, underpowered relative to a desktop) laptop.

Are they "bugs" from the point of view of the gba designers or the game programmers? I was u der the impression that the game programmers purposely read invalid memory this way in order to prevent emulation

It's true that he passed the interviews and everyone seemed to love him, but would you hire someone who lied to the extent that he did?

Are you normally able to take your scooter into public transit?

Another thing to try: experiment with not eating lunch at all

Oops:

Every cube is within one of a multiple of nine, which means every sum of three cubes is within three of a multiple of nine. So numbers of the form 9k+4 or 9k+5 cannot be expressed as the sum of three cubes.

It’s conjectured that every other whole number can be.

https://twitter.com/robinhouston/status/1169938974246342658?...

They mean "unsolved" in the sense that for eg we cant prove or disprove claims like "all integers are the sum of three cubes".

How about tax-paying non-citizen residents, tourists etc?

These say "lab-grown veggie burger" and "lab-grown Impossible Burger" but never "lab-grown meat"

Impossible Burger isn't lab-grown meat