Seven deadly sins of talking about "types" (2014) - <AUTHOR> http://www.cl.cam.ac.uk/~srk31/blog/2014/10/07/ <comment><USER3> I think the argumentation here is a bit a skewed towards 'what static types can and cannot do for the compiler' \- i.e. how they can help the computer in constructing formal proofs. For me another almost as valuable thing is how static types help _me_ think about and design the code. The static type information is always there to remind "this entity belongs to this set of objects" which frees me from the cognitive burden of maintaining this constantly in my working memory. With specific static types the function signatures now document the tranforms defined for those entities . This aspect of static types as a cognitive tool is highly personal, and not same for everyone, unlike the language and the compiler, though.

</comment><comment><USER4> > It's also nothing to do with static checking—"type safety" holds in all > "dynamically typed" languages.

This. Exactly true, and often forgotten.

It's useful here to distinguish between conversions and casts. Conversions use type information to ensure computations remain sensical; the canonical example is a conversion between integers and floating-point values which makes sure you never end up feeding invalid bit patterns into the relevant arithmetic hardware. An example of a cast is taking a bit pattern you _had_ been treating as an integral value and then telling the language it's a floating-point value, and there not being an error at that point.

 _Conversions don 't break the type system; they use the type system._ Casts throw types away.

<comment><USER5> Casts don't only throw types away, they can also add type information to otherwise untyped input, such as reading data from a file or an HTTP request payload.

<comment><USER4> > Casts don't only throw types away, they can also add type information to > otherwise untyped input, such as reading data from a file or an HTTP request > payload.

This is true. A more interesting example might be a program which creates database queries from user input _casting_ input strings to the type "unescaped string", and then _converting_ them to type "escaped string" by performing a string-escaping process on them. (A _cast_ from "unescaped string" to "escaped string", which is done implicitly very often in languages where those types are not machine-checkable, is often disastrous.)

<comment><USER5> Right, but I don't think this sort of type "conversion" (e.g. some function with type signature like this in Haskell)

        escapeQueryString :: ByteString -> Query

is really adding or throwing away type information, it's just a function that accepts one type and returns another type. So it's not related to casting, except that it's the _opposite_ of casting. But what that gives you is the ability to compose it with any other function that you define as accepting a `Query` type, and the program will refuse to compile if you ever accidentally try to pass it a ByteString. So it's about enforcing an invariant, in other words.

</comment></comment></comment></comment><comment><USER3> This topic of "what are static types good for" continued to bug me because I could not formulate a concrete answer to myself. I found the following Reddit discussion

[http://www.reddit.com/r/programming/comments/lirke/simple_ma...](http://www.reddit.com/r/programming/comments/lirke/simple_made_easy_by_rich_hickey_video/)

Which had eventually the specific thing I was after in a comment by Rich Hickey which helped to nail the concept I was after

"Statically typed programs and programmers can certainly be as correct about the outside world as any other program/programmers can, but the type system is irrelevant in that regard. The connection between the outside world and the premises will always be outside the scope of any type system."

Which is precisely why I enjoy types: Self referential consistency makes sure I do not make errors within the logical model I have set for myself. It does not help me build better models but once those models are built it helps me to compose programs that do not break the invariants in the chosen formalism.

Which, I think tells exactly what static types are good for: For those sort of problems that benefit from having a formal specification. There are a lot of programs that have this quality.

So the argumentation is a bit skewed off. It should not be about whether static or dynamic types are better but more focus on what are those identifiable problem patterns where a dynamic type system helps programmer create more value than a static one and vice versa.

<comment><USER6> > Self referential consistency makes sure I do not make errors within the > logical model I have set for myself. It does not help me build better models > but once those models are built it helps me to compose programs that do not > break the invariants in the chosen formalism.

I think this is a valid point.

But I am less convinced about the second part. I feel that better type systems do help one model the world better (while retaining the consistency checking that you mentioned). In my mind at least having more/better "type tools" is like having differently shaped pieces in your lego tool box. You _can_ create better models for yourself, because the pieces allow you to. And the more experience you have with them, your modeling abilities also improve.

</comment></comment><comment><USER7> I emphatically reject the many of the conclusions of this article.

>Let me say it simply. Type systems cannot be a one-stop solution for specification and verification.

Wrong! Any correctness property can be encoded into a sufficiently powerful type system. Which brings me to...

>Curry-Howard is an interesting mathematical equivalence, but it does not advance any argument about how to write software effectively.

This is absurd, of course. The isomorphism between type systems and proof systems allows us to build lots of impressive systems like Agda and Coq.

>No sane person can argue that we want to bifurcate a programming language into distinct base-level and type-level fragments.

That's actually quite a reasonable desire.

>Personally, I want to write all my specifications in more-or-less the same language I use to write ordinary code.

To the author, this seems to mean "therefore, we shouldn't have types!". In reality, a sufficiently flexible programming language allows you to write type-level code in the same language as value-level code. See Agda.

>Rich Hickey's transducers talk gave a nice example of how patterns of polymorphism which humans find comprehensible can easily become extremely hard to capture precisely in a logic.

Lots of people have typed transducers just fine... [http://blog.podsnap.com/ducers2.html](http://blog.podsnap.com/ducers2.html) [http://conscientiousprogrammer.com/blog/2014/08/07/understan...](http://conscientiousprogrammer.com/blog/2014/08/07/understanding- cloure-transducers-through-types/)

<comment><USER8> > >Let me say it simply. Type systems cannot be a one-stop solution for > specification and verification.

> Wrong! Any correctness property can be encoded into a sufficiently powerful > type system.

I'm writing a factorial function. But, because the caffeine hasn't kicked in yet, at the recursion step, I add one instead of subtracting one. The result is that the program will run in an infinite loop until either the fixed-size Int rolls over to 0, or the bignum-style integer consumes all available memory. That's certainly incorrect behavior. But I'd like to see your "sufficiently powerful type system" that will handle that.

Then there's numerical accuracy. Here the results are not "wrong wrong", they're just "a little bit wrong" or "less accurate than they could have been". Again, I'd like to see your type system detect that.

In my world, embedded systems, you can get hard-real-time situations, which means that the right answer, too late, is wrong. I believe that there are formal verification tools, but they don't look anything like a type system. And even those tools depend on a very deep knowledge of the processor that the code will be running on ( _not_ compiled on). Once more, I'd like to see your type system that's going to handle this.

> > Curry-Howard is an interesting mathematical equivalence, but it does not > advance any argument about how to write software effectively.

> This is absurd, of course. The isomorphism between type systems and proof > systems allows us to build lots of impressive systems like Agda and Coq.

And if Agda and Coq were being used to write much software, you'd have a point. But if I understand correctly, they're mostly used for automated proofs. The point is that the program compiles, and therefore something is proven. The point isn't to get a runnable program.

<comment><USER9> > The result is that the program will run in an infinite loop until either the > fixed-size Int rolls over to 0, or the bignum-style integer consumes all > available memory. That's certainly incorrect behavior. But I'd like to see > your "sufficiently powerful type system" that will handle that.

I believe that Agda could do this.

</comment></comment></comment><comment><USER10> I have always gotten the impression there was a failure of communication when (without lose of generality) Haskell programmers would tell (also, without loss of generality) Python programmers that Python only has one type, 'object', which appears to violate the understanding of the Python programmer thoroughly enough that there isn't really even a conversation about what is meant by the comment.

The first point dissolves this conversation (because clearly neither the Haskell nor Python programmers are confused about the execution of actual programs). Notably, it dissolves it in a way where that pesky third issue doesn't pop up (which is perhaps the worst of them all, sans _maybe_ the last).

<comment><USER11> Well, that's an interesting comment. I have almost a decade experience in Python, and having recently picked up Haskell, I clearly see the value of having (or not) a static type system.

I have noticed that during all these years I would just "type-check" the various APIs in my mind, or with the aid of the REPL, but it's not as easy when programmers with less experience join the project. I would often have to explain tracebacks about type errors (e.g., tried to call a missing method on `None`, but the programmer didn't expect that API to return `None`). Strong typing avoids errors from propagating, but without static checking only gets you half-way there.

I would still use Python (or other dynamic language) to introduce someone to programming - not having to reason about types lowers some barriers - <USER2> nowadays I'm not sure it pays off for a project expected to be maintained.

<comment><USER12> I was always on the fence about static typing because I figured that it automatically led to more verbose code (clearly a significant down side), but after looking at Haskell and F# I'm not so sure that's true for them, even though it definitely is for C++ and Java.

I'm still unconvinced that additional testing is required to overcome bugs that a static type checker would catch, though. In my experience all of those "call a missing method on None" issues get caught relatively quickly by a test that you would have to write anyway even if you were using a language with static typing.

<comment><USER13> > In my experience all of those "call a missing method on None" issues get > caught relatively quickly by a test that you would have to write anyway even > if you were using a language with static typing.

There are lots of bugs that you still have to test for in a language with a typesystem like Haskell's. But it's not this class of bugs. Pattern matching (and completeness checks) should take care of that.

<comment><USER12> I know, but my point was that in my experience _this_ class of bug is nearly always a problem at its heart in requirements anyway (i.e. an unspecified edge case), meaning you _have_ to test it in whichever language you use to be confident of the program's correctness.

E.g. you'll still need to write a test for your haskell code to determine that the behavior is correct if the IP address is missing, and in your python code if you don't specify behavior it is the kind of thing that will likely lead to one of those nasty "cannot call a method on none" errors.

Since the act of testing _which is necessary anyway_ catches it or confirms correct behavior, the additional benefit of a static type checker confirming the presence of such a bug is perhaps lower than it might appear at first glance.

This is clearly _not_ true of weakly typed languages where you have to write a myriad number of extra tests just to achieve the _same_ confidence in your code to cover all the unexpected use cases caused by weird type conversions you didn't even realize you were doing.

<comment><USER14> I believe eru's point was that those kinds of tests are not necessary in Haskell because if a function takes something of the type IpAddress, None simply isn't possible. So everywhere IpAddress is used, you don't have to do any of those tests.

It sounds like your point is that even in Haskell there will inevitably be boundaries where the None case is an issue. And that's true, namely the point where you call:

        parseIpAddress :: String -> Maybe IpAddress

Somewhere your app will be sucking in a string and you need to have a test for the empty string case. That's true. But the surface area of the application that is susceptible to this problem is reduced (often dramatically). All code that works with IpAddress is free and clear. Whereas in most other languages, _every_ function that takes an IpAddress probably needs to be tested with the None case. If you try to argue that you don't need to test every one, then you're plagued by the difficulty of knowing which need it and which don't. Haskell's types solve that for you completely.

<comment><USER12> I get the point, but I still feel like the problem surface is not really reduced that much by static typing it away, and the bulk of the problem is simply moved elsewhere rather than solved outright since the root of these issues is incorrect specification anyhow.

As in, I take issue with the word "dramatic", not the word reduce.

Additionally - it might just be my python bias talking - but I tend to find that most useful "real-life" libraries need to have an opinion about what happens when a variable is None, because it is almost always meaningful. I guess if I were writing haskell my code would end up looking like a bad carly rae jephsen song :)

<comment><USER14> > I get the point, but I still feel like the problem surface is not really > reduced that much by static typing it away

Ok, that's a valid point, which means that we need to precisely characterize what is meant by "problem surface". Let's continue with our IpAddress example. Imagine you are the author of the IpAddress package. Imagine we have an IpAddress type accompanied by an API of say 15 functions that take an IpAddress and do something with it. How many of those functions need to have tests that cover the case of passing None? I believe that number represents our problem surface.

If you agree that this is the problem surface, then I can confidently say the reduction is dramatic. (If you don' agree, then I refer you to the previous point about Maybe making it very clear what needs None tests.) The Python IpAddress package has to have None tests on every single function that takes an IpAddress. The Haskell package has to have None tests on zero. It only needs the equivalent of a None test on the functions that return a Maybe IpAddress. This is going to be a very small number. This brings us to your other point.

> Additionally - it might just be my python bias talking - but I tend to find > that most useful "real-life" libraries need to have an opinion about what > happens when a variable is None, because it is almost always meaningful. I > guess if I were writing haskell my code would end up looking like a bad > carly rae jephsen song :)

I'm pretty sure this is indeed largely caused by your Python bias. In my experience, Haskell code does not end up littered with Maybes. I think you don't appreciate the full weight of the statement that when you have an IpAddress, you _never_ need to worry about the None case. Never ever. Period. There are cases where you need to deal with a Maybe IpAddress. Those cases don't end up polluting all your code, contrary to what you seem to think. In fact, it's the other way around. The pure cases tend to be the ones that are the most common, making the Maybe cases clearly visible.

Even in the situation where they do start to pollute some things, Haskell gives you dramatically better tools for dealing with the problem. Yes, you'll still have to have a test for it, but the code you're testing will have been much more concise and less prone to error. Furthermore, Haskell can make it so you don't even have to think about testing that case. You write an Arbitrary instance for IpAddress and the Arbitrary instance for "Maybe IpAddress" comes for free! This means that your QuickCheck test for the Maybe IpAddress function will automatically be sure to try it with Nothing.

From what you've said it is clear to me that your python bias is somehow making it hard for you to see/believe the benefits that we're talking about. I'm concerned that this gap seems to be so big and we seem to be having such a hard time crossing it. Give Haskell a try and see for yourself. But don't go off into a cave and play with it alone. There are abstractions and best practices for dealing with some of these things that took awhile to emerge. So you should be sure to talk to people who have experience using them while you're learning.

<comment><USER11> > I'm pretty sure this is indeed largely caused by your Python bias. In my > experience, Haskell code does not end up littered with Maybes.

I think the Maybes and other optional/sum types tend to be limited to the boundaries, where you do IO or handle errors, while your internal functions can deal with the concrete type. A code base littered with Maybes is certainly a code smell.

<comment><USER9> > A code base littered with Maybes is certainly a code smell.

It's not because Maybe (and usually more practical Either) have functor instances. What this means is you can use fmap to apply pure functions to Maybes, Eithers, or any other type that has a Functor instance.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I'm going to make a few comment and nitpicks.

"Patronising those outside the faith ... Please drop the condescending tone."

This is a great sentiment, but rather jarring to have it followed up by "No sane person can argue that we want to bifurcate a programming language into distinct base-level and type-level fragments".

"Equivocating around "type-safety""

Surely it's reasonable to use the terminology "type safety" to describe a range of properties that code may have beyond the (supposed) original meaning of "memory safety".

"If everyone would just use a modern language with a fancy type system, all our correctness problems would be over, right? ... Type systems cannot be a one-stop solution for specification and verification."

This is an enormous straw man. No fan of strongly typed languages claims that they solve all correctness problems. Furthermore, the fans of strongly typed programming are the most likely to appreciate the additional forms of verification that Stephen outlines.

<comment><USER8> > This is an enormous straw man. No fan of strongly typed languages claims > that they solve all correctness problems.

I have read the claim "If it compiles, it works" (or minor wording variations), on this board, more than once (in reference to Haskell). Fans of strongly typed languages do in fact make claims that sure sound like they are saying that.

<comment><USER16> It's said semi-tongue-in-cheek. The original statement was _filled_ with caveats. [0]

Sometimes it's said _less_ tongue-in-cheek. Then it usually has to do with the facts that large refactorings can be handled by merely breaking things and rewiring until types check. This generally _does_ work since types typically guard "wirings".

But taken out of contexts and as the meaning is extended bit by bit it becomes truly ridiculous and nobody would disagree.

So, don't just propagate the rumor. Nobody is claiming miracles. It just sounds like that at around the 8th iteration of the telephone game.

[0]: As far as I'm aware, this is the origin of the idea: [http://r6.ca/blog/20120708T122219Z.html](http://r6.ca/blog/20120708T122219Z.html)

<comment><USER17> The origin is definitely further back. I recall hearing "it takes longer to get it compiling, but when it compiles it works" about OCaml more than a decade ago. When I mentioned this to my father at that point, he remarked that the sentiment goes back further.

<comment><USER18> It goes back to discussions on Ada as well. I, personally, qualify my advocacy with a probably. As in, "if it compiles, it's probably correct."

<comment><USER17> I wouldn't be terribly surprised if he'd been thinking of Ada evangelists, though I think there are other candidates too. Unfortunately, I can't ask him to clarify...

</comment></comment></comment></comment></comment></comment><comment><USER19> The coda at the end is nice tool in general. Whenever you find yourself in a discussion, where it seems people talk past each other because some words have a fuzzy meaning, try to avoid the word completely. Works good for discussions about "free will", "love", "intelligence", "luck", "conciousness", and apparently "types".

<comment> pseudonom- [http://lesswrong.com/lw/nu/taboo_your_words/](http://lesswrong.com/lw/nu/taboo_your_words/)

</comment></comment><comment><USER16> With deference to Dr Kell, I think this is overwrought.

He has some good points, points made happily against a particular form of "type cultist" who oversimplifies argument toward making types out to be something magical. They're not, no sane person would think so, but they are _a static, syntactic proof system pertaining to the meaning of your programs_ and there's a lot to be said for such technology.

I am happy to quibble exact points made in this rant, but I'm on my phone so for now I'll merely say that there's a large design space of programming languages and a similarly large (perhap today larger) space of type theories. Matching them up to hit all of your tradeoffs is hard, but there have been some great successes and I would happily contend that any professional programmer owes it to themselves to explore this design space "in anger".

I'm also happy to generally claim that faster, more complete feedback is better than the opposite. Static systems of all regards are faster than "dynamic" ones, and most of them are more complete. This is where you hear about comparisons of types (especially dependent ones) and tests. It's _great_ stuff to think about and explore.

Further, I want to emphasize that SMT solvers are fascinating too and nobody thinks that they're not. The style of proof they provide is more expressive and less certain, though, so the right answer is to know how to combine all of these modes of evidence.

</comment><comment><USER20> > Type checkers are one way to gain assurance about software in advance of > running it. Wonderful as they can be, they're not the only one.

This is true, but in my experience they are far and away the most common and easily tooled _automatic_ way. Tests may run automatically, but they must be manually written, and static analysis tools are not (yet?) very widespread.

</comment><comment><USER21> No, I think a separate type-level language is a _good_ thing, so long as my data-level language remains Turing complete (and thus undecidable). I would much rather be forced by the syntax -- by the construction of the language itself -- into a guaranteed decidable subset, rather than have to reason things out myself and get frustrated when the compiler doesn't agree with me (or when it used to agree with me and doesn't any longer!).

Now, there's no reason that the type-level language can't be exactly a subset of the data-level language. I'd just rather not play guess-and-check decidability with the compiler the same way I currently have to play guess- and-check optimizability.

<comment><USER13> There are good arguments for not even getting Turing-completeness in your value-level language. Totality would be a nice goal.

See [http://blog.sigfpe.com/2007/07/data-and- codata.html](http://blog.sigfpe.com/2007/07/data-and-codata.html)

<comment><USER21> Oh I totally agree. Unfortunately for many that's far too radical a notion, despite how unnecessary Turing-completeness is for 99.95% of programs written, and how desirable termination is. First you have to convince the Ruby/Python/JS/Elixir crowd of the frivolity of code mutability.

</comment></comment></comment><comment><USER22> > The Sniveley/Laucher talk included a comment that people like dynamic > languages because their syntax is terse.

Sure. Trying to have a strongly-typed Java program, for instance, means a lot of boilerplate. As a consequence, it's often not done, or at least not done enough.

> To suggest that any distaste for types comes from annotation overhead is a > way of dismissing it as a superficial issue.

On a large codebase, there is nothing superficial about it. The more boilerplate you have, the more difficult it becomes to understand the codebase and to find code which actually does something.

> If everyone would just use a modern language with a fancy type system, all > our correctness problems would be over, right? If you believe this, you've > drunk far too much Kool-Aid. Yet, apparently our profession is full of > willing cult members. Let me say it simply. Type systems cannot be a one- > stop solution for specification and verification. They are limited by > definition. They reason only syntactically, and they specify only at the > granularity of expressions. They're still useful, but let's be realistic.

Let's be realistic, and not pretend this is a widespread opinion.

> Rich Hickey's transducers talk gave a nice example of how patterns of > polymorphism which humans find comprehensible can easily become extremely > hard to capture precisely in a logic. Usually they are captured only > overapproximately, which, in turn, yields an inexpressive proof system. The > end result is that some manifestly correct code does not type-check.

Possibly, but it's all a question of tradeoffs. There is a lot more incorrect than correct code which doesn't typecheck.

<comment><USER23> > On a large codebase, there is nothing superficial about it. The more > boilerplate you have, the more difficult it becomes to understand the > codebase and to find code which actually does something.

In case of types it's true for humans. IDE will be able to build a very precise model and ease navigation and code changes when it understands types.

<comment><USER24> Why should this be a property of the IDE and not the language itself?

No, seriously. If the language sucks but your interaction with the IDE is fine, why not have a language that is closer to your interaction with the IDE to begin with, and use a text editor?

<comment><USER22> It's the old "verbose getter and setters are not a problem because I can generate them in Eclipse" argument. To some extent, over-reliance on an IDE indicates issues with your language of choice, just like the overuse of design patterns.

</comment></comment></comment></comment><comment><USER25> Things that also get my goat (from a less type theoretic point of view):

\- Assuming that type checking is the only thing you might want to do with your program at compile time. There are, in fact, arbitrarily many things you might want to do at compile time. Textual preprocessing, expansion macros, type checking, C++ template metaprogramming, etc. are all obvious examples. The fact that most languages bolt all of these things on as one-off features is a sign that something deeper is being missed (perhaps the 3-Lisp[1] idea, for example, or just consider plain ol' Lisp macros).

\- Assuming that totality, soundness, and lack of side effects are always type checking virtues. Sometimes I'd like a "typechecker" that isn't always guaranteed to terminate. Sometimes I'd like my typechecker to launch some missiles. This is really more about the previous point.

\- Assuming that type checking is NOT desired at runtime. Sometimes it is. Clojure's core.typed has the property that it is "just code" and can therefore be run at anytime and used for things other than checking that your code is safe to ship. [2]

\- Assuming that a program that fails type checking shouldn't be run. Maybe it should and the parts of the program that fail type checking should be run inside some monadic context. Maybe we want not only gradual typing, but gradual enforcement. Maybe if we had richer type data, then "failing type checking" wouldn't be binary. Perhaps a program that fails certain type checks has to add runtime support to enable certain features, but if the same program type checked to be about pure memory locations, the runtime would vanish and a "straight to the metal" program would remain. (In other words, maybe what we currently call a language's "runtime" should just be a residue of things that couldn't be checked at compile time, among other things.)

\- Assuming that types and the type checker should be a fixed feature of the language. Perhaps type checking should be something that is built as a library from language primitives. Take this far enough and you get something like exotypes. [3] Which reminds me...

\- Assuming that "type" is the only kind of metadata you might like to attach to a symbol, expression, or value. There are many other things I might like to express, and I might like to use the usual machinery of type checking to analyze or work with those things. Clojure's value-level metadata and Common Lisp's property lists are some good examples of generalizing this.

\- Focusing on manifest typing for verifiability of programs and ignoring the extra information it gives tooling. Visual Studio's IntelliSense and F#'s type providers are examples. At least one person at Microsoft has trouble sleeping at night because he or she is worrying about when the rest of us are going to figure this one out. [4]

\- Assuming that most programmers want one or the other. The article touched on this, but I wanted to expound a bit. I would like my original prototype to feel like play-doh and my finished product to feel like concrete. Why do I have to do this in two different languages? "Oh I'll prototype it in python and then switch to Haskell when I want it to be safe." What?

\- In general, assuming that it is the job of the language designer to provide the safety nets, rather than the DSL or API designer. A suitably designed programming language is one that could prevent operation Foo in layer 3 while allowing it in layers 1 and 2. This is one reason why languages like Idris are so complicated. Dependent types HAVE to be complicated because the language designer feels that it is his or her job to make sure the part of your program that runs at compile time terminates and doesn't do anything "bad". Why do we rarely question this assumption?

[1] [http://lisp-univ-etc.blogspot.com/2012/04/lisp-hackers- pasca...](http://lisp-univ-etc.blogspot.com/2012/04/lisp-hackers-pascal- costanza.html)

[2] [https://github.com/clojure/core.typed](https://github.com/clojure/core.typed)

[3] [http://dl.acm.org/citation.cfm?id=2594307](http://dl.acm.org/citation.cfm?id=2594307)

[4] [http://blogs.msdn.com/b/dsyme/archive/2013/01/30/twelve- type...](http://blogs.msdn.com/b/dsyme/archive/2013/01/30/twelve-type- providers-in-pictures.aspx)

<comment><USER9> > Sometimes I'd like my typechecker to launch some missiles.

You'd like missiles to be launched at compile time?

<comment><USER25> Doesn't everyone? ;-)

<comment><USER8> Of course. It's called "launch on warning".

;-)

</comment></comment></comment></comment><comment><USER26> Perl 6 elegantly blends static nominal typing and arbitrarily loose or tight dynamic constraints.

The following slides were published a week or so ago and should demolish most folks' overly simplistic view that one or other is best or indeed that they don't play well together:

[http://jnthn.net/papers/2015-fosdem-static- dynamic.pdf](http://jnthn.net/papers/2015-fosdem-static-dynamic.pdf)

</comment><comment><USER13> > (It should also do so using a straightforward explanation, ideally featuring > a counterexample or stripped-down unprovable proposition. I don't know any > type checker that does this, currently.)

I guess the incomplete-pattern-matching warnings (in eg ghc) come closest. They usually give you an example of an example of a value you haven't matched. But that's a very restricted and simple domain.

</comment><comment><USER27> > If somebody stays away from typed languages, it doesn't mean they're stupid, > or lack education, or are afraid of maths. There are entirely valid > practical reasons for staying away. Please drop the condescending tone.

Well, ok, let's hear these practical reasons?

Otherwise, it's just an empty claim.

<comment><USER13> Legacy code (and skillsets) are always a good practical reason.

</comment></comment><comment><USER28> The hardest objective problem in computer science may be P ?= NP, but the hardest _subjective_ problem is whether it is better to have static vs. dynamic typing in languages. There are extremely intelligent, thoughtful people on both sides... and it's rare in software engineering that there is such an even divide. I'm quite familiar with Haskell, Scala, Clojure, and many other languages... and I still can't conclusively call one better. I prefer static, on a mix of practical grounds, but I realize that it's not a clear victory.

Take the concept of data frames from R, also seen in Python's Pandas library, and probably inspired by the APL family's (column-oriented) tables. It's not a complex concept. Yet it's very powerful for interactive data exploration. It's also a bitch to statically type (see: [https://github.com/acowley/Frames](https://github.com/acowley/Frames)). It's more of a leap than lenses (and probably, like lenses, extremely cool once you fully "get" it).

If we have to pull out some advanced Haskell extensions to do something basic in _interactive data analysis_ then I consider that worrying. (This is not to say that Frames isn't a great piece of work. Bringing subtyping into a Hindley-Milner derived language and not having everything go to hell is really hard. See: Scala) And remember, this is coming from someone who's pretty invested in the "static" side.

Clojure also has a world-class aesthetic sense. Haskell is still using camelCase. OCaml uses under_scores; that's better than fuckingUglyCamelCase, but not ideal. Clojure (and the Lisp family in general) is run by people who realize that aesthetics are really important and that allowing hyphenated- tokens is far better than allowing people who hate their space bars to write "a-1" when they should be writing "a - 1". That's just one example. For another, maps. Clojure has {"five" 5, "ten" 10} but Haskell has fromList [("five", 5), ("ten", 10)]. My point is that (which I prefer Haskell, for its types) Clojure's aesthetic sense is arguably better, and I would say world- class, especially considering that it runs on a butt-ugly platform (JVM) and is still a beautiful language. We need to keep watching that community closely because they're doing some great work in a wide variety of fields, including front-end development (ClojureScript).

 _Type systems don 't just make you write annotations; they force you to structure your code around type-checkability. This is inevitable, since type checking is by definition a specific kind of syntactic reasoning._

There is some truth around that. Just to get data frames, you need row types which means you have subtyping, and that complicates type checking considerably. Haskell (see Frames) uses multiple "experts only" language extensions to get something that "just works" for casual use but requires advanced knowledge to grok the types. It's great work, but its difficulty shows that we can't just ignore subtyping.

The counter-argument that I'd make is that 95+ percent (maybe more?) of all functions that are ever written _ought_ to have simple static types. So much of code, when it is clean, is already well-typed, even in a dynlang. The difference is that, in a static language, the compiler yells any time someone fucks that up in refactoring. And, more generally, you learn about errors (not all errors, but a surprising percentage of them) sooner and that's a good thing. In a dynamically typed language, you see a lot of functions that evolve into multimethods that do different things per input type(s) and (although usually this won't happen if the code is maintained by decent designers) you can get O(n __2) or worse complexity in the functionality. If you 're programming defensively in a dynlang, you have to think about all the crap that might be passed into your functions. "What's a Matrix plus a Scalar? How about a RowVector plus a ColumnVector? How about a Sparse2DArray plus a DataFrame?"

On the whole, I'd rather be in a statically-typed language for a program of any size, and I'm stodgy and conservative and old (but efficient and concise) so, for me, "big code" starts around a couple thousand lines. I hate writing boilerplate unit tests that a compiler and a type system would knock out automatically. But I do have to give Clojure a lot of props for its community and its aesthetic sense, and I think that the above obviously derive from its ease-of-use and its Lisp heritage, both of which are tied to a feature (dynamic typing) that I otherwise wouldn't much like.

The main question that I've been pondering for a few years (and not coming to satisfactory answers) is whether it's possible to unify the cleanness-of- language and aesthetics of Clojure/Lisp with the static typing of Haskell... and not get some hyper-complex type system that results in compile-speed problems at scale (e.g. Scala under typical use). It's an open problem.

</comment><comment><USER29> I found this wonderfully clear and refreshing and I felt hopeful for the future of programming. In the meantime, it's just nice to see that not everyone is a shambling cultist, repeating canned talking points they read on a wiki which affirm to them that their own choice is the very best choice possible.

<comment><USER30> It's fair to say that but it isn't the case that someone can have an worthwhile opinion of something they haven't tried and a lot of people working with say JavaScript or PHP just have never tried a decent ML-style language in anger.

I think Stephen is a tiny bit guilty (as we all are) of that which I'll use Kahneman wording's to put: "Nothing is as important as you think it is when you are thinking about it". There's what seems to be an exaggeration that whatever cost a type system has must be high... it isn't even true of dependently typed programming languages.

I also think product and sum types can be given a free pass to most complaints and while at it, you can throw in first-class function type as a minimum. And I will grant that you can stay away from ad hoc polymorphism and subtyping.

<comment><USER31> > It's fair to say that but it isn't the case that someone can have an > worthwhile opinion of something they haven't tried

I disagree. I don't have to try hitting myself in the head with a hammer to have a reasonable basis to believe it would be a bad idea. There's not much point in having reasoning ability if you can't apply it to develop useful opinions on what is and isn't even worth trying.

Obviously, that's not to say that there aren't _additional_ insights possible from direct experience, and that people sometimes apply prejudice _rather_ than sound reasoning to present opinions on things they haven't tried, but its simply silly to say that people _cannot_ have a worthwhile opinion on something they haven't tried.

<comment><USER8> I think you're misunderstanding davidgrenier's comment, specifically the line you quoted. It appears to me that you are actually agreeing with him.

<comment><USER31> There may be an "is -> isn't" or "can -> can't" issue in the line I quoted, but I don't think so -- the rest of the sentiment in that article seems to be a specific case where the poster believes that someone is making an error of offering an opinion without experience (which I agree is an error), which makes sense (though, I'd obviously argue, represents an overgeneralization from a valid example) if its supporting a generalization that opinions without experience are invalid, but, without some "but" or "on the other hand", etc., doesn't make a lot of sense if the thesis it goes with is that _some_ such opinions _are_ valid.

So I don't think I misunderstood it.</comment></comment></comment></comment></comment>


ChezWEB: Hygienic Literate Programming for Chez Scheme - <AUTHOR> https://github.com/arcfide/ChezWEB <comment><USER2> Aaron Hsu, the author, is now a complete APL (Dyalog) advocate. I similarly have gone from Lisp to J, and now APL. I read the book "Mr. Babbage's Secret: The Tale of a Cypher and Apl". It is more of a history narrative melding a few things together, but it got me back on the array programming languages. I find it is true, that a single page of code is easier for me to rework when I need to review/edit it than pages of well-documented code (Python, C, or other). Racket is now being implemented in Chez.

<comment><AUTHOR> 'arcfide completed his thesis just the other day! It was really interesting. Have you read it?

<comment><USER2> I downloaded it, but compiler design is not my area. I do like his talks and he champions Iverson's Notation as a Tool of Thought very well. I hope to read it over the holiday.</comment></comment></comment>


LEGO Robot Solves Any Rubik's Cube In Less Than 12 Seconds - <AUTHOR> http://singularityhub.com/2010/02/17/lego-robot-solves-any-rubiks-cube-in-less-than-12-seconds-video/

<comment><USER2> This has been submitted before, as a simple search will show: <http://searchyc.com/rubik+lego?sort=by_date></comment>


30 days of tvOS sales numbers - <AUTHOR> https://medium.com/@CoryDMC/30-days-of-tvos-sales-numbers-6775814adc41#.h0sfc3z34 <comment><USER2> Serious question, would anyone expect to have much in the way of sales for a dice rolling app or a stock gif collection on any other platform?

<comment><USER3> I'm stunned he got any purchases at all. Who would pay for an app to roll dice on your TV set? The purchases were probably accidental.

Aside: I always get a kick out of how these posts have to mention the very small number of hours that were spent making the simple app. I bet it was actually more.

<comment><AUTHOR> People who want to play board games, but have lost their dice. It's a small market, but I think I've cornered it.

<comment><USER3> Did you release a smart phone version too?

<comment><AUTHOR> No, that market is already saturated. ;P

</comment></comment></comment></comment></comment><comment><USER4> _These download numbers are depressing, and I, like most developers who have tvOS apps, blame discoverability. What that means is that there are just too few ways for users to find or be shown tvOS apps_

Seriously? "Hey I threw together a couple of apps in a few days and they're not being downloaded. Obviously not enough folks are discovering them".

Apps for these types of platforms are hard. But most folks want to watch video (or play games) on their TV. They don't want to roll dice, or view Gif slideshows.

<comment><USER5> The App Store is shit for discoverability - and I suspect the lack of an easy keyboard makes it even worse on Apple TV.

But even if the discoverability were top notch, this still wouldn't be discoverable. Does author seriously expect a properly functioning app discovery engine to prominently surface a dice roller, or a gif browser?

There are many, many legitimate complaints against the App Store model and how tough it is to survive as an app developer within that ecosystem, but the base requirement is still "building something good that people want", and I really don't feel like the author did that.

<comment><AUTHOR> Author here!

I don't expect the app store to surface any particular app, just not get in the way of finding things. I'm lucky, you only have to swipe across three tabs and type in two letters to find my app.

Apple has said explicitly: "The future of TV is apps". If that's the case, then all I ask is for a way to link users to my app.

<comment><USER6> What would your ideal discovery process be?

<comment><AUTHOR> Ideally - user curated app lists. Start with celebs and notable people from various industries. If it's successful, eventually expand to everyone, not just selected people. Allow curated lists to be updated by the curator whenever they want.

That's a longer term solution I see. Short term, I just want you to be able to click a button in iTunes on your Mac and in the App Store on your phone to start the app downloading on your TV. That way I could put a link in this comment and anyone who sees it and is interested can get the app in two clicks.

<comment><USER6> I like it. I would think that all they need to do is build your short term solution and the open web can provide the rest. I mean, presuming they can provide a link from the web to iTunes, which seems simple enough.

</comment></comment></comment></comment></comment></comment><comment><USER7> I have an Apple TV dev kit and I would have paid for it had they not given me one for free (may still for the bedroom)

I have downloaded apps - both free (Netflix, Crackle, HBO, etc...) as well as paid for apps - Geometry Wars 3 just this weekend.

I have an XBox One also - It's just much quicker / easier to just flip over to Apple TV and start a game then to go through the whole process of booting the XBox, putting in a game, etc... I'm not a hardcore gamer by any means but I play when I need a break.

Missing from Apple TV still are Pandora / Spotify / others... I'd like to see some party games - trivia, card, etc...

It's definitely difficult to find new apps - the on screen keyboard is garbage and really needs to be worked out. Just give us a nice vertical scrolling list with categories on the left.

IMO - it's still very new and developers are trying new stuff - see what works / what doesn't. The Netflix app is an example of this - the new interface is absolute garbage. I've actually fired up my XBox to use Netflix on that instead of Apple TV now...

<comment><USER8> Missing Spotify is killer for me, it's actually tempting me to try Apple Music since I anticipate having an Apple TV connected to my other TVs in the house sooner or later. It doesn't even seem to be an issue of Apple blocking Spotify to try and steer users to AM, Spotify just hasn't created an app yet (no idea if it would get approved though). Seems like a strategic mistake on Spotify's part.

<comment><USER9> I've seen this issue for several apps (Spotify, Amazon Video, etc.), and I always just shrug it off. You can use both with an AppleTV, but the application has to be installed on a secondary device like an iPhone and then streamed via Airplay. Both of the explicitly mentioned applications work great, with that one exception of not having a native application on the device.

</comment></comment></comment><comment><USER10> The appletv has some horrid UX problems. The text input is horrid. Siri works well enough for searching video content (though i wish there was a way to disable itunes; always get my hopes up just to find that it requires an itunes purchase).

App discovery is horrid. It's not easy to find apps, and if you aren't within the first set you'll never find it. There is no way to discover via computer or phone and send to appletv, so it's basically a no go. The only exposed apps are the featured or most popular. After that it's guesswork at best.

</comment><comment><USER11> I have an Apple TV (dev kit, I wouldn't have paid for one, but it's pretty nice actually). I haven't used a single app besides Netflix and AirPlay (which isn't really an app), and I'm not even sure why I'd want to use an app on my TV instead of just using my MacBook Pro. I feel like this will end up the same way as the Mac App Store: no one will make money, besides massive players.

Most of the benefit is that I don't need to plug my laptop into the projector to watch shows now. Unless it's an Amazon show.

<comment><USER12> _not even sure why I 'd want to use an app on my TV instead of just using my MacBook Pro_

Do you ever decide what to watch with other people? That's the killer function for these TV apps for me (though I have a Roku, not Apple TV). I can sit on the sofa with my girlfriend and we can browse through the list of TV shows/movies together and choose one, rather than having to both crowd around a laptop, or worse, phone screen to decide.

<comment><USER13> I think to some extent it depends on what you see apps as on a device like the AppleTV. To me the big potential draw of app on a TV is access to other content streams that Apple hasn't negotiated contracts with. So while on my old AppleTV I can watch iTunes content, Netflix and HBO, a smaller content provider can build and submit an app. I can also get apps to stream local content. For this kind of use using a MacBook or iPad is not a very good substitute. On the other hand, if you are looking at filling the position of a Wii or XBox, and you game solo, than the laptop or iPad might have material advantages over a TV app, especially if you always play solo.

</comment></comment></comment><comment><USER14> How many Apple TV's are out there? I am surprised that your numbers are as high as they are for GifTV. I think it is safe to assume that roughly 0 people have used the Siri Remote to type in "GIF Slideshow", but 10 people per day are still installing the app.

Maybe my expectations are just much lower. When I put a hundred hours or so into a game and upload it to the app store with no marketing I only expect about a hundred downloads. I keep buying app store lottery tickets, but I don't expect any of them to win. My next one will be for the Apple TV in the next few days and we will see if that does any better.

<comment><AUTHOR> I'd love to hear about your experience! Always nice to get perspective on what strategies are working and what are not.

</comment></comment><comment><USER15> Given that Features are an effective way of getting traction, why create anything but apps that will get featured? i.e., not a dice game.

I also have a theory that Apple are partial to apps that will make them money, so a free app (unless monetised with Apple's ad platform) may struggle a bit.

Two of us in my office got dev kits and had Streaks Workout ready for ATV launch. Have had a couple of features and charted OK. Nothing crazy, but more than a handful of sales each day and the app is priced at about US$3.50.

Discoverability is poor but so are a lot of the apps out there.

<comment><AUTHOR> For perspective, Apple is currently featuring a different gif slideshow app in at least the canadian app store. Getting featured wasn't my primary goal, but it's never been out of the question

</comment></comment><comment><USER16> I was going to update our existing AppleTV but it is expensive. Going to try Chromecast.</comment>


Colin Powell thinks cell phones are fancy television remotes - <AUTHOR> https://mobile.twitter.com/RebeccaShabad/status/773666821970984964/photo/1 <comment><USER2> No, he doesn't. I believe pw has misread the document.

"The real issue had to do with PDAs." They weren't allowed because they could emit signals that could be intercepted. This was also why cell phones weren't allowed when they first came out.

Powell then wants to know why, say, TV remote controls are allowed, since they also emit signals. He's saying that the reason given didn't make sense, not that he thinks the PDA or Blackberry or cell phone is a "fancy television remote."

</comment><comment><USER3> The post title is nonsense, but the content is great. It shows the usual security / usability tradeoff in an environment where neither side can be easily dismissed. Also neither side seems to handle it very well. Security seems to say "can't do that" without offering alternatives. Colin says "nonsense" after technical explanation.</comment>


Etsy CTO on Its Conservatively Crafty Tech Philosophy - <AUTHOR> http://techcrunch.com/2015/04/27/etsy-cto-on-its-conservatively-crafty-tech-philosophy/ <comment><USER2> > "The company has 685 employees of which approximately a third are > engineers."

Given that they've produced some impressive things, Etsy always seemed to be the example of a shop that was overdoing it - but I had actually assumed they were overcomplicating it with 20 engineers or so. Looking at their github now, and hearing those recent numbers, it feels much worse. That level of work is great, but for a company that does what Etsy does, much of it seems like overkill. (Managing 1000 instances should be the same as managing 100, this is where automation kicks in. Architecture enables that.)

Ultimately, that's a tremendously large amount of engineers, to where I can't really mentally assign what all but about 20 of them might do. Let's be generous and say 30 - or even 40 :) All of that eats into the bottom line (and also makes adding more staff harder, as your tech becomes more and more custom).

Really, at the basic level, it's a CRUD-based storefront website. Yes, it has scaling needs. But it's not really novel in that regard.

Yet, they've built more automation around their automation (lots of things in the Chef ecosystem) and probably made things a lot more custom.

I can understand some of this for say, multiplayer gaming or video streaming infrastructure maybe, but I would suspect Etsy could have been run a lot easier with less wheel reinvention.

Startups should really strive, IMHO, to write as little of software as possible, that's outside of their line of business. When wheels are square, build better wheels sure, but what I see from that number looks like MASSIVE levels of maintaince costs for being that custom.

So anyway, thanks for producing things that other people use and that are useful - YES - but from the startup accounting / efficiency perspective, I wouldn't want to see my company run that way.

<comment><USER3> I think this article addresses what they do; they work their way down the stack and broaden what they provide to the business vs outsourcing to some SaaS company.

Sure, you could run this in the cloud and not worry about physical machines, but that will probably be more expensive. As companies grow, it becomes cheaper to bring lots of things in house, rather than outsourcing them.

As companies grow, small % differences can result in large total impact, at which point having engineers eek out small gains may make a lot of sense, e.g. think of Google's results around latency, or small improvements in recommendation engines that drive higher sales.

<comment><USER4> > you could run this in the cloud and not worry about physical machines, but > that will probably be more expensive.

I question what the current cost structure looks like. As a public company, my guess is that investors will do the same as well.

In a world where Instagram deals with orders of magnitude more customers with a whopping five engineers, it's a pretty high bar to show why so many resources are necessary for this particular operation.

I'm sure the Etsy guys are sensitive to that as well, but from the outside it's hard to believe there isn't a better way to use resources more efficiently.

<comment><USER5> I instagram loses a photo, nobody cares. If etsy loses an order is deal- breaker.

Not the same problem domain.

edit: Instagam has not that many customers. Has many users. That's a real diference.

<comment><USER4> Very good point. A transaction involving a user's money carries a great deal more weight in terms of reliability, accuracy, etc.

That said, the resource difference between these two companies is considerably large, and the tech in question (e-commerce) is not exactly an area of unknown innovation. From a technical standpoint, that's sufficiently a solved problem.

</comment></comment></comment></comment></comment><comment><USER6> > One way Etsy drives this kind of commitment to deep understanding that seems > to underlie its technology choices, is limiting the number of tools it uses > as a company. It would rather be the master of few tools than have a broad > knowledge across many different ones.

Every large(-ish) company I know has pretty strict rules about the languages, frameworks, and tools used for the main products.

The more flexible of these do allow prototyping using a different toolsets. The ones that have a developer audience always experiment with new environments.

New tools and new processed get adopted over time, but in many cases the cycle they go through emulated pretty closely the adoption cycle seen outside. Even if the new shinny toy syndrome is very strong in this field, this makes a lot of sense, as nobody really wants to throw away everything. (_While writing this I got to think about the numerous rewrites eBay has seen over years_).

> The company owns and operates its hardware and networks in its own > datacenter. Part of the reason for avoiding the cloud is control, but not > necessarily just from a security perspective as you might think. The real > reason is Etsy personnel want to get under the hood and understand every > aspect of every piece of technology the company controls.

I continue to be very curious about how polarizing the cloud remains.</comment>


Harvard Law Prof. Is Representing Harvey Weinstein. Students Demand Resignation - <AUTHOR> http://reason.com/blog/2019/02/26/ronald-sullivan-harvey-weinstein-harvard <comment><USER2> It seems Harvard chose poorly who they admitted - representation is fundamental to justice and if the supposed future generation of leaders are allowed to think otherwise then the US has got much worse to worry about than Trump.

<comment><USER3> On the flip side, it seems Harvard chose poorly who they tenured. Weinstein sympathizers just don't care about the #metoo movement.</comment></comment>


Americans Shouldn't Have to Drive, but the Law Insists on It - <AUTHOR> https://www.theatlantic.com/ideas/archive/2019/07/car-crashes-arent-always-unavoidable/592447/ <comment><USER2> > our laws essentially force driving on all of us—by subsidizing it, by > punishing people who don't do it, by building a physical landscape that > requires it, and by insulating reckless drivers from the consequences of > their actions

^ this is the key point of the article, of which all of the examples support.

Bummer.</comment>


Ask HN: What're your favorite cities and why? - <AUTHOR> <comment><USER2> shanghai</comment>


Ever wonder where Digg.com got its first thousands of users? - <AUTHOR> http://www.techcrunch.com/2006/10/26/2004-video-clip-early-digg-demo-by-kevin-rose/ <comment><USER2> Gee, why didn't I think of that? I'll just feature my internet startup on the nationwide cable show that I co-host!

<comment><AUTHOR> It's interesting to see how starting a social site is really done -- you need massive hits to get started. It's not something you can do without being able to bring in the traffic unless your app has a lot of inherent utitlity.

<comment><USER2> Which suggests to me that you have to start desperate with a purely social site. You have to, have to, have to reach a critical mass or you're boned. Free stuff or promises of it, guerilla PR, outright paying users, spam-like invitations -- whatever it takes, you need to consider it.

</comment></comment></comment><comment><USER3> That clip struck me as Kevin being really shady. He acts like he is a completely objective third party ('they', 'they', 'they'). I bet a lot of people wish that they could promote their site to millions of people for free.

Anyway, promoting something like that and not making clear it is yours is dishonest, imo.

</comment><comment><AUTHOR> Notice that Kevin does not mention that Digg.com is his own site.</comment>


Smyth Report - <AUTHOR> https://en.wikipedia.org/wiki/Smyth_Report <comment><USER2> > For this reason, the Smyth Report focused heavily on information, such as > basic nuclear physics, which was either already widely known in the > scientific community or easily deducible by a competent scientist, and > omitted details about chemistry, metallurgy, and ordnance. This would > ultimately give a false impression that the Manhattan Project was all about > physics.

Fascinating how easily the public's perception of science can be manipulated, intentionally or not.</comment>


How Big Pharma Uses Charity Programs to Cover for Drug Price Hikes - <AUTHOR> http://www.bloomberg.com/news/articles/2016-05-19/the-real-reason-big-pharma-wants-to-help-pay-for-your-prescription <comment><USER2> cause bankrupting middle america is a great business strategy.</comment>


Zoom's 90-day plan to bolster key privacy and security initiatives - <AUTHOR> https://blog.zoom.us/wordpress/2020/04/08/update-on-zoom-90-day-plan-to-bolster-key-privacy-and-security-initiatives/ <comment><USER2> I'm still not sure what to think of the whole debacle.

Zoom could be a victim of the internet mob justice, where every inevitable misstep is blown out of proportion. Perhaps the mob is helped along by some competing interests. Or Zoom could be yet another tech company with dubious ethics (like U: or F). I doubt they are outright a PLA branch, that would be far too obvious.

This isn't just idle musings - I love how Zoom allows me to share screen/whiteboard, and see people's faces at the same time. It works really well for remote dev collaboration, in some ways better than physical presence. And yet the question of safety remains.

Should I go and research WebEx?

<comment><USER3> Occam's Razor. Zoom usage went up by 8x in a few months. Usually doubling in two years is great for a public company. So that's 6 years of great growth, compressed into a few months. It shouldn't be surprising to see six years of security problems also compressed into those three months.

I think Zoom is on track to fix these problems quickly and cement their spot as the best solution for videoconferencing.

<comment><USER4> Zoom had the same security issues with half the traffic. Acting like usage causes them is disingenuous.

Technically speaking, zoom has shown off great and remarkably stable/scalable features.

But that is orthogonal to whether they are putting people at risk (e.g. not- so-secret therapy sessions) or lying about their feature set (clearly claiming to have end to end encryption).

<comment><USER5> That's a straw man. GP argues that Zoom's increased popularity implies increased public scrutiny. Not that the problems are OK.

There's lots and lots of insecure software that Bloomberg doesn't write about. People click on articles about software they use.

<comment><USER4> I'm not following your argument.

I agree that increased scrutiny does not make the problem ok, but does reveal the problems more quickly.

But the only reason those points matter in the "Should I use Zoom?" question is if you're assuming all other products have the same flaws and just haven't been looked at. To which, I'm pretty confident they don't all share these problems, particularly but not limited to the "blatantly lied about the basic security features".

<comment><USER6> _> To which, I'm pretty confident [other products] don't all share these problems_

I am not confident of this.

I would assume that anything that isn't actively being sold into the large enterprise market has Zoom-level problems, or worse.

</comment></comment></comment></comment></comment></comment><comment><USER7> So were they really sending data to servers in China? From what little I've heard and read about this, that is what stood out to me. Not sure they should ever be trusted again after that.

<comment><USER8> I think this is the Zoom response to that one: [https://blog.zoom.us/wordpress/2020/04/03/response-to- resear...](https://blog.zoom.us/wordpress/2020/04/03/response-to-research- from-university-of-torontos-citizen-lab/)

As I read it they accidentally routed some data to China based servers for a month (Feb 2020) due to a config mess up during their crazy fast scaling period. This is since fixed.

<comment><USER9> They were making requests to IPs in China long before Feb 2020. At the time I assumed they'd been hacked, but in retrospect it seems like this was just how their organisation is distributed.

Needless to say, I have decided not to endorse their videoconferencing solution.

<comment><USER10> Do you have evidence of this?

</comment></comment></comment></comment><comment><USER11> Zoom's web SDK and web client were down for nearly four days over the weekend with minimal communication, and when they brought it all back they killed a key functionality the education market needs which is the ability to join a meeting without an account: [https://devforum.zoom.us/t/in-progress-web-sdk- web-client-fr...](https://devforum.zoom.us/t/in-progress-web-sdk-web-client- from-browser-403-forbidden/10782/35)

<comment><USER12> Actually this isn't true anymore, they have since added the _option_ to not require an account when using the web client. The Web SDK still works like before and also doesn't require an account.

But I agree, the way it was handled was harrowing.

<comment><USER11> Thanks! I fell out of the loop with this.

</comment></comment></comment><comment><USER13> "90 day plans" tend to be management & PR things... Real engineering is more of a "it takes as long as the job takes"...

<comment><USER14> Can you blame them? Most users and purchasers (at a lot of companies the people making purchase decisions aren't actually the users) don't really understand or care about how long real engineering takes. As long as they made a decision to pick a vendor based based on the principles of Cover Your Ass it's all that matters.

It's another primary reason why so many "enterprise" companies purchase Redhat over running CentOS.

</comment></comment><comment><USER15> uh, is that an outlook-email link with someone's username in? The one linking to Alex.

<comment><USER16> Yup. Looks to be their email address. Email is from PR firm Sard Verbinnen & Co.

<comment><USER17> Safelinks have the email address of the recipient of a link.

</comment></comment></comment><comment><USER18> and this is why product over security always wins.

there's mob mentality right now, but zoom got a TON of customers, and now is gonna have proof of end-to-end encryption in a couple of months.

boom.

zoom wins.

honestly just don't talk on zoom about something highly secretive such as ... idk... something a government is interested in as that isn't currently secure, other than that, don't sweat it.

<comment><USER19> They are very unlikely to have end-to-end security in a couple of months, for the same reason few (if any) of their competitors have it: it is really bandwidth intensive to send full-resolution video of every participant to every other participant. So everyone sends low-res for most participants, and at most one high-resolution stream. To do this you have to be able to make low-resolution streams out of the high-resolution one people are sending you (to pass along to others). That means you have to terminate encryption on the server side. Once you have done that you are no longer "end-to-end". This is just the state of things.

This is a valid tradeoff for most things, but the real problem here is that Zoom claimed (and continues to claim) "end-to-end encryption", while not providing it. That is a lie, and people naturally wonder what else you are lying about.

<comment><USER20> You can also send two streams (high and low quality) from each client and make other clients request the right one from the server. Yes, it's slightly more bandwidth than before and now complexity. No, it doesn't require full mesh of connections to be E2E.

</comment></comment></comment><comment><USER21> My company banned the use of Zoom on company computers or computer connecting to the company network.

Has anyone else had this happen to them?

<comment><USER22> The very large company I work for banned all video conference software except for what is provided by the company. I don't think it is just about security, but make everyone use the same system(s) because it just got too confusing to communicate with other divisions or even departments. You can search for people in other divisions and then video chat with them if you want, or just plain old school voice chat.

Luckily, the software we are required use works pretty well on iOS, Android, OSX and Windows.

</comment></comment><comment><USER23> Mac App Store version when?

<comment><USER24> Or even a non-MAS app that's sandboxed, if it's going to be free anyway and they prefer to manage their own release schedule.

</comment></comment><comment><USER25> I wonder if Google and Apple were directly involved in the campaign against Zoom.

</comment><comment><USER26> They're in the same bed as China. I don't trust them for anything now, this to me is just a PR management exercise. They're still going to give away your data

<comment><USER27> Would you please stop posting unsubstantive and/or flamebait comments to HN? We're hoping for a better quality of discussion than this, and (especially) than what it leads to. Case in point: see below.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER28> I believe the GP was referencing Zoom's encryption going through China's servers, which was on HN's recently: [https://citizenlab.ca/2020/04/move-fast- roll-your-own-crypto...](https://citizenlab.ca/2020/04/move-fast-roll-your- own-crypto-a-quick-look-at-the-confidentiality-of-zoom-meetings/)

There are valid criticism to be discussed about China's actions and how much Zoom should be trusted given its close relation.

There's been many criticism of the US government here and I never see anything flagged or removed, I would consider that nationalistic and provocative under the same guidelines. I just don't see why the China discussions are removed.

<comment><USER27> > _There are valid criticism to be discussed about China 's actions and how > much Zoom should be trusted given its close relation_

Yes, and that's why comments about it should be thoughtful and substantive—not drive-by flamebait leading to useless flamewars about NATO and Winnie the Pooh.

> _There 's been many criticism of the US government here and I never see > anything flagged or removed_

That happens often. If you never see it, that's because of a cognitive bias: we notice and weight more strongly—that is, we see—what we dislike. [https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...](https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Adang%20notice%20dislike&sort=byDate&type=comment). People on the opposite side of this question have exactly the opposite complaint.

</comment></comment></comment></comment><comment><USER29> Zoom won the proverbial lottery with this pandemic and lost their ticket through greed/laziness. Great companies are always prepared when their big break comes. Zoom is not a great company.

<comment><USER30> You don't have to be a great company to win in the market. I'd bet that zoom still maintains dominance and manages to con people into believing that they're super secure now guys.

</comment></comment><comment><USER31> I can't quite figure out what's going on with this thread. It seems to have an eerie amount of posts about support for Zoom, perhaps by paid trolls ("wumaos")?

<comment><USER27> Please don't break the site guidelines by posting insinuations of astroturfing. Overwhelmingly, such perceptions are simply in the eye of the beholder. I say that based on many years of looking at that data, and you can find more explanations here than anyone would ever want to read: [https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...](https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=true&page=0&query=by:dang%20astroturf).

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

If you're worried about this kind of thing, follow the site guidelines and email firstname.lastname@example.com so we can look into it. (We always do.) In this case, though, the simplest explanation seems adequate: the community is divided. When there's a popular divisive topic, people who feel strongly for side A always feel like the amount of support for opposing side B is 'eerie', because it's hard to imagine how it could possibly be in good faith. Of course B feels the same way about A.

Edit: oh dear. It seems like you've been using HN mostly for nationalistic battle lately. We ban accounts that do that, so please stop. It's emphatically not what this site is for, regardless of which nations are at issue.

</comment></comment><comment><USER32> I can only assume CISO is Chief Information Security Officer? I hadn't seen the acronym before. Bad Zoom for not writing it out in full on the first instance.

<comment><USER33> "CISO" is a pretty standard acronym. People who don't work in cybersecurity or who don't have that background might not recognize it, but it seems like a minor detail.

<comment><USER32> Sure, it's a minor detail. And yes, you can say the audience for this post are people who work in cybersecurity. But it costs nothing to introduce the acronym, as is usually recommended. Without it you are alienating anyone who doesn't know the term.

<comment><USER34> Serious question - would you feel the same way about using CEO or CFO without spelling out what they stand for?</comment></comment></comment></comment>


Gene Wilder, dead at 83 - <AUTHOR> https://twitter.com/APEntertainment/status/770340136311779332 <comment><USER2> When I was about seven years old my grandfather took me to a Sunday market and bought me Blazing Saddles on VHS, it was the first time I understood what comedy was (at seven, my laughter mainly came from watching the campfire- farting scene) and it wasn't until much later I understood the comedy behind the racism. From then on, on every trip to the market, I would come home with a new and increasingly crude VHS (a few weeks after he introduced me to the Young Ones, and then Bottom) – he seemed to find humour in giving me things that he knew would annoy my mother.

Despite being born in the eighties, and in the United Kingdom, I still grew up on the comedy of Mel Brooks, Gene Wilder, Richard Pryor. I'm going to miss Gene Wilder, just as I miss Pryor.</comment>


A Founder's Job - <AUTHOR> http://notmylawyer.com/post/754048881/your-business-is-a-person-make-her-awesome

<comment><USER2> I disagree. I believe a business should be built around a product, a vision dreamed up by the founder well before they started hiring or searching for co- founders. The personality of the business will be determined by the product. The correct question is "What is the product going to be?" not "Who is your business going to be?". A company with a good product won't have to ask the questions posted in the article.

<comment><AUTHOR> I see what you're saying, but notice I said your business is like a "person," not a "personality." Whatever problem you are solving is being solved by the business, not by you, even if you are a single founder or small team.

It's useful to ask who your business is going to be because it's a concrete acknowledgement that you are not your business. Once you do that you can decide which parts of who you are should be applied to solving the problem you're going to solve, and what contributions you'll need from others to complete who you want your business to be, whether they're contractors, co- founders, employees, advisors, or whomever.

Your business will also have a personality, but that's only small piece of the picture, just as a person's personality is only a piece of who they are. A person has skills, abilities, a point of view, values, etc., just like your business. And the way your customers will relate and interact with you as the provider of a product or service, is more similar to how they would relate to a person than anything else. So I think the lens is useful.

Thanks for the comment! :)

</comment></comment><comment><AUTHOR> I have the hardest time settling on titles for blog posts. For this one the candidates were:

A Founder's Job.

Your Business is a Person. Make her Awesome.

Who is your Business?

Is there one you like better? Any tips for picking titles?

Thanks!</comment>


Denying One's (same-sex) Desires Tied to Homophobia - <AUTHOR> http://psychcentral.com/news/2012/04/09/denying-ones-desires-tied-to-homophobia/37087.html The study is the first to document the role that both parenting and sexual orientation play in the formation of intense and visceral fear of homosexuals, including self-reported homophobic attitudes, discriminatory bias, implicit hostility towards gays, and endorsement of anti-gay policies. <comment><USER2> "Investigators believe the findings may help to explain the personal dynamics behind some bullying and hate crimes directed at gays and lesbians. Many believe that attackers often perceive some level of threat from homosexuals."

Or: They're just an easy target, like most minorities or people who can be singled out from the crowd. Bullies don't want their victims to fight back, so they stick to easy targets.</comment>


It's Better to Beg for Forgiveness than to Ask for Permission - <AUTHOR> http://www.bothsidesofthetable.com/2010/06/15/its-better-to-beg-for-forgiveness-than-to-ask-for-permission/ <comment><USER2> This reminds me of my first partner in our software/consulting service business. He was absolutely fearless.

We would always arrive at appointments very early so he had an excuse to "poke around". He'd ask anybody, the receptionist, someone in the breakroom, even the janitor. He'd see what was going on in the parking lot, the loading dock, even in the warehouse or factory. Seeing him in a business for the first time was like watching a kid in a candy store.

In our first meeting, he always knew something about the client's business that they didn't. He'd say things like, "Automating the inventory won't help if Fred and Jean are counting 2 different things." This always led to interesting discussion and often, follow-up business.

Once he even spent a week of his own time on third shift, going over procedures and reports with factory supervisors. They didn't know who he was; they just figured someone from the main office sent him. He did a complete analysis in Excel which we used in a proposal. That got us hundreds of thousands of dollars worth of work.

I often challenged him, "You can't just do that," I would say. To which he would respond, "These people need help and don't even realize it. We have to find a way to show them." Then the inevitable, "It's better to beg for forgiveness than ask for permission."

Looking back, it didn't always work. It pissed off some people and burnt those bridges. But when it did work, we often concluded that nothing else would have.

I learned a lot in those days. I'm still not as fearless as my partner was, but I'd like to think I'm getting there. Thanks for the memories.

<comment><USER3> Great story! And exactly the point. The other saying is "you can't make an omelet unless you're willing to break eggs." I don't mind getting messy from time-to-time. When you take risks like your partner did it backfires sometimes. But I'd rather occasionally get shut down for trying too hard.

<comment><USER4> Yes. But keep in mind: You can break an awful lot of eggs, without making an omelet.

</comment></comment></comment><comment><USER5> This is especially good advice if you work in a large company. Banging your head against the wall is often more pleasant than getting permission to do something new or different. So my solution is to just mock up a prototype before I tell anyone about it. It's _easy_ to say "I want to do this, and can prove it's not all that difficult". Even better if you can say "I had this idea that was so great I went ahead and wrote it!" People are a lot more likely to take your work seriously after it's already been written than before.

<comment><USER6> I fully agree with this. Getting past big company bureaucracy absolutely requires this attitude in my opinion.

</comment></comment><comment><USER7> The outcome of this story was favorable (which is why we're reading it). I wonder, however, if there are far more stories that begin the same way but end with "You're being fired for insubordination" or something similarly negative.

<comment><USER8> I have a story that backfired. I had a team of 5 developers that were working in a product. The company had been trying to build the product for several years. When I saw the architecture they were using I tried to convince the architect to make some changes. They wouldn't do it. They wouldn't even let me touch the code. I was a manager I wasn't supposed to get involved. So I thought. "It is better to ask for forgiveness than to ask for permission". So I started to build the product from scratch. I had plenty of time and no one cared what I did. After 5 or 6 months I already had a product that was way a head than the official product. When I tried to show it to my manager he got really mad. He literally screamed at me. That was 1.5 years ago. I went in a depression for a long time. They fired the architect. They fired my manager. The developers had to spin their wheels for a long time. Then they left. And the product is still not ready.

<comment><USER9> "Ask forgiveness rather than permission" is not equivalent to "forge ahead without thought for the consequences". Completely rewriting a codebase by yourself to show up a team that has been working on it for a long time might mean better code, but it's also a direct demonstration of the ineffectiveness of that team. _Of course_ some kind of major shake-up is going to happen after something like that. Firing people might be a little extreme, but you certainly have to expect that it's a possibility.

If you don't have the stomach for directly causing people to get fired, or for conflict, then don't go out of your way to demonstrate how poorly they're doing their job. Find your way out to something else, and let them do themselves in.

<comment><USER8> No one was fired as a consequence of what I did. They were fired because time passed and there were no results. If I had been able to convince my boss I think we would have been successful. At one moment I thought about going one level up in the organization, I decided to be loyal to my boss so I kept my mouth shut.

<comment><USER10> Ouch. Don't chain yourself to a sinking ship.

</comment></comment></comment></comment></comment><comment><USER11> "It's Better to Beg for Forgiveness than to Ask for Permission", Grace Hopper, one of our pioneers. She also coined the term "debugging" and was one of the creators of COBOL.

</comment><comment><USER12> If I were to follow this philosophy more often I'd try to be damn sure I knew exactly what I was doing before I did. Going off on your own to do something because you know others would not agree is a bit arrogant. It has to come from a belief that you know more than they do. So if you are going to do something when you know your boss/colleague/co-founder would disagree then you had better make sure you do know more than they do.

</comment><comment><USER13> If you enjoyed this article, you will probably love Randy Pausch's Last Lecture: [http://www.amazon.com/Last-Lecture-Randy- Pausch/dp/140132325...](http://www.amazon.com/Last-Lecture-Randy- Pausch/dp/1401323251/ref=sr_1_1?ie=UTF8&s=books&qid=1276700690&sr=8-1)

I had already watched the lecture on YouTube and thought I wouldn't get much from the book but I was wrong.

The story of Pausch muscling his way into Disney's Imagineer team is fantastic.

<comment><USER14> Also watch Randy Pausch's lecture on Time Management: <http://www.youtube.com/watch?v=oTugjssqOT0>

</comment></comment><comment><USER15> Why do people put distracting animations next to the content which they presumably _want people to read_? I don't care which Twitter users looked at your page, and if I did I could very well find that information without the animation drawing my eye to it.

EDIT: Thankfully there's Readability. But I'm sure the author would rather I read it as he presented it.

</comment><comment><USER16> Sometimes it's better, sometimes not.

Life is complex and subtle. That applies to business, personal relationships, friendships, personal hobbies, society, culture, everything. If you bind yourself to the naive "official" level of policies, rules, and regulations then you will miss out on the rich vein of interactions based on tacit and implicit knowledge, culture, and norms.

Flirting is a perfect example of this sort of thing. Full of subtlety and complexity and none of it 100% direct and straightforward. All of life has similar elements. If you treat your job, for example, as a mechanistic process then you'll probably have about as much success as if you treated romance the same way.

Developing the skills, experience, and judgment to know how, when, where, and in what way to "break the rules" and when not to is a an ongoing, lifelong adventure for everyone.

</comment><comment><USER17> Tangent story [Asking for Permission]

[http://kbiri.blogspot.com/2009/01/lens-story-about- yesterday...](http://kbiri.blogspot.com/2009/01/lens-story-about- yesterday.html)

<comment><USER18> That's not exactly a counterpoint, as the intonation behind "ask for forgiveness, not permission" is that you are doing something the other party would not want if asked directly.

<comment><USER17> Corrected it.

</comment></comment></comment><comment><USER19> One of Colin Powell's leadership slide points. <http://www.blaisdell.com/powell/>

</comment><comment><USER20> This usually works best in overly bureaucratic or draconian situations.</comment>


Instapaper Subscriptions (beta) - <AUTHOR> http://www.instapaper.com/subscription

<comment><USER2> Didn't even think twice about this - I am _always" clicking on "Read Later" - and then making sure I sync up with my iPad and/or iPhone before walking home. Then, throughout the day, whenever I have downtime, I get caught up on all the articles.

In fact, there are a few times when I'm just buried in the screen Spam, that I just give up and hit "Read Later", knowing that the article will be cleaned up for me (Kind of like Safari's reading screen)

Love the $1/month charge. I have zero reason not to continue this indefinitely. I would have gone as $3/month without hitting my "Hmm, let's think about this point" - though I suspect I would have paid as much as $4/month before I considered not subscribing. $5/month is over my pain point.

As a side note - the WSJ has basically established my "levelling" indicator for what I consider fair value for a subscription. They charge me $155/12 months or about $13/month - with content syncing to my iPad or viewable through the Web Browser.

So, when I purchase monthly content or service subscriptions, I mentally ask my myself - what percentage of a WSJ subscription this is. I'd say that Instapaper is worth about 1/3 of the WSJ.

</comment><comment><USER3> I'm surprised Marco is billing $1/month in 3 month intervals... I'd have just billed $12/year.

$12 is hardly a large payment chasm for a customer, particularly if you've already told them that they're not going to get anything particularly extra for their subscription and they're still interested.

But it also makes the fixed-fee on the transaction a lower %age of the total sale and of course from a cash-flow perspective you have a full 12 months income in the bank now.

<comment><USER4> Don't forget, Marco is not shy to charge $4.99 for Instapaper in the App Store. I do not have the statistics right now to back it up (although I'm sure a few Google queries could), but I'm fairly confident that's above the average price for an app.

<comment><USER5> The iPhone app also has some value to it that makes it worth the $4.99, e.g., 250 article capacity, iPad compatible, and it remembers your position.

The only benefit subscribing gives to you right now is being able to hide ads, which people can already do for free, and the warm, fuzzy feeling you get from supporting Instapaper's development.

</comment></comment></comment><comment><USER6> I love the honesty here:

"What are the benefits?

Right now? Almost nothing, except knowing that you are supporting the Instapaper service's operation and future feature development."

</comment><comment><USER4> $1/mo to support one of my most used services is a no brainer. I hope others feel the same way - Marco is going indie and he's definitely getting my $1/mo to support his new full time business venture.

<comment><USER7> I honestly would have paid $5-$10/month for Instapaper. It is by far the most used app I have on my iPhone.

I wish Marco the best of luck, and can't wait to see what new features he comes up with.

</comment></comment><comment><USER8> I'll subscribe gladly if they fix the cron that emails articles to my Kindle. That thing never works. Sometimes I go tell it to send the articles manually, sometimes that works. Sometimes it doesn't and I have to download a .mobi.

It's worth some amount of money to not even know what a .mobi file is.

</comment><comment><USER9> Instapaper on my Kindle is well worth $10/month.

I used to skim all the long articles I came across, now I read them all. The longer, well thought out ones are some of the best.

If he released a more native Kindle integration, I'd definitely pay for it.

<comment><USER10> I fully agree. I've gotten so much use out of my instapaper/kindle integration that it's mind-boggling.

If I recall correctly, they do have an option where they'll send instapaper to your kindle account every day. However, the free kindle account doesn't support automatic delivery, so you have to pay amazon their delivery fee.

I'm outside the states, so the $2 per instapaper or whatever it is just isn't worth it to me. At the end of every day I just download all the files I've collected to my kindle with the USB cable, and read on the train ride home.

<comment><USER11> Same situation, but what I usually do is to go to instapaper.com/kindle on my kindle browser to get the last version of my read-later document on my way to work every morning. No need of USB and I can use it in situations like right before getting into a plane.

The kindle browser kind of sucks (now, I am sure they will put more work into that), but I have that URL as the first entry on my bookmarks menu.

</comment></comment></comment><comment><USER12> Whenever I see a low donation / price like this, I think of Shoemoney's post about Amazon Wish Lists. His basic argument is that you should provide a way for people to give you a wide range of money. I'm sure that some people will gladly pay Marco $3/quarter but there might be a couple people that might gladly buy him a new $100+ gadget.

[http://www.shoemoney.com/2008/12/23/income-from-donations- am...](http://www.shoemoney.com/2008/12/23/income-from-donations-amazon-wish- lists-rock/)

<comment><USER13> Exactly.

Well, that and I'm sick of everything in the goddamned world being a subscription service now. Can't you do it like Pandora and make a big, obvious, ONE TIME PAYMENT, WILL NOT RENEW option?

Or better yet, just give me an empty box so I can pay you a few years worth of "subscription" at once and not think about it again. I'm sick of having a million monthly charges on my credit card.

Take my money, please.

</comment></comment><comment><USER14> Excellent. I'm happy to support one of my favorite services. Instapaper is one of the few apps (on iPad for me) that have actually improved the quality of my daily life -- how often can you say that about an app?

Specifically, it's retraining my brain to slow down, go deeper, and think critically.

My only concern would be rewarding the content producer, because I often skip the web page all together.

Perhaps integrating Flattr's API for those domains that have it set up?

</comment><comment><USER15> Previously it would have been kind of a dick move to make alternate reader apps, but maybe now he could perhaps support an official API for subscribers

</comment><comment><USER16> I don't even see an option to pay for any kind of service (logged in or not). Did i miss the link somewhere?

<comment><USER17> Click the thread's link: <http://www.instapaper.com/subscription>

Then click on the Paypal 'subscribe' logo right in the middle of the screen.

<comment><USER18> You also need to be logged in, otherwise it redirects to the home page.

</comment></comment></comment><comment><USER19> I use pinboard for my "read it later" functionality, but I'd switch to Instapaper if it could deliver to my Kindle account (I don't use a Kindle, but do use the software on my iPad). I'm assuming it's an Amazon limitation that means auto-delivery only works on the Kindle hardware, no?

</comment><comment><USER20> NYTimes reported that Instapaper has 800,000 registered users and 200,000 regular users. If every regular user signed up at $1/month, Marco would be pulling in $2.4M. Even if it's only a quarter of the users, that's still a nice chunk of change.

</comment><comment><USER21> As soon as there is a non-PayPal option I am there. I know why this is currently the only option, but maybe someone from one of the many subscription-billing startups that haunt HN should send Marco and email and offer him a deal... :)

</comment><comment><USER22> I'm not sure how much it's worth but I was happy to subscribe for $1 and sent a separate gift via PayPal for $10.

Go get 'em Marco!

</comment><comment><USER23> I'd pay for Kindle synchronization to actually work. Mine hasn't in a week or so.

</comment><comment><USER24> At $3/3mo, I just signed up without thinking about it. I love instapaper.

</comment><comment><USER25> Definitely worth the $1/month and happy to support such a great product

</comment><comment><USER17> I will pay even more ($30/year) if Instapaper could somehow allow for cross- browser bookmark syncing a la XMarks. It seems like once XMarks is gone, there will be a huge void in the market. Maybe Instapaper can add some more features to fill in this gap.

<comment><USER26> As-is, Instapaper isn't a bookmarking service, though. Its a reading service. It strips away the unnecessary crap and formats text nicely, so you can focus on reading.

<comment><USER27> Many people seem to be mistaking Instapaper for bookmarking. I get "why should I use historious over Instapaper?" a lot, even though one is a "to read" list and the other is a bookmarking service.

Ironically, I also get "why should I pay for historious when Instapaper is free?" a lot as well. Looks like I'll be getting that less often now...

</comment></comment></comment><comment><USER28> What's the advantage of that over a delicious tag "read_later", that i've been using for years?

delicious work on all browsers (natively), iphone, android.

well, not for epub readers without a one line cron job on my desktop... but again, it works with android :)

<comment><USER29> Two completely different services. Instapaper will bookmark articles to read later, and cut out everything except the text. One downside is that it doesn't seem to be able to handle multi-page articles, however some sites have a single page view (or "printer friendly").

The killer feature in my book is the iOS app. It's a universal app, and will sync your article progress across your iOS devices. I _love_ this — perfect for, e.g., reading part of an article on your iPhone while in line at the bank, then going home and picking up where you left off on your iPad.</comment></comment>


As coronavirus looms, mask shortage give rise to promising re-use approach - <AUTHOR> https://www.nytimes.com/2020/03/20/health/coronavirus-masks-reuse.html <comment><USER2> 3M just doubled its production to 100 Million a month. That should do it I think.</comment>