My unusual hobby - <AUTHOR> https://www.stephanboyer.com/post/134/my-unusual-hobby <comment><USER2> > What's really amazing to me is that Stephen Kleene probably proved this > without the help of a computer, but I was able to verify it with the highest > possible scrutiny. It's as if he wrote an impressive program without ever > having run it, and it turned out not to have any bugs!

This offhand comment (which we can all forgive) makes it seem like mathematics happens in a vacuum. I can understand the temptation to think that way, and I hope I can make it clear that this is not the case.

General theorems typically grow out of a set of representative examples of interesting behavior (unit tests, if you will), are judged by their relationship to other mathematical objects and results (integration tests), and are reviewed by other mathematicians (user acceptance tests).

Mathematicians don't just write down a proof and cross their fingers. The proof is often one of the last steps. There is a high-level intuition that explains why a theorem or proof sketch is probably true/correct before a formal proof is found. These explanations are usually compact enough to help one re-derive proof ("X doesn't have enough 'space' to fill Y, and Z tracks that gap", or something like that), but aren't formal enough to put into any formal logic system I know of.

<comment><AUTHOR> (OP here.) Fair enough—thanks for the thoughtful clarification.

By the way, I'm a big fan of your "Math ∩ Programming" articles. People who found my blog interesting will certainly think the same of yours: [https://jeremykun.com/](https://jeremykun.com/)

<comment><USER3> You're a class act.

</comment></comment></comment><comment><USER4> And this...

" _To give you an idea of what an actual proof looks like in Coq, below is a proof of one of the easier lemmas above. The proof is virtually impossible to read without stepping through it interactively, so don't worry if it doesn't make any sense to you here._ "

is why Coq is not one of my favorite tools.

A proof consists of two things: the "proof state"\---a statement of what you know at a given point--and a sequence of "proof operations"\---the manipaulations that move from one proof state to the next.

Most mathematical proofs you have ever seen have been presented as a list of proof states, with the operations either explained in comments or taken to be obvious.

Coq (and most other similar systems) present the proof as a sequence of proof operations, with the state invisible unless you're going through it in a Coq IDE.

On one hand, that's the same thing as a program: a Coq proof is a program for creating the proof. Unfortunately, on the other, I've never been able to read Coq proofs the way I can read programs. Probably a lack of experience, I guess.

On the other hand, Coq is a _damn_ fun computer game.

<comment><AUTHOR> > Unfortunately, on the other, I've never been able to read Coq proofs the way > I can read programs. Probably a lack of experience, I guess.

I don't think it's a lack of experience on your part. I worked with some people at MIT who were far better at Coq than I was, and they admitted the same thing. Coq proofs are unreadable, even when all the hypotheses and variables are given thoughtful names.

But, as you found, Coq proofs are not meant to be read; they are meant to be stepped through. I'm not sure if there is really a better alternative: if the formal proofs were made easier to read, they'd probably be much longer. And they can already get quite long compared to traditional paper proofs.

I think the right strategy is to break large developments into small lemmas, such that each proof is short and borderline obvious (similar to structuring a computer program to be self-documenting). Also, more experienced Coq users heavily invest in proof automation (building "tactics" in Coq) to make proofs short and sweet. I don't have much experience on that front, though.

<comment><USER5> I worked with Adam one summer before he had that coq textbook, he's definitely a wizard of proof automation in coq. I only much more recently learned how ltac case expressions also backtrack!

<comment><USER6> For the benefit of people without specific knowledge of people at MIT: Adam is Adam Chlipala [http://adam.chlipala.net/](http://adam.chlipala.net/)

</comment></comment></comment></comment><comment> david-gpu I had to take a semester on formal proofs using Coq, the same tool the article talks about.

Putting aside their steep learning curve, formal proof methods do not guarantee that the code you've written is bug free. They only guarantee that the code follows the requirements you defined given the conditions you also set on your inputs. You can think of it as a mathematical proof of your postconditions will hold given that your preconditions are true.

And you know what? People do make mistakes establishing those preconditions and postconditions all the time, and the tool is not going to be of any help. You've proven your code, but it may not do what you actually wanted it to do.

During a lecture I saw a tenured professor, who was a well-respected mathematician and expert in Coq, make some rather obvious mistakes while establishing those preconditions and postconditions. His proof was valid but worthless.

When you add that writing those proofs is actually rather time consuming, you end up with a niche product with little real-world applicability, except possibly for safety-critical environments.

<comment><USER7> > Putting aside their steep learning curve, formal proof methods do not > guarantee that the code you've written is bug free.

People seem to always bring this up but what's better? Verified code is about as close as you're ever going to get to bug free.

If you're doing a large proof, getting the specification wrong and not eventually noticing while working on the proof isn't common. You'll likely have something that isn't provable and get proof goals that don't make any sense. I don't think it's a common problem for mathematicians either that they end up proving the wrong thing.

I haven't heard of any examples of complex verified programs where later someone found a huge flaw in the specification. It would be like writing a set of unit tests and a complex program that passed them which had behaviour that goes against what you wanted.

<comment><USER8> > I haven't heard of any examples of complex verified programs where later > someone found a huge flaw in the specification.

Look at

> [https://www.krackattacks.com/](https://www.krackattacks.com/)

"The 4-way handshake was mathematically proven as secure. How is your attack possible?

The brief answer is that the formal proof does not assure a key is installed only once. Instead, it merely assures the negotiated key remains secret, and that handshake messages cannot be forged.

The longer answer is mentioned in the introduction of our research paper: our attacks do not violate the security properties proven in formal analysis of the 4-way handshake. In particular, these proofs state that the negotiated encryption key remains private, and that the identity of both the client and Access Point (AP) is confirmed. Our attacks do not leak the encryption key. Additionally, although normal data frames can be forged if TKIP or GCMP is used, an attacker cannot forge handshake messages and hence cannot impersonate the client or AP during handshakes. Therefore, the properties that were proven in formal analysis of the 4-way handshake remain true. However, the problem is that the proofs do not model key installation. Put differently, the formal models did not define when a negotiated key should be installed. In practice, this means the same key can be installed multiple times, thereby resetting nonces and replay counters used by the encryption protocol (e.g. by WPA-TKIP or AES-CCMP)."

I personally would consider this as a clear example of a huge flaw in a specification where a correctness proof was done on.

<comment><USER7> > I personally would consider this as a clear example of a huge flaw in a > specification where a correctness proof was done on.

Awesome, thanks for the recent example. My point is people seem to always bring up that specifications may have flaws as if this makes verifying code pointless. The guarantee of correctness is still an order of magnitude better than e.g. using unit tests and I'd wager it isn't common that specifications are wrong in a critical way. It's difficult to make a mistake specifying that a program should not have buffer overflows and out of range errors for instance.

The WPA2 flaw is an example of a specification missing an important property as opposed to a property being described incorrectly. People seem to jump on the latter the most I find as if it's common.

<comment><USER8> > The WPA2 flaw is an example of a specification missing an important property > as opposed to a property being described incorrectly.

If a specification misses an important property it is in my opinion by definition an incorrect description (in particular in this case when this missing property indeed leads to a security problem).

> I'd wager it isn't common that specifications are wrong in a critical way.

> People seem to jump on the latter the most I find as if it's common.

Let me present you an hypothesis: Currenly few things are really formally specified. And if it is done, there are usually very smart people behind the project. Which by definition makes it rare that they contain lots of critical errors. On the other hand, if these methods were applied "large scale" (i.e. also by much less skilled programmers who don't have a lot of deeper knowledge about more than basic computer science topics), the rates of errors in specification would be much higher and I believe this could become a not-that- uncommon topic.

Of course I nevertheless believe that if a lot more properties were formally specified and correctness proofs were done, the error rates of programs would nevertheless go down by magnitudes. But I don't believe that formal specifications and formal correctness proofs are a panacea. What I rather consider as sad is that it seems to be that if formal specification and machine-checked proofs were applied "by nearly every program", we actually slowly get out of ideas what kind of tools we can develop to decrease the error rates even more...

<comment><USER7> > If a specification misses an important property it is in my opinion by > definition an incorrect description (in particular in this case when this > missing property indeed leads to a security problem).

I agree that missing important properties is very bad, but incorrectly stating a property, writing a complex program that matches it and completing the proof all without noticing sounds unlikely to me.

> On the other hand, if these methods were applied "large scale" (i.e. also by > much less skilled programmers who don't have a lot of deeper knowledge about > more than basic computer science topics), the rates of errors in > specification would be much higher and I believe this could become a not- > that-uncommon topic.

Hmm, so from my experience, if you're having trouble writing correct specifications you quickly end up getting stuck when writing proofs. Your specification won't match your program and your program won't match your specification so you'll be unable to finish your proof. If you somehow luck out through this a few times, you eventually won't be able to prove something else because a previous specification/theorem is wrong.

> But I don't believe that formal specifications and formal correctness proofs > are a panacea. What I rather consider as sad is that it seems to be that if > formal specification and machine-checked proofs were applied "by nearly > every program", we actually slowly get out of ideas what kind of tools we > can develop to decrease the error rates even more...

Besides having machines read our minds, I'm not sure where you can go from formal methods except inventing languages that make specifications easier to accurately describe. When it's still a ongoing debate if strongly typed languages are safer than dynamically typed languages we have a very, very long way to go so this isn't an issue yet...

</comment></comment></comment></comment></comment></comment><comment><USER9> If you're a programmer that's not tried theorem proving before, I highly recommend giving it a go. It gave me the same 'thrill' I got when I first started programming as a 14-year old and realised a new way of thinking. I find it sharpens your mind in a new, and different way - that's really an exciting feeling.

I prefer Isabelle myself, as I find its proofs more readable in a traditional mathematical sense. Coq however, is probably easier for most programmers to experiment with.

<comment><AUTHOR> > I prefer Isabelle myself, as I find its proofs more readable in a > traditional mathematical sense.

Just curious, what makes Isabelle easier to read? I haven't tried it.

<comment><USER9> Isabelle comes with a proof language layer Isar, designed specifically for readability: [https://isabelle.in.tum.de/Isar/](https://isabelle.in.tum.de/Isar/)

The structure of Isar proofs then more closely resemble a traditional mathematical proof, with a formalisation close to natural language. You can see the example from Wikipedia:

[https://en.wikipedia.org/wiki/Isabelle_(proof_assistant)](https://en.wikipedia.org/wiki/Isabelle_\(proof_assistant\))

As you can see, the overall structure of the proof is clearer, and you have less dependency of seeing the proof state to understand the proof.

The downside to Isabelle is that it introduces a dual syntax, with certain sections written in quotes. There's more to learn syntax and concept wise, but I think it's worth the extra effort for a clearer proof.

EDIT: Linked to Wikipedia page for formatting.

</comment></comment></comment><comment><USER10> Please use a more informative title and name the hobby. The current title "My unusual hobby" is click bait.

<comment><USER11> "Get Coq out for monkey at QA."

<comment><USER12> Please don't.

<comment><USER13> Given your moderation style of politely asking people not to contribute certain manner of things, I now understand that was probably your intent here.

But my first reading of this comment was as a wry response to the content of the parent comment.

And that is why natural language is not a formal system!

</comment></comment></comment></comment><comment><USER14> Reminds me of Principia Mathematica, where the author (Bertrand Russell) needs 379 pages to prove that 1+1=2. [1]

> "From this proposition it will follow, when arithmetical addition has been > defined, that 1 + 1 = 2." —Volume I, 1st edition, page 379.

[1] [https://en.wikipedia.org/wiki/Principia_Mathematica](https://en.wikipedia.org/wiki/Principia_Mathematica)

<comment><USER15> Fun aside: I'd love to see the reaction of an applied-math class, like an engineering class, in which the instructor after having introduced the course, says, "let's go through some math prequisites for this class" and essentially starts reciting something equivalent to Principia Mathematica (without mentioning what he's trying to prove, meaning in a bottom-up fashion),

\- "If A is true, and B is true, then C is true"

\- "We know A is true, therefore if B is true, C must be true"

\- "B is true if and only if D is true and E is true"

\- ...

\- Therefore C is true.

\- (on and on and on for a whole hour).

<comment><USER16> Do that to any pure math class and they will similarly walk out. You need to know where something abstract like this is going to follow at all.

<comment><USER17> > You need to know where something abstract like this is going to follow at > all.

Indeed, and do remind your audience from time to time about where you're going. Otherwise, your whole line of reasoning might become useless to someone who lost track of the point, or just didn't hear or grasp it the first time you said it.

</comment></comment></comment></comment><comment><USER18> I've read a fair bit about functional programming but the right-associative nesting of -> still bothers me.

 _(first precondition IMPLIES (second precondition IMPLIES (implication))_

is inherently harder for me to understand than

 _(first precondition AND second precondition) IMPLIES implication_

even though logically they are the same. The first version carries more mental overhead because it seems to indicate that there is some sort of hierarchy/assymetry to the two preconditions.

It's the same thing when I try to read a Haskell function type signature:

f :: a -> b -> c

 _f is a function taking a and returning (a function taking b and returning (c))_

vs.

 _f is a function taking two parameters a and b and returning c_

There is no hierarchy anyhow because the parameters can be swapped:

f' = \b a -> f a b

Curious to know if it's just me or there are others who experience the same.

<comment><USER19> I am not a particularly experienced functional programmer. What functional programming I do is mainly relegated to code I write as a hobby, but in the last year or so I've started using more functional techniques at work (and luckily my teammates haven't lynched me yet). These days at work I use primarily Ruby and I've been surprised at how often I write curried procs. The language neither requires nor encourages that behaviour, so why am I doing it?

I think I started with the same assumption that you have: the order or parameters is arbitrary. In functional programming, though, this is not the case. For example, the "map" function takes a function and a functor (you can think of a functor as a collection like a list if you aren't familiar with the term). The order is important because if I partially apply a parameter to "map" I get a completely different meaning.

If you partially apply the function to "map", then the result is a function that applies that function to any kind of functor. If you partially apply the functor to "map", then the result is a function that applies any kind of function to that specific functor. Because I can only partially apply the first parameter in the function, this helps define the meaning of the function. In this example, the first definition is more correct (because "map" always takes the function first and the functor second). This becomes increasingly important as you build applicatives and monads.

In case that was unclear, here's a quick example. Let's say I have a list of integers and I have a function that adds 5 to an integer. If I do something like "map addFive list", it will go through each element in the list and add 5, resulting in a new list. If I partially apply the function to map with "map addFive", this will return a function that loops through any list and adds five to each element. So I might say "let addFiveToEach = map addFive".

If we had a different kind of map function (let's call it "mapNew") maybe we can do "mapNew list addFive" and it will do the same as the "map" code above. But if I partially apply list to mapNew I get a function that applies a function to my specific list. I might do "let eachInList = mapNew list".

The result is two very different functions. Either I will do "addFiveToEach list" or I will do "eachInList addFive". What meaning I prefer depends on the situation.

It's this idea that partially applied functions have a meaning that is powerful. When you are writing the code, which meaning do you want? As you note, both are possible, but I think you'll find that only one is actually appropriate in most cases. For example, instead of calling the function with both parameters, what if you assigned the result of partially applying the function to a variable? What would the variable be called? Does that help the reader understand the code?

Like I said, I was surprised at how often it makes a difference in my code. In fact, where it doesn't make a difference, it's usually an indication that I've made a mistake somewhere. It is even to the point where you start to want to pass partially applied functions around because they are more meaningful than the data that they contain. In fact a function is literally just another container in a functional programming language. For me, that was a kind of mind blowing realisation.

<comment><USER20> I think that's just an artifact of how currying is usually specified. Imagine a language with no automatic currying, but the special name "_" makes the function partially applied: "let addFiveToEach = map addFive _" (or "map (+ 5 _) _"). Then you can also do "let eachInList = map _ list", and you don't have to choose between them.

It does sacrifice some use cases, such as not knowing the total number of parameters, and does add more line noise. But I would be pretty happy with this tradeoff.

</comment></comment></comment><comment><USER15> So I'm wondering what is the bridge between "proof-assistant" and "automated (or partially automated) theorem prover".

As someone with "journalistic" (but fairly in-depth) knowledge about these topics, my guess is that something like a proof-assistant will have to be paired up with some kind of logic programming system (like Prolog, or a kanren-derived system or something).

I guess then the problem of combinatorial explosion in logic search translates directly to the combinatorial explosion of proof-steps in a proof assistant. Hence my mention of partially-automated (more doable than fully-automated).

Probably some kind of a "database of facts" would also be involved, making it an expert system (reminds me of metamath [1]).

Is it fair to say, partially-automated theorem proving is a fairly advanced version (and not without added complexity) of a proof-assistant, and will help ease some of the grunt work involved in using a proof-assistant by hand?

[1] [http://us.metamath.org/](http://us.metamath.org/)

<comment><USER21> I've done a bit of work on a "next generation" Metamath, Ghilbert[1], but have come to the conclusion that it's too ambitious to do as a part-time project. People might find it interesting, though, because it attempts to take interactivity to a higher level than Metamath, and is (imho) a cleaner language.

[1] [http://ghilbert.org/](http://ghilbert.org/)

<comment><USER15> Hey glad to find someone involved in metamath related project.

I guess if I could simplify my discussion to one question, it would be: Does metamath or ghilbert use a logic inference engine to automate parts of a proof?

The way I understand metamath (the website, not the language) is that it's like an encyclopedia of mathematical knowledge. The encyclopedia is in the form of theorems, lemmas, corollaries, and their proof. But unlike an encyclopedia or disconnected articles, all the propositions build on top of one another. As a result, it builds (or tries to build) the whole mathematical edifice starting from core axioms (well, I guess it didn't build itself, but hundreds of mathematicians contributed to the database, like people contributing to wikipedia in the form of article-writing. As to how automated this process is, I don't know).

Now the question is, can we use this edifice as a database, to be input to a logic inference engine. What this would accomplish is that:

\- If I make a query about a mathematical proposition (e.g., Are there infinite prime numbers), the logic inference engine would use the database to conclude that there are if it is able to access all the relevant propositions.

\- If it's not able to reach a conclusion, e.g., if my query was "Are there infinite twin primes?" it would start a process of exploring new propositions from old propositions. Then either the search would conclude very quickly (if the proposition is only one or two steps away from the knowledge in the database) or it would give up after a few million, or billion attempts (e.g., this is more likely the case with the twin prime query). There will have to be a manually-specified cutoff point otherwise it could go into an infinite loop (I guess it may have something to do with decidability, incompleteness theorem, halting problem, etc, etc. Though even many decidable problems are computationally intractable due to very very large search space).

\- Suffice to say, when I say "query" I don't mean a question in english language but a well-crafted mathematical statement in language of metamath itself.

P.S.: As for your mention of this work not doable as part-time, I fully agree with you. It would have enough cognitive load to be a very complex project even if done full time.

<comment><USER21> Metamath basically goes in the other direction than most proof assistants, it relies on human ingenuity. There is a bit of search in the original C metamath (the "improve" feature) and also just a tiny amount in mmj2 (unification), but if the user doesn't have a clear picture what the fine-grained steps are, they're going to have a bad time.

One of the interesting things about Metamath is that proofs tend to be very concise. In more automated proof systems, you use automated tactics and proof search techniques, and if you expanded out their output, they'd generally be quite verbose. I think this has led a lot of people to believe that automation is more necessary than it actually is.

All that said, you absolutely could build an inference engine of similar scope as the other big proof assistants, and use the existing Metamath database as a rich foundation.

Happy to answer other questions.

</comment></comment></comment></comment><comment><USER22> Cool post! The stuff about Curry-Howard was really interesting and relates to a question i have been thinking about. But I'm a novice when it comes to the theory of type systems or theorem provers. Maybe someone here can enlighten me?

As type systems become more complex (like say in Scala or Haskell), they move towards having specialized syntax and weird hacks to express what are arguably simpler logical theorems/invariants about values in a type.. so why can't we have a programming language that gives you a full blown logic system(Coq? or Microsoft Z3? a SAT Solver?.. i don't understand the differences in detail) rather than part of one? Are there attempts at that, or does it turn out to be unworkable?

<comment><AUTHOR> > so why can't we have a programming language that gives you a full blown > logic system

Most dependently typed programming languages, including Coq, give you the ability to basically "do logic" in a mostly unrestricted way.

There are a few challenges that come to mind with making a practical programming language that can also do arbitrary math:

a) For the language to be useful for proving things, it needs to be strongly normalizing. That means all programs halt—otherwise, you could trivially prove any proposition. Unfortunately that limits its utility as a general purpose programming language.

b) The languages which attempt to be useful for theorem proving are generally pure functional languages (due to the strong correspondence between functional programming and logic). Most programmers don't like working in pure functional languages, although the success of Haskell shows that there are certainly programmers who do (myself included).

c) The more expressive a type system is, the more difficult type inference becomes. Yet, paradoxically, I find myself writing more types in languages like C++ and Java than I do in equivalent Coq programs. I believe Coq uses a variant of a bidirectional type inference engine, which is quite usable in practice.

Idris is an attempt to make a practical programming language with the full power of dependent types. So it's probably the closest real language to what you're describing.

Z3 and other SAT/SMT solvers take a different approach: they try to search for proofs automatically, and for certain kinds of math they are very successful. But these are generally only for first-order theories or other restricted kinds of propositions, and not great for general theorem proving. They are good for things like proving array accesses are within bounds, or that you never try to pop from an empty stack (at least that's my understanding of their capabilities).

<comment><USER23> I should add that something like FStar [0] combines the capabilities of automated theorem proving and a more manual-proof-based dependent type system like that in Idris.

It doesn't have some of the power of Idris' elaborator reflection, for example, but it can eliminate many long-winded manual proofs via the SMT solver.

[0] [https://www.fstar-lang.org/](https://www.fstar-lang.org/)

</comment></comment></comment><comment><USER24> Here is a paper that shows Coq proofs of two famous theorems by Shannon: the source compression rate of H(X) and the channel capacity of I(X,Y). [https://staff.aist.go.jp/reynald.affeldt/documents/affeldt-i...](https://staff.aist.go.jp/reynald.affeldt/documents/affeldt- itp2012-preprint.pdf)

I wonder if simplified versions of these proofs couldn't be used with students. Right now it seems like too much details, but maybe there can be a common "stdlib" of standard math arguments that we assume to be true, and then focus on the specific machinery for each proof?

</comment><comment><USER2> My question for the author: does implementing a proof formally in Coq honestly give you a better understanding of the theorem/proof?

It would seem to me that, if you're filling in details from an existing proof or making some existing formal (in the math sense) intuition more formal (in the Coq sense), there's not much deep insight to gain from implementing a proof in Coq.

<comment><AUTHOR> My experience is: formally proving something in Coq is not a prerequisite for understanding it, but understanding it is a prerequisite for formally proving it in Coq. So if you get Coq to accept your proof, it's a good sign that you understand every detail.

For the domain theory proof I discussed in the article, formalizing it in Coq absolutely helped me understand it because:

a) Merely formalizing the definitions was valuable for me, because there are tricky subtleties to them (e.g., the supremum of a subset doesn't need to be in the subset, the various ways to define a "complete partial order", etc.).

b) When you do a formal proof, you have to refer to the definitions quite often. This just reinforces them in your brain.

c) Of course, when you formalize things in Coq, any misunderstandings you had about the material will be brought to your attention when your proof doesn't work.

On the other hand, I didn't gain much insight from the soundness proof for the simply typed lambda calculus. The definitions for that development were more straightforward. But I was already fairly familiar with the ideas of progress, preservation, etc. so I didn't expect to learn much from doing that. If anything, the main thing I gained from that was experience using Coq.

<comment><USER25> > My experience is: formally proving something in Coq is not a prerequisite > for understanding it, but understanding it is a prerequisite for formally > proving it in Coq. So if you get Coq to accept your proof, it's a good sign > that you understand every detail.

Such tasks are called "orienting tasks" in the cognitive science/human learning literature, and are useful because what it means to "understand" something is quite nebulous and we often fool ourselves when we actually think we understand something. They also allow us to test understanding outside of the domain it's supposed to be applied in, which is useful if the real situation is noisy, messy or costly.

Scott H Young explains the psychology of the problem well: [https://www.scotthyoung.com/blog/2017/06/13/how-much-do- you-...](https://www.scotthyoung.com/blog/2017/06/13/how-much-do-you- understand/)

<comment><USER26> Thanks for the link, that was quite interesting.

I love the format that the article takes, as well. I liked the superscript note numbers that xkcd's whatif blog uses, this is another implementation of that, executed very well.

<comment><USER25> It makes printing a bitch but overall I wouldn't mind if more articles were formatted like that, yeah.

</comment></comment></comment></comment></comment><comment><USER27> Terrific!

I took the liberty of translating your module to TLA+, my formal tool of choice (recently, I've been learning Lean, which is similar to Coq, but I find it much harder than TLA+). I tried to stick to your naming and style (which deviate somewhat from TLA+'s idiomatic styling), and, as you can see, the result is extremely similar, but I guess that when I try writing the proofs, some changes to the definitions would need to be made.

One major difference is that proofs in TLA+ are completely declarative. You just list the target and the required axioms, lemmas and definitions that require expanding. Usually, the proof requires breaking the theorem apart to multiple intermediary steps, but in the case of the proof you listed, TLA+ is able to find the proof completely automatically:

        LEMMA supremumUniqueness ≜
          ∀ P ∈ SUBSET T : ∀ x1, x2 ∈ P : supremum(P, x1) ∧ supremum(P, x2) ⇒ x1 = x2
        PROOF BY antisym DEF supremum (* we tell the prover to use the antisym axiom and expand the definition of supremum *)

The natDiff lemma doesn't even need to be stated, as it's automatically deduced from the built-in axioms/theorems:

        LEMMA natDiff ≜ ∀ n1, n2 ∈ Nat : ∃ n3 ∈ Nat : n1 = n2 + n3 ∨ n2 = n1 + n3
        PROOF OBVIOUS (* this is automatically verified using just built-in axioms/theorems *)

Another difference is that TLA+ is untyped (which makes the notation more similar to ordinary math), but, as you can see, this doesn't make much of a difference. The only things that are different from ordinary math notation is that function application uses square brackets (parentheses are used for operator substitution; operators are different from functions, but that's a subtelty; you can think of operators as polymorphic functions or as macros), set comprehension uses a colon instead of a vertical bar, a colon is also used in lieu of parentheses after quantifiers, and aligned lists of connectives (conjunctions and disjunctions) are read as if there were parentheses surrounding each aligned clause. Also `SUBSET T` means the powerset of T.

Here's the module (without proofs, except for the one above):

        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>- MODULE Kleene </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-
        EXTENDS Naturals

        (*
          Assumption: Let (T, leq) be a partially ordered set, or poset. A poset is
          a set with a binary relation which is reflexive, transitive, and
          antisymmetric.
        *)

        CONSTANT T
        CONSTANT _ ≼ _

        AXIOM refl    ≜ ∀ x ∈ T : x ≼ x
        AXIOM trans   ≜ ∀ x, y, z ∈ T : x ≼ y ∧ y ≼ z ⇒ x ≼ z
        AXIOM antisym ≜ ∀ x, y ∈ T : x ≼ y ∧ y ≼ x ⇒ x = y

        (*
          A supremum of a subset of T is a least element of T which is greater than
          or equal to every element in the subset. This is also called a join or least
          upper bound.
        *)

        supremum(P, x1) ≜ ∧ x1 ∈ P
                          ∧ ∀ x2 ∈ P : x2 ≼ x1
                          ∧ ∀ x3 ∈ P : ∀ x2 ∈ P : x2 ≼ x3 ⇒ x1 ≼ x3

        (*
          A directed subset of T is a non-empty subset of T such that any two elements
          in the subset have an upper bound in the subset.
        *)

        directed(P) ≜ ∧ P ≠ {}
                      ∧ ∀ x1, x2 ∈ P : ∃ x3 ∈ P : x1 ≼ x3 ∧ x2 ≼ x3

        (*
          Assumption: Let the partial order be directed-complete. That means every
          directed subset has a supremum.
        *)

        AXIOM directedComplete ≜ ∀ P ∈ SUBSET T : directed(P) ⇒ ∃ x : supremum(P, x)

        (*
          Assumption: Let T have a least element called bottom. This makes our partial
          order a pointed directed-complete partial order.
        *)

        CONSTANT bottom

        AXIOM bottomLeast ≜ bottom ∈ T ∧ ∀ x ∈ T : bottom ≼ x

        (*
          A monotone function is one which preserves order. We only need to consider
          functions for which the domain and codomain are identical and have the same
          order relation, but this need not be the case for monotone functions in
          general.
        *)

        monotone(f) ≜ ∀ x1, x2 ∈ DOMAIN f : x1 ≼ x2 ⇒ f[x1] ≼ f[x2]

        (*
          A function is Scott-continuous if it preserves suprema of directed subsets.
          We only need to consider functions for which the domain and codomain are
          identical and have the same order relation, but this need not be the case for
          continuous functions in general.
        *)

        Range(f) ≜ { f[x] : x ∈ DOMAIN f }

        continuous(f) ≜
          ∀ P ∈ SUBSET T: ∀ x1 ∈ P :
            directed(P) ∧ supremum(P, x1) ⇒ supremum(Range(f), f[x1])

        (* This function performs iterated application of a function to bottom. *)

        RECURSIVE approx(_, _)
        approx(f, n) ≜ IF n = 0 THEN bottom ELSE f[approx(f, n-1)]

        (* We will need this simple lemma about pairs of natural numbers. *)

        LEMMA natDiff ≜ ∀ n1, n2 ∈ Nat : ∃ n3 ∈ Nat : n1 = n2 + n3 ∨ n2 = n1 + n3

        (* The supremum of a subset of T, if it exists, is unique. *)

        LEMMA supremumUniqueness ≜
          ∀ P ∈ SUBSET T : ∀ x1, x2 ∈ P : supremum(P, x1) ∧ supremum(P, x2) ⇒ x1 = x2
        PROOF BY antisym DEF supremum

        (* Scott-continuity implies monotonicity. *)

        LEMMA continuousImpliesMonotone ≜ ∀ f : continuous(f) ⇒ monotone(f)

        (*
          Iterated applications of a monotone function f to bottom form an ω-chain,
          which means they are a totally ordered subset of T. This ω-chain is called
          the ascending Kleene chain of f.
        *)

        LEMMA omegaChain ≜
          ∀ f : ∀ n, m ∈ Nat :
            monotone(f) ⇒
                approx(f, n) ≼ approx(f, m) ∨ approx(f, m) ≼ approx(f, n)

        (* The ascending Kleene chain of f is directed. *)

        LEMMA kleeneChainDirected ≜
          ∀ f : monotone(f) ⇒ directed({ approx(f, n) : n ∈ Nat })

        (*
          The Kleene fixed-point theorem states that the least fixed-point of a Scott-
          continuous function over a pointed directed-complete partial order exists and
          is the supremum of the ascending Kleene chain.
        *)

        THEOREM kleene ≜
          ∀ f : continuous(f) ⇒
            ∃ x1 ∈ T :
                ∧ supremum({ approx(f, n) : n ∈ Nat }, x1)
                ∧ f[x1] = x1
                ∧ ∀ x2 : f[x2] = x2 ⇒ x1 ≼ x2

        </comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>=====

<comment><AUTHOR> Wow, this is amazing. Can you share a link to the full module with proofs? I'd love to compare it to the Coq version.

<comment><USER27> Sure — if and when I get around to writing them :) Looking at your proofs will probably make this a lot easier. After all, the principles of proof are very similar in pretty much every system. But if you want to get a sense of what a methematical proof in TLA+ looks like (as opposed to algorithm proofs, which make up most TLA+ examples), see the appendix to this paper: [https://lamport.azurewebsites.net/pubs/proof.pdf](https://lamport.azurewebsites.net/pubs/proof.pdf)

But it's very important to know that TLA+ has very different usage goals from Coq/Lean/Isabelle, and so makes very different design tradeoffs. The tools are certainly _not_ interchangeable.

Coq, Lean and Isabelle are first-and-foremost research tools. As such, they are completely general purpose, very powerful, but also very, very complicated. TLA+, on the other hand, was designed for use by ordinary engineers to specify and verify large, real-world digital (software or hardware) systems. This means that TLA+ is not generally appropriate for doing high math (e.g., because it's untyped, it doesn't even have operator overloading, which alone would make it unappealing for serious math; then again, not much serious math is done formally, anyway), and isn't designed for logicians to explore various logics (it's classical logic only). In addition, it's syntactic/symbol manipulation capabilities are very limited, so while you _could_ specify a programming language, as you've done, the result is going to be much messier (although specifying low-level languages with simple syntax, like machine- or byte code, can be very elegant).

OTOH, TLA+ is truly exceptional in its ease of learning and its capabilities when it comes to specifying and verifying systems and algorithms. In many respects, it's computational theory is richer than Coq's (although Coq is so general that some people have embedded TLA, the computational theory of TLA+ in Coq; but TLA+ has it out of the box). In addition, when used in industry, people hardly ever use TLA+'s proof system. Not because it's inadequate for proving the correctness of algorithms — it truly excels at that — but because formal proofs are, in general and regardless of the choice of tool, not very cost effective. Instead, TLA+ has a model checker that lets you verify your propositions about your system completely automatically — you just state them and press a button — albeit, only on small, finite instances. This is more than sufficient for industry use, as, while there have been multiple cases of informal (published and peer-reviewed) correctness proofs later found to be wrong with a model-checker, I am not aware of any cases where a model checker result was found wrong, despite running on small instances, and so not qualifying as proof.

So the choice between TLA+ and Coq/Isabelle/Lean is usually simple. If you're an academic researching new logics, new programming languages, or complex formal mathematics, you'll choose Coq/Isabelle/Lean. If you're an engineer trying to design a complex or subtle system or algorithm, you'll likely choose TLA+.

</comment></comment></comment><comment><USER28> Whoa, very cool post! It's interesting that "small but novel" languages can be formally proved. Do any mainstream languages have a sound foundation like that? If someone is interested in creating a new programming language, is it worth getting up to speed on proof writing and using that to build the language? It's not really a topic that comes up in the Dragon Book or mainstream general compiler study, AFAIK.

<comment><AUTHOR> > Do any mainstream languages have a sound foundation like that?

I can think of a few languages that started from a formal theory (e.g., Eff [1]), but none of them are "mainstream". There was a mostly successful attempt [2] at formally specifying C and implementing a verified compiler for it. Standard ML has a very comprehensive spec [3], perhaps the best of any "mainstream" language. It's not quite at the level of a Coq formalization, but also not too removed from it. Haskell is based on a lot of peer-reviewed papers, but there isn't one comprehensive spec for it at this level of formalism. Also, the RustBelt project [4] is worth mentioning. It's an initiative to develop a formal theory of Rust.

> If someone is interested in creating a new programming language, is it worth > getting up to speed on proof writing and using that to build the language?

If your new programming language contains a novel idea that you want to have published in a peer-reviewed journal/conference, then yes, I think it is absolutely worth it. It's likely your paper will be rejected without having formal proofs.

But if you don't intend to publish your ideas, it's really quite a lot of work and might not be worth it. Depends on how dedicated you are, and how much you care about things like soundness.

[1] [http://www.eff-lang.org/](http://www.eff-lang.org/)

[2] [http://compcert.inria.fr/](http://compcert.inria.fr/)

[3] [http://sml-family.org/sml97-defn.pdf](http://sml- family.org/sml97-defn.pdf)

[4] [http://plv.mpi-sws.org/rustbelt/](http://plv.mpi-sws.org/rustbelt/)

</comment></comment><comment><USER29> I've been working in a CPS Joy variant, deriving recursive functions on trees and such. I've noticed that the code always works the first time. So far my "data" on this phenomenon is still too anecdotal to get excited, but I wanted to mention it (here where people might be interested.) It surprised me at first, but then I realized that this is part of the promise of Backus' Functional Programming: being able to do algebra to derive programs gives you error-free code that doesn't require tests.

It leads me to speculate... what if I don't need types to write correct software? I assumed I would implement typing and type inference (like Factor language already has) at some point. But if the code has no bugs without it... YAGNI?

My reasoning goes like this: Let's postulate that we have a library of functions, each of which has the quality Q of being error-free. If we derive new functions from the existing ones by a process that preserves Q, so that new functions are all also error-free, then we cannot have errors in our code, _just user error_. I.e. the user can present bad inputs, but no other source of error exists (other than mechanical faults.) This would be a desirable state of affairs. Now if the Q-preserving new-function-deriving process doesn't require types to work, then we don't need them. Whether or not typing helps prevent user error is another question. Personally, I lean toward defining user error as UI error, but I am ranging far from my original point now.

(If you're interested: [https://github.com/calroc/joypy/tree/master/docs](https://github.com/calroc/joypy/tree/master/docs) Still very DRAFT versions. [https://github.com/calroc/joypy/blob/master/docs/3.%20Develo...](https://github.com/calroc/joypy/blob/master/docs/3.%20Developing%20a%20Program.md) )

</comment><comment><USER30> I'm currently working through the material here: [https://github.com/pigworker/CS410-17](https://github.com/pigworker/CS410-17)

</comment><comment><USER31> I've never managed to have fun with Coq even though I really tried. I did tons of exercises and labs. On the other hand, I do love (functional) programming, logic and maths in general.

It's almost like you get the bad side of programming (time-consuming, tedious) without the reward (seeing your program doing cool things). And you don't get the satisfaction of doing maths either. At least I don't. Maybe I didn't try hard enough.

What is very interesting though is to learn about type theory and the Curry Howard isomorphism.

</comment><comment><USER32> Is it possible for one of these "programs" to run forever? If so, does that illustrate a direct correspondence between the halting problem and godels incompleteness theorem?

<comment><AUTHOR> There are two languages to discuss here:

1) The underlying pure functional language that forms the logical basis for Coq (called "Gallina"). It is not possible to write a program which runs forever in this language, because all recursive calls must be "well founded". Coq uses a very simple set of rules to determine when recursive calls are guaranteed to terminate (slightly more flexible than primitive recursion), but it rules out some legitimate programs which do not terminate. For example, writing merge sort is difficult in Coq because the type checker can't automatically prove that the recursion terminates. For these cases, you can provide your own ordering relation and prove that it is well-founded. So tldr, you have to prove that your programs terminate (and this is automated in many cases). The fact that all Gallina programs terminate is crucial; otherwise, you could trivially prove any proposition.

2) Usually in Coq you do not write most proof terms in Gallina manually (because it is quite unnatural). Instead, you write scripts called "tactics" to generate the terms for you. These scripts are written in a dynamically typed language called Ltac, and programs in this language can run forever. But all proofs generated by these tactics are type checked in Gallina, so it's impossible for a tactic to generate a bad proof term without it being detected by Gallina's type checker.

<comment><AUTHOR> * but it rules out some legitimate programs which terminate.

(Typo, but too late to edit the original comment.)

</comment></comment></comment><comment><USER33> A lot of these comments are focused on the merits of Coq and some of the mathematical details of your post. As someone who has no experience with Coq and little experience with mathematical proofs, I want to add an additional perspective. This is a pretty cool hobby. It's really nice to hear about hobbies that aren't motivated by ambitions of profit or fame. Thanks for sharing!

</comment><comment><USER34> Anyone else here do recreational mathematics ? I mainly try to answer questions on CSTheory.stackexchange.com

</comment><comment><USER35> I have the same hobby; I play with Coq, Idris, Agda, F* and pen and paper. I do not have time to do it for work most of the code, however all critical parts I do. One of my dreams is to do this full time.

</comment><comment><USER36> Are there mathematical proofs that are incapable of being expressed in Coq? Isn't there a limit to kind of ideas a computer could verify? Curious about the boundaries of this language.

<comment><USER9> This question gets at the heart of computation, logic and provability.

Coq is based on a logic system called the "Calculus of constructions" [https://en.wikipedia.org/wiki/Calculus_of_constructions](https://en.wikipedia.org/wiki/Calculus_of_constructions). As such it has the same limitations as that logical system.

Most notably, Gödel's incompleteness theorems place a limit on what's provable in Coq, or indeed many other systems.

There are various kinds of logic systems, each with different kinds of 'power'. Power is a double-edge sword in logic systems, as with power comes the capacity to introduce paradoxes and inconsistencies.

As with programming languages, certain logic systems and automated logics are suited for particular cases. For example, there is a system 'MetiTarski' like a Domain Specific Language, designed to prove theorems about real-valued special functions.([https://www.cl.cam.ac.uk/~lp15/papers/Arith/](https://www.cl.cam.ac.uk/~lp15/papers/Arith/)).

</comment></comment><comment><USER17> > The CI system runs Coq on my code and prevents me from merging it into the > master branch if there is a mistake.

How does one make Travis CI prevent a merge?

<comment><AUTHOR> By making the master branch protected in GitHub and making the CI check for Travis required. Docs: [https://help.github.com/articles/enabling-required- status-ch...](https://help.github.com/articles/enabling-required-status- checks/)

</comment></comment><comment><USER37> thinking about this same topic there is probably amazing opportunities out there for programmer mathematicians. Don't get me wrong, of course there are quants and such for trading firms but intuitively I would think there are an amazing number of applications for this kind of advanced mathematical programming that seem relatively under utilized.

</comment><comment><USER38> This is honestly beautiful.

</comment><comment><USER39> This is how I imagine Flowtype works for Javascript (more or less). What's interesting to me, is that this could be the foundation for AIs taking over programming from developers.

</comment><comment><USER40> How do you pronounce Coq? I searched it but all I found was [https://m.youtube.com/watch?v=TAHH83n2dmY](https://m.youtube.com/watch?v=TAHH83n2dmY)

<comment><USER41> It's pronounced like "cock". It's named after the animal, and that's how you say it in French. It's how people who use the tool say it.

<comment><USER42> Not really, the English word "cock" has a very different vowel than the French "coq" \- [https://youtu.be/bIraCzL3dtI?t=4s](https://youtu.be/bIraCzL3dtI?t=4s) is a pretty fair exemplar. It's a lot more like the "o" in "joke".

(edit: maybe you're English? Some English accents of England would articulate "cock" very close to French "coq" and "joke" would be far away. Apologies, one really does need to specify which "English" is meant, and I should have seen that at once. First cup of coffee still in progress.)

<comment><USER4> Perhaps more like "Coke"?

<comment><USER43> I pronounce it as "coke", for fairly obvious reasons :-).</comment></comment></comment></comment></comment>


IPhone 5C: C is for Cognitive Illusion - <AUTHOR> http://www.asymco.com/2013/09/11/c-is-for-cognitive-illusion/ <comment><USER2> Interesting analysis by Dediu as usual (I'm a big fan and listen to his podcast regularly). I think a lot of people (including Horace and yours truly) are surprised by the 5C pricing strategy -- it's not 5C(heap) but 5C(olor). I just looked at real world photos on Ars of the new models and from my POV the 5C models look like they are designed for kids. (A matter of taste, of course.) If Apple cut the price by another $100 they might make sense as a pricepoint but at only $100 less than 5S it seems crazy to me.

It's notable there's no black (or 'slate') 5C. I guess if one wants a more 'dignified' (again, a matter of taste) one has to go 5S.

I commend to all the interesting Steve Jobs quote found at the end of the comment by markwilcox:

 _" What ruined Apple was not growth … They got very greedy … Instead of following the original trajectory of the original vision, which was to make the thing an appliance and get this out there to as many people as possible … they went for profits. They made outlandish profits for about four years. What this cost them was their future. What they should have been doing is making rational profits and going for market share." \- Steve Jobs._

As a long-time Apple fan and former shareholder I'll be very interested to see how this pans out.

<comment><USER3> > _I just looked at real world photos on Ars of the new models and from my POV > the 5C models look like they are designed for kids._

That's a western male perspective. In Asia (including India), adults will jump to get those colors. (And women in the West too).

<comment><USER4> I think you think you called out sexism, but in actually, you have perpetuated it. PP shared his/her own opinion with no attempt or claim made to speak for other people.

Your contribution was to declare which opinions belong to each sexist grouping you architected. You have said, "Your opinion is a western male one," but I doubt you know PP's origin, so you are shooting in the dark.

You have said, "Asians are like _this_. Women are like _that_. Men are like _this_. Indians are _that_." That is prejudicial, and even worse, normative, behavior by you, compelling others to conform. If I were an Asian adult who didn't like the colors, your comments might make me feel hurt right now, whereas PP's comment was acceptable.

<comment><USER5> Or perhaps its a claim based on (perceived) statistical truths about the sorts of colors and designs various groups of people prefer.

</comment></comment></comment></comment><comment><USER6> "Apple is recognizing that the market is actually "segmentable". This is the notion that one size does not fit all–a radical idea for the brand."

Apple has always had products for higher end and lower end markets as soon as that product becomes established. iPod video (I know that's not the formal name) came out at roughly the same time as the Nano and shuffle. MacBook Pro had MacBook. iPad and iPad mini. Mac Pro and iMac. This isn't new, it's just the first time it's been so deliberate and noticeable.

<comment><USER7> Author refers to smart phone market as "segmentable", not other markets. Your statement doesn't really disprove his.

<comment><USER8> Yes but the author also states that it is a "radical idea for the brand", which it isn't. It also isn't a radical idea for the smart phone market, as Android manufacturers have been doing it for a long time.

So we have a brand with experience in segmenting approaching a market that has already been segmented by competitors. Not such an interesting story.

<comment><USER7> True, that's a better statement.

It seems that Apple has done this out of market demand (of course they did, any company would rather have one clutch device over a smorgasbord), but with the 5C still being a high-end feature phone, why'd they do it? I'm guessing they are just creating a foundation for a radical iPhone 6?

<comment><USER9> I like MG's take. The iPhone 5s is evolution of a pre-Ive design.

The iPhone 5c is Johnny Ive's first shot at a decidedly Ive version of the iPhone.

<comment><USER8> Hasn't Ive done the hardware design for a long time - only recently also controlling software?

In either case, launching an extra device because your designer wants to put their stamp on the world seems like an absolutely awful business strategy.

</comment></comment></comment></comment></comment></comment><comment><USER10> The iPhone 5 has become relatively less stale in the total mobile phone market compared to what the iPhone 4/4S became. The current model of the phone can still compete, it's good enough. Apple recognizes this, but also knows that it needs to innovate to keep its early adopters happy. And so they split their product to tailor to these two market segments -- those who _need_ innovation, and those who would be perfectly happy with the current specs. These two market segments do not differ greatly in their purchasing power. Splitting the product wasn't to create a mid-tier and high-tier phone for the respective price points. It was a targeted refresh of the product for two equally valuable market segments.

I suspect that as the mobile phone landscape changes, the iPhone 5C will begin feeling more obsolete, and it will then be relegated to the level of n-1 offering, and all attention will then go to the iPhone 6, which should presumably be a huge leap in innovation and design.

<comment><USER11> To me, what this looks like is a final submission by Apple to the economics of their own supply-chain.

Apple has never been able to make enough iPhones of each successive generation for people to get their hands on during the first few months after release. Whereas, once they've ramped up production, they tend to have all these parts left over in the pipeline[1] that they have to sell off as N-1 gen hardware to price-sensitive late adopters. (This is also why the iPod Touch was originally created, to serve as a sink for N-2-gen parts.)

Now, Apple are trying to shift the purchase frenzy to the N-1 gen, and position their new gen-N tech -- whose production hasn't yet been ramped up -- as something for early-adopters only. In other words, to switch from an (N-1, N) view of the world, to an (N, N+1) view.

Everything in the S will filter down to the C of the next gen. They'll get their pipelines saturated with 5S parts just in time to wrap them in plastic and call them 6C parts. As long as more people buy Cs than Ss, this works out perfectly.

\---

[1] By "in the pipeline", I mean the more general "economically incentivized to produce units of, instead of units of the new model, by contractual obligations to factories, training costs of factory workers, etc." Apple actually keeps their literal pipeline of hardware-produced-but-not-yet- shipped-as-a-product quite low.

<comment><USER10> That's interesting. Do you have any links to read more about their supply chain and the origins of the iPod Touch?

</comment></comment></comment><comment><USER12> This is classic innovators dilemma. Apple cannot release a true low-end, mid- range, or even "low high-end" phone because it risks eating into the iPhone's legendary profit margins.

Smartphones are becoming cheaper; Apple cannot hang on to the iPhone's profit margins forever. As it ignores the trend it risks creating a generation of smartphone users not in the Apple ecosystem. It's happening right now.

</comment><comment><USER13> Such a big deal is being made of this initial pricing strategy for the 5C when it's really such a transient situation.

Apple is going in with a high price on the 5C to keep the brand solid and scoop up profits from early adopters who will just have to have the latest pretty colored iPhone.

My guess is that the 5C's price will erode much faster than the 5S. Apple will do its best to balance the mix to ensure that the product is sold and out there.

<comment><USER14> This is exactly what I came here to say. This is another case of Apple skating to where the puck is going to be in maybe 2 or 3 years time.

There is no point in Apple introducing a brand new truly low cost iPhone because such a device would by necessity only be in the market for a short time before it would get obsoleted. The 5C is set to be manufactured for the next 3 years, so they will extract maximum scale effects and maximum sales volume over the lifetime of the device.

The 'C' may well stand for 'Cheap', but not now. It stands for where it will be positioned over it's lifetime. Other manufacturers bring out a new device and only care about it for maybe 6 months, after which they're on to the new thing and ready to forget the old one ever existed. Apple thinks really long term about their device's full economic life cycle.

For example the iPad Mini was criticism for being too expensive, but that was taking a short term view. I fully expect the current mini to continue to be manufactured at a lower price point for another year, cutting off the air supply to the cut price Android tablet market, but Apple is in no hurry to get to that point.

<comment><USER12> > This is another case of Apple skating to where the puck is going to be in > maybe 2 or 3 years time.

That phrase doesn't mean what you think it means. It has nothing to do with planning for a long product life.

"Where the puck is going" is towards affordable off-contract phones and cheaper carrier monthly costs. The 5C is Apple _doubling down_ on the carrier subsidy model. It's the model that makes the 5C seem competitively priced.

It's ironic because Apple is often credited as standing against carrier power, when in reality the status quo is exactly what will allow Apple to keep making those legendary profit margins on iPhones.

Once unsubsidized becomes the norm (as started by T-Mobile and now being adopted by others) they're going to be forced to compete on price at the expense of margins. They can stay exclusively on the high end if they want, but the high is going to be ~300-400 at most.

That's where the puck is going. Selling a 2012-grade 5C for competitive price in 2015 is not "where the puck is going".

<comment><USER14> >That phrase doesn't mean what you think it means. It has nothing to do with planning for a long product life.

It means acting now to best position yourself for the future.

I absolutely agree with you that affordable off-contract phones are going to be a big part of the future. Previous iPhones were premium products that were too expensive to manufacture for that to be viable, but the 5C is designed to be much cheaper to make. While it's selling at premium prices now it's far, far better positioned to become a strong medium end product in future.

</comment></comment></comment></comment><comment><USER15> The article text states the _exact opposite_ of its own headline:

 _"Under the old model the n-1 variant was meant to be a modest volume contributor to the portfolio, being essentially a cognitive illusion which encouraged buyers to stick with iPhone n at the expense of competitors. However, the new n-1 product (the 5C) has a distinct positioning that makes it seem fresh and not a lesser, stale version of the flagship. It is designed to appeal as a legitimate upgrade for iPhone 4 /4S users. It is, in other words, _not_ meant as an illusion, and not focusing attention on the flagship[3]. Rather, it is meant to be a genuine, core product."_

IOW, the iPhone 4 vs 4S was cognitive illusion, the iPhone 5C vs 5S is not cognitive illusion. So, C _is not_ for Cognitive Illusion.

Opposite headline is better link bait, though.

<comment><USER16> I think the reading was that this model is to address the old cognitive illusion. That is, the old n-1 model rested on a cognitive illusion to work. The argument here is that this model is to take that place. (Make sense?)

</comment></comment><comment><USER17> Obviously Apple is trying to turn the iPhone 5C into the plastic Macbook of 2006 - the best-selling laptop ever.

The MacBook was also more expensive than the competition, however consumers (even students) paid up.

Arguably the price difference wasn't as extreme, but I'd be surprised if Apple didn't lower the price to $499 or less, and announce a white+black models of 5C very soon.

However, I'd argue that the main reason consumers bought the Macbook was not the Apple brand, but the vast gap between OS X and Windows XP. They bought into the operating system, and that's what drove sales of other Apple products from then on, because after all, that iPhone/iPod works better with a Mac.

Fast-forward to now, Apple's competitor isn't MS Windows. It's Android, which doesn't cost a premium the way Windows did, and is arguably not inferior to iOS.

OS X was more "open" compared to Windows, and not just due to its Unix underpinnings. It didn't come with pre-packaged software and DRM restrictions, but it did come with better software. It didn't force you to consume content the Microsoft way, it embraced developers creating great apps like VLC without charging them.

No more. iOS is a walled garden, even more so than Windows ever was. Sure Google isn't a saint in that regard, and yet Android encourages competition. It has no issue with Amazon's Kindle app selling e-books. It has no issue with developers writing apps to replace "core functions". It knows that selling 10 units with a 10% margin is better than selling 1 unit with a 20% margin. It's thinking long-term.

I still love Apple for its design and attention to product detail, but if their greed and hubris continues to escalate, history may just repeat itself.

</comment><comment><USER18> Why is nobody talking about the camera improvements, the speed improvements, and the fact that this is the first 64 bit phone? The improvements to the 5S are actually dramatic, you just can't see them yet.

<comment><USER19> I'm wondering if those improvements will actually matter to customers - I'm seeing diminishing returns with respect to putting R&D money into phones.

<comment><USER18> A lot of the apps that you know and love wouldn't be possible without performance improvements. Of course customers won't notice the improvement directly, they'll notice in new software capability they previously didn't have.

</comment></comment></comment><comment><USER20> As Hacker News users we can all consider ourselves in the top N percent for technology product interest, so the iPhone 5C seems weird to us. It's plastic? It's how much? In those colours? With those specs? I was talking to my girlfriend and some friends who are distinctly not interested in the wonderful world of tech and to them the iPhone 5C does genuinely seem fresh (although pricing was a bit split). Apple's positioning the device to recapture the interest of a market who's been saturated with many devices.

<comment><USER5> I consider myself in that same top N percent for technology product interest, but I'm not at all confused about the 5c. Most smartphones, even flagship smartphones, are plastic, and some have spectacular build quality. The price is extremely competitive. I think the only complaints about price are influenced by the rumor that the 5c would be the _free_ subsidized tier. Ignoring that and looking at the 5c on its own terms, it's certainly a competitive $100 subsidized phone.

</comment></comment><comment><USER21> Wouldn't pricing a new iPhone (regardless of version) too low have a negative effect on the perceived value?

If the iPhone 5C had the same core components as the 5S I would get it instead because the plastic is probably more durable and I'd like a colorful device as a change of pace from the white and silver Apple products I own currently.

</comment><comment><USER22> A small point that's usually overlooked: assuming you're on AT&T, there's a ~$35 upgrade fee, $30 for a case, sales tax, and maybe an extra charging cable or other accessory. A $99 phone is more like $200 for the average person, so the comparison should be closer to $200 vs $300 rather than $100 vs $200.

<comment><USER23> You're not required to buy a case and accessories at the AT&T store. If someone is price conscious, they will know they can get it cheaper elsewhere. And I suspect a lot of people won't put cases on them since the shell is plastic and the color of the phone is a selling point.

</comment></comment><comment><USER24> Could just be a sales strategy. "The 5C looks tacky, the 5S looks much better and is only $100 more expensive!" And teenagers will probably go for the 5C, breeding a new generation that likes tacky smooth glossy plastic in bright pastel colors.

<comment><USER25> What's tacky today might be fashionable tomorrow. Fashion is very fluid.

<comment><USER26> Not quite as fluid as some people think. Gold has been tacky for a while now, at least in the states.

<comment><USER25> But it's wildly popular in other parts of the world. Apparently it's the number one color for aftermarket modifications of iPhones.

Look at the design of Sony products over the past 50 years. The design has changed radically. Heck, even look at the Apple design language over the past decade or so.

Things change. Everyone thought that OS X 10.0 looked very stylish at the time...now it looks dated.

</comment></comment></comment></comment><comment><USER27> Apple's problem is that they are only relevant in a handful of countries while competing in a global market. Android is crushing them.

<comment><USER28> It means that Bentley and Ulysse Nardin also have a problem.

<comment><USER29> And the car analogy still does not fly. A Bentley will work fine on the same roads a Volkswagen does. However, an iPhone will not run, say, Android apps. If Apple's marketshare drops under a certain percentage, it becomes less and less interesting to treat it as a first-class citizen.

<comment><USER30> Network effects are very important, however, for now Apple users outspend Android users by a very significant margin, so they can get by with a relatively low market share.

As long as the spending trend continues, developers will continue delivering products for the platform.

</comment></comment></comment></comment><comment><USER31> I think this opens them up to new experimentation at the top of the market. The 5C becomes the everyday model that suits the average consumer. The 5S will become the experimental super phone. Following on from this I would not be at all surprised to see a larger screen phone join the 5S as a high end lower volume model for those who can afford/want it.

</comment><comment><USER32> I think they decided they couldn't make the 5 any cheaper in the short term, so they changed their product cycle.

<comment><USER33> Is it possible that Apple will settle for lower market share as long as they retain a majority of the profits? I mean look at the PC market where Apple sells relatively few units but controls nearly half of the profit. What does it matter if you only control 10% of the market if you control 90% of the profit in the long run.

Of course the issue in this argument is the App store. You could argue that by building a huge user base could allow you to shift your profits from hardware to software in the long run.

<comment><USER34> I don't know if the numbers are hypothetical but Apple is probably going to have roughly 10% of the smartphone market this quarter, but they'll also have slightly less than half the profit share, which is some way off your 90% figure. And both numbers are trending down from their peaks of ~25% and ~90%.

I'd also look to Intel and Microsoft if I was wondering where the profit in the PC market went. I'm guessing your figures for PC profit don't include the little known Wintel duo?

</comment></comment></comment><comment><USER35> Agree that the purpose of the 5C is to keep margins up rather than grow market share.

The interesting relationship isn't between the price of the 5C and the 5S, it's between the price of the 4S and 5C. It seems to be targeting people who would have bought a 4S, not people who wouldn't have bought an iPhone at all.

</comment><comment><USER36> Interesting analysis. This shift in the number of flagship products might also give a fresh start to the brand in the mind of iPhone users. Now that everybody has an iPhone, "Think different" might regain some credibility if you start using the new, more than good enough iPhone 5S.

</comment><comment><USER37> Not really strange at all that the specs don't differ much besides the case. Apple has always done this. Make a minor change like flash memory size, and charge a heck of a lot more for the higher end version than the difference actually costs to produce. They retain an easy to develop for ecosystem by not having much difference and gain economies of scale on production. Whoever this is doesn't really know much about the computer industry. He probably doesn't even realize desktop processors are often produced as one model and cheaper ones just clocked down to create artificial differences which retaining efficiencies of only having to make one thing.

<comment><USER25> Actually, Horace Dediu is a pretty well respected writer who does know what he's talking about. Go read some of his past posts, they're pretty insightful.

<comment><USER34> But skip the ones where he predicts success for RIM and Nokia (this is pre- Windows Phone, which he predicted they would never move to), and failure for Samsung because the former are "integrated" and the latter is "modular" (even though they make their own silicon, screens, RAM, etc.).

And the one when he says Android will never have more than 15% of the market... (currently at 80%) and certainly never more than Microsoft (currently 3.7%).

And any when he mentions open source, which he doesn't understand at all.

</comment></comment></comment><comment><USER38> I dunno...assuming the original iPhone 5 would have been bumped down to the same price as the 5C is releasing as... I would rather have the iPhone 5.</comment>


Real Estate Developer Scam Could Skim 5 Percent Off Your Home's Value - <AUTHOR> http://www.alternet.org/economy/148441/sleazy_real_estate_developers%27_latest_scam_could_skim_5_percent_off_your_home%27s_value_/

<comment><USER2> This is slimy beyond reproach. Financial trickery like this should be seen as criminal fraud. It is items like this that make me think that this country could do with some stronger protection laws against consumer targeted financial instruments, and I use financial instrument is the lightest sense because in this case it is not one it is a fraudulent fee sneaked into the title, knowing full well that a consumer that does not work in the industry would know what a private transfer fee is or that it is a residual fee that is required with every transfer.

The financial snake oil in this country has to stop. Denying people their food or defrauding them of their money are two of the quickest was to push a populous to the brink of a revolution. I think that cliff is closer than many of us want to believe. Blatant abuse of people like this adds fuel to the fire of the growing discontent. I fear for the abuse that we allow people to suffer at the hands of the financial institutions, as I see every day it is adding voices to the discourse.

People are becoming radicalized and if anyone is looking for an example of why, here is an example in all of its immoral and predatory glory. These people should be ashamed of themselves, this is thievery whether technically legal or not. So now not only do we have to content with phone crammers tacking charges onto our phone bills but we also have to content with title crammers tacking recurring payments onto out titles. This madness has to end, people need to work for their money.

</comment><comment><USER3> The primary problem with this situation is that this kind of fee comes as a surprise. If the fee was known, you would demand a lower price for the property and the realtor would take some of the additional valuation when the property got sold. Sounds familiar? It should. That's basically a stock sale.</comment>


Ask HN: Jsfiddle.net down for everyone else or just me? - <AUTHOR> <comment><USER2> You don't need to ask HN, there are websites for that: [http://downforeveryoneorjustme.com/jsfiddle.net](http://downforeveryoneorjustme.com/jsfiddle.net)

</comment><comment><USER3> It's back again.

</comment><comment><AUTHOR> Getting 503 :(</comment>


Inside Danske Bank's 200B euro 'dirty money' scandal - <AUTHOR> https://www.cnbc.com/2018/10/03/inside-danske-banks-200-billion-euro-dirty-money-scandal.html <comment><AUTHOR> _Toward the end of 2013, an internal email changed everything. Entitled "Whistleblowing disclosure — knowingly dealing with criminals in Estonia branch", it was written by Howard Wilkinson, Danske's head of markets in Estonia. Its content was explosive. Detailing a "near total process failure", he referred to a UK limited liability partnership called Lantana Trade which had opened an account at Danske in Estonia the previous year._

 _Its account was marked "dormant" at UK Companies House and yet it had a credit balance at Danske of $965,418 on the same date. A colleague later told Mr. Wilkinson that the bank did not know who the beneficial owners were but "apparently it was discovered that they included the family of Vladimir Putin, Russia's president, and the FSB [Russia's intelligence service]", according to the email seen by the FT._

 _Danske 's internal audit team was sent to investigate the Estonia operation in January 2014. Yet Mr. Wilkinson complained in a further email in April that despite his warnings "no related client account has been closed by management" and "there appears to have been no attempt by management to identify the full scope of the problem of UK LLPs submitting false accounts"._

 _He reported that a senior executive told him "[Danske Bank] is not the police" and "[Danske Bank] has no obligation to report false client accounts to the authorities." That same day, he resigned and sent an email to Copenhagen, signing off: "Sad to say, it seems to me that things are totally broken here."_

Wow. So internal whistleblowing procedures are token efforts which are actually shortcuts to get yourself 'resigned'. I become less and less surprised when reality turns out to match Dilbert one-to-one. Which is sad.

<comment><AUTHOR> Another tidbit:

 _Questions have also been asked as to whether Danske received special treatment from its regulator, which was until May headed by the bank 's former chief financial officer._

I.e. the body that had sole responsibility to enforce anti-money laundering on the bank was its former CFO. SMH...</comment></comment>


Rtcl: embeds an R interpreter into Tcl - <AUTHOR> https://github.com/mattadams/Rtcl <comment><USER3> This is very cool. I have used Tcl from R - but this will fit my workflow better - awesome.

(and thanks for posting all the interesting Tcl projects to HN - <USER2> appreciated)</comment>


"Business and management majors were among the least likely to become self-employed" - <AUTHOR> http://www.scribd.com/doc/8037801/Baccalaureate-Education-and-the-Employment-Decision-SelfEmployment-and-the-Class-of-1993- <comment><USER2> Taken at face value business majors are surprisingly conservative. They're there because mom and dad told them it would be safe/smart, and in other cases because they couldn't think of anything else to study.

So it's in those impractical majors (e.g. philosophy) that you're more likely to find free-thinkers, idealists. And as it were, that's exactly the type of attitude you need to reject offers for safety, security, and fortune in the name of your own romantic idea about making a difference (but probably just losing your shirt).

Least that was my experience, and I'm a startup founder + recovering business grad.

</comment><comment><USER3> I think many students fantasize a future for themselves and for many it is a safe, steady, well paid job in business. So they think 'business studies'.

A lot of the most successful business men (and women) have come via unconventional routes. And these people often have their own company.

Conclusion? A successful business may be all down to luck.</comment>


Life Plan - <AUTHOR> http://spencerfry.com/life-plan

<comment><USER2> He "plans" to be CEO of Apple in 15 years' time. He thinks he'll be "on the radar" for this on the strength of

1\. a startup doing VoIP;

2\. another startup enabling designers, artists, photographers, etc., to put their portfolios online;

3\. another unspecified "game changing technology startup" he hopes to start, although he doesn't have any idea what it'll be.

I venture to suggest that this may not be very realistic.

<comment><USER3> "Shoot for the moon. Even if you miss, you'll land among the stars."

Les Brown

<comment><USER4> The Cynic: or, more likely, you'll end up drifting in space endlessly.

I actually agree with the sentiment though, it'd just be nice to have a saying that's a little bit more scientifically valid.

<comment><USER5> Technically, if you're in space you're among the stars, at least as seen from earth, even if you're actually far away from them, slowly using up all of your oxygen in a ship which will soon become your tomb.

<comment><USER4> In those terms, you're pretty much 'amongst the stars' even while on earth, as can be ascertained with a glimpse at the sky at night.

</comment></comment></comment></comment></comment><comment><USER6> "If you want to make God laugh, tell him about your plans" :)

Even though I'm not religious, I think this is true, especially with respect to startups.

<comment><USER7> True enough, but you've got to love his ambition! He's twenty-five, it's all in front of him. (Of course a lot of HN'ers are probably around that age anyway.)

Plans are useless, planning is essential.

</comment></comment><comment><USER8> It's always refreshing for me to hear about other startup CEOs talking about investing more than 2-3 years in a web startup, thanks for that. We're coming up on year 2 of our venture. We're making money, but we haven't broached 6 figures yet it sometimes feels like we're a failure. When we got into this, it was supposed to be a 1-2 year commitment, now it looks more like a 4-6 years. At least it's still fun!

</comment><comment><USER9> now write out a detailed plan on how to achieve it or it will just be a dream and never be achieved.</comment>