The Logical Disaster of Null - <AUTHOR> https://rob.conery.io/2018/05/01/the-logical-disaster-of-null/ <comment><USER2> _> I'm not sure Null should have a place in programming. _

The essay is conflating 2 different concepts of "null."

The Tony Hoare quote is about null _references_ which is about _aliases_ to computer memory. (E.g. the dreaded NPE or null pointer exception.) He's not talking about _logical_ nulls such as "tri-state booleans" or "missing data".

The logic-variant of Null usage for "unknown" "missing" "invalid" values is unavoidable in programming. This is why that null concept shows up repeatedly in different forms such as NaN in floating point, NULL in SQL language, etc. If you invented a theoretical language without logical Nulls, the users of your language would _reinvent nulls_ using worse techniques such as homemade structs with an extra boolean "HasValue" field. E.g.:

      struct NullableInteger {
        int x;
        bool hasvalue;
      }

The "hasvalue" field becomes a "null by convention". Other programmers might not even code a verbose extra boolean variable and instead use (dangerous) sentinel values such as INT_MAX "32767" or negative value such as "-1" as the "pseudo null" to represent missing data. A lot of old COBOL programs had 99999 as some out-of-range value to represent missing data. We need nulls in programming languages because they are useful to model real-world (lack of) information. All those other clunky techniques will reinvent the same kinds of "null" programming errors!

The orthogonal aspect is making the _type system_ more powerfully _aware_ of nulls so that the compiler sees that possible null conditions were not checked. A compiler error forces the programmer to put in the _explicit_ defensive code to _handle the possibility of null values_.

<comment><USER3> I find it weird that people keep making languages with static typing where all types can also be null instead of using an option type. Doing so nullifies a significant amount of the correctness checking static typing provides.

It makes some sense for interoperation when living inside .NET or the JVM, but this was a known problem when _those_ systems were designed.

<comment><USER4> 1\. It's hard to support circular data structures in an imperative language without null pointers.

2\. Restricting a language to non-circular data structures will not be popular.

3\. Having a nullable and non-nullable version of every pointer or reference type is not usually super popular either.

Phrased differently: nullable types are actually a fairly reasonable compromise from a set of not fully appealing choices.

<comment><USER5> Having nullable and non-nullable versions of every type is fine if you have decent syntax for it. Take Kotlin for example:

[https://kotlinlang.org/docs/reference/null- safety.html](https://kotlinlang.org/docs/reference/null-safety.html)

<comment><USER6> Well, not really. What Kotlin has is exactly an Optional type. It's just a different syntax for it.

<comment><USER7> There's one difference between nullable/non-nullable types and Optional type, which is nesting, right?

I'd assume that while Kotlin's String? is equivalent to Optional<String>, Kotlin has no equivalent to Optional<Optional<String>>.

Which, personally, I think I'd prefer Kotlin's approach, because that means you can do `maybeString = "exists"`, which is more readable than `maybeString = Optional::Exists("exists")`

<comment><USER6> Sure. In Haskell you join them, but just not allowing it perhaps better.

Also, you can still nest them in Kotlin, since you can have a nullable type inside generics.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I have a pet peeve whenever people bring up the old "Billion dollar mistake" quote. Calling it a mistake means that it could have been avoided. But we couldn't have avoided null pointer errors (or some other name for the same thing) any more than humans could have avoided the bronze age. In the 60s and 70s we didn't have the "technology" to avoid null errors. By technology I mean production-ready languages with a static typing layer sophisticated enough to implement a Maybe/Optional type. Those languages weren't production ready until maybe around the 80s. And most of those compilers were themselves implemented in unsafe-null languages like C.

But anyway, that's history, now we have nice languages that have safe nulls, so the interesting questions moving forward are: why are people still creating new languages that have unsafe nulls (looking at you Go), and why are people still choosing to use languages with unsafe nulls?

<comment><USER9> There were better languages but Unix won, and with that - C. A mistake we (whoever "we" are) repeated with JavaScript - we let the language win that was "there", not the one we really needed.

Worse is better. Ease of deployment over ease of development.

As for the Q: why design languages with null (that is - incomplete or flawed type systems) _now_? I have o idea. I think the reasoning is that "worse is better" succeeded for JS, php, C, so it's a viable path.

"Maybe an X" and "Definitely an X" are more different than string and number. If a language pretends string and number are distinct but at the same time has no distiction for "maybe X" - then it doesn't have a very good type system.

Note that it doesn't necessarily need to avoid null values for this. Non- nullables is mostly equivalent although less elegant. That is, "String s" means a string or null, while "String! s" means a non-null string (example from a C# vNext syntax).

<comment><USER10> > we let the language win that was "there", not the one we really needed.

Different explanation of history: Something "wins" because it is _precisely_ what is needed.

<comment><USER9> It does - but I think sometimes somethinb should have "won" that solved the short term problem 95% as well, but solves the problems over the next 4 decades better The Q is why individuals and companies would pay short term for gains to others.

</comment></comment></comment></comment><comment><USER11> I disagree with the author here, and while I admit that Null failures are a pain, it's not true to say they don't exist in other languages. "Maybe" and "Option" etc may force you to deal with them before they will compile, but that's not the same thing as saying the concept of Null does not exist in those languages. I'm sure there are some languages out there without any concept of Null, but they would have their own shortcomings for the lack of it.

It's also wrong to suggest that Null has no place in "logic". Boolean logic is one type of logic, but it's not the only type.

Finally, the examples of how Null works in various languages are really poor. "Why doesn't Ruby coerce nil into zero?" Because it doesn't coerce any types implicitly. Why should nil be the exception? How is that expectation "logical"?

<comment><USER12> I think you misunderstood something about the languages mentioned like Swift or Haskell. They do have a way to represent the concept of "nothing", or "missing" using an enumeration (called Optional in Swift, Maybe in Haskell).

What they don't have is the global concept of Null that sits at the root of the type hierarchy. This means every type in a language like C# or Javascript has to have Null as one of its members. If you want to define some operators/functions on the members of the type, have have to always consider Null as a member. Like the author listed: How do you compare Null, how do you negate Null? Those questions shouldn't even be asked because Null is not negatable or comparable. Maybe the problem is that Null shouldn't have been admitted as member of a type that you consider comparable or negatable.

So in Swift/Haskell, when you define a type you don't consider "nothing" as one of its members.

The mental model in Null-using-languages is that a Type is a sort of blueprint that can be stamped out to make instances of that type. From that point of view its natural to consider you may be missing an instance.

In language like Swift or Haskell the concept of a Type is closer to a set in math; in this case the set of all possible values of that type. This is why I said above that Null has to be considered as a member of a type. I'm using math language to re-interpret the type-as-blueprint world view, to show why it leads to illogical results.

Seriously, Swift demoting of the concept of "nothing" to just another enum is alone worth the price of admission. This has cascading consequences that lead to safer code. You also get simpler code as you strive to resolve the uncertainty of a missing value as early as possible in your code. Swift is the most impressive language I've seen in a while, but think its origins at Apple have overshadowed the its incredible technical value.

<comment><USER13> Have you used any language that has a type system powerful enough to support arbitrary sumtypes (and also has null as a separate type)? If not then I can recommend playing around some with Crystal.

IMO optimals are just a crutch to make up for a too weak type system.

<comment><USER14> Given a sufficiently powerful type system, you should still err towards an Option type, because you don't want to have to make two types for everything you want to represent - the real type, and the real type but also null. Having an Option type lets you compose that behaviour, even if, yes, it's as simple to define as `type Maybe x = Just x | Nothing`.

<comment><USER15> No, optional really isn't needed in crystal. You can just add `| Nil` to any type wherever you use it. We ever have a short cut in the type syntax of the language `?` to add null to a type union. So in practice at the type layer all you're doing is replacing Maybe Type with Type?. But now you have a strictly more powerful construct which behaves like options in some ways (you can call try on any union with nil because all types including nil implement the try method) but supports flow typing for null checking, removing all of the extra dereferencing syntax for option types.

<comment><USER12> This is also how Swift implements it support for optional. So far I don't see a difference in expressive power between the two languages. A user never has to actually type out Optional, when adding ? is enough. Swift also has optional chaining and nil coalescing operators as syntactic sugar. Under the hood there is still an Optional type for the type checker to work with.

I think this is becoming a trend in modern language design. However as this comments section demonstrates it's hard to understand its benefits or why it's an important improvement, if your only experience is from C/C++/C#/Java etc

<comment><USER15> Does swift have flow typing? The expressive power of sum types with nil is only exposed with flow typing. Also I don't think swift supports arbitrary sum types it just has a "fake" sum type syntax that only works with null. In crystal you can have an `Int32 | String` just the same as you can have an Int32?

<comment><USER16> I've seen this come up a couple of times in this discussion, so ELI5: What is "type flowing"?

<comment><USER15> Flow typing is where the type of a variable changes based on control flow.

Consider:

        x : Int32 | String
        if x.is_a? Int32
          # typeof(x) == Int32
        else
          # typeof(x) == String
        end

<comment><USER16> Thanks!

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> > No one seems to know why C# behaves the way it does.

Operators are lifted[0] over nullability in C#. Every value type T can be converted implicitly to Nullable<T>. When `10 * null` is typechecked, both sides of * are typed as Nullable<T>. The * operator then acts like the pseudo- Haskell

      (*) <$> 10 <*> null

or, I guess

      liftA2 (*) (Just 10) Nothing

The semantics of Nullable<T> are similar to those of an optional type, with some implicit mapping and lifting. In that context, null acts less like null. (Thanks to convenient conversions.) Note that the following doesn't throw:

      int? value = null;
      value.HasValue // == false

[0]: [https://blogs.msdn.microsoft.com/ericlippert/2007/06/27/what...](https://blogs.msdn.microsoft.com/ericlippert/2007/06/27/what- exactly-does-lifted-mean/)

<comment><USER18> I came here to write this. What C# does in this case makes sense if you take the time to pick apart what it's actually doing.

</comment></comment><comment><USER19> If anyone wants to see for themselves what life is without null, TypeScript has an option to type-check for possible null/undefined values with strictNullChecks[0]. It's a game changer. The con: you have to check every variable that could be null/undefined before using it. The pro: you have to check every variable that could be null/undefined before using it :)

[0] [https://basarat.gitbooks.io/typescript/docs/options/strictNu...](https://basarat.gitbooks.io/typescript/docs/options/strictNullChecks.html)

<comment><USER20> Our stack is Typescript and Kotlin, and I find handling of null simple and safe, especially in Kotlin there is decent supporting functionality [https://kotlinlang.org/docs/reference/null- safety.html](https://kotlinlang.org/docs/reference/null-safety.html)

With Java we used @NotNull annotations and IDE support to give warnings. Luckily we are converting our legacy code base to Kotlin.

With conditional type conditions Typescript will have better support than earlier:

        type NonNullable<T> = Diff<T, null | undefined>;  // Remove null and undefined from T

Source and the examples in: [https://github.com/Microsoft/TypeScript/pull/21316](https://github.com/Microsoft/TypeScript/pull/21316)

</comment></comment><comment><USER21> _These laws apply to logical expressions about things that exist. In other words: you can't apply these laws to the unknown, which also includes the future. This is where we arrive at the edge of the rabbit hole: null represents nothingness /unknownness, so what the hell is it doing in a deterministic system of 1s and 0s?

Computer systems are purely logical, but the applications that we write, if they embrace Nulls, are apparently not. Null is neither true nor false, though it can be coerced through a truthy operation, so it violates Identity and Contradiction. It also violates Excluded Middle for the same reason. So why is it even there?_

And suddenly a bunch of type theorists just winced. It is possible to have trivalent logic that's coherent. SQL does this -- and it makes sense to do it in that application.

<comment><USER22> I really don't like throwing the word "pseudo-intellectual" around because its mostly used to mean "I think I'm smarter than you".

However, this person begins their article poisoning the well, saying,

> I find that the people I talk to about this instantly flip on the > condescension switch and try to mansplain this shit to me as if.

Proceeds to speak in that very same condescending tone, presenting a smarter- than-thou trundle down from the mountain. All the while including some nonesense about logic.

This person clearly has a chip on their shoulder: tacking on things about community-regulation in an article about Null, like all technical public engagement authors do. Let's signal "what good behaviour we expect" in the midst of a book pitch and a confused discussion of a technical matter.

One of these goals can be failed in its attempt with good nature. When you smush all this together it seems an exercise in performative intellectualism, or more accurately, pseudo-intellectualism.

</comment></comment><comment><USER23> I think this opinion makes some sense from a pure-functional standpoint, but not from an imperative one. In imperative programming, where you're managing lots of state, it's important to be able to represent the concept of a slot with nothing in it.

That said, I think a large portion of the problems caused by null could have been avoided by making one small change to its behavior: _accessing a member (or element) of a null should evaluate to null instead of throwing_. This is deeply intuitive and is the biggest cause of null pointer exceptions. If you try to access a.b, and a is null, it makes perfect sense that b is also null. Many languages have recently started adding an "optional chaining" operator that works this way, but a lot of pain could've been avoided if things were this way from the start.

<comment><USER24> I don't agree that this is a good behavior. I rarely need that behavior. NPE means that I forgot to handle null. And handling null usually means something other than use null for a result. NPE is hard to miss and stacktrace points exactly to the code that should be fixed. Propagating null will hide the code that should be fixed. I think that NPE behavior is the best solution without changing type system (and null-aware type system is just the best solution).

<comment><USER25> That's just your personal experience. Here's one from me: I use it all the time. I wish this was how js worked or that chaining operator would become standard soon. Reason is, there are times where you need some deeply nested variable in state, but it may not be already initialized, so you need to check it every time you access it. Gets tiring really fast.

</comment></comment></comment><comment><USER26> >> Logically-speaking, there is no such thing as Null (...)

Oh but there is.

The author is probably considering only propositional calculi with two truth values, such as Boolean algebra and, er, well, they're probably only considering Boolean algebra because that's what we use in computers, because it maps nicely to 0s and 1s.

However, two-valued logics are by no means the only possible logics, neither are they the only ones that have actually been described in the framework of mathematical logic. Probably the most well-known many-valued logics are Łukasiewicz's and Kleene's that have three truth values (i.e. values assigned to literals): true, false ...and unknown.

... which is to say, "null".

And just to blow your mind, there are also infinite-valued logics, like fuzzy logic and, I'd argue, the good old probability calculus of the reverend Bayes, which is nothing if not a many-valued logic.

The mistake is, I think, that the author is taking "logic" to mean Aristotelian logic, however that is not at all the logic we use in computers. Like I say above, computers use Boolean algebra which is an entirely different formal system with its own axioms, separate to grandpa Aristotle's own. For instance- Aristotle never said anything about functions, mappings from the set of literals to {0,1}, neither did he formally define the algebra of the Boolean operators AND, OR and NOT (a.k.a. conjunction, disjunction and negation). Although you can project Aristotelian logic onto Boolean logic, they are far from the same and I would really struggle to see how one would implement a programmable computer using Aristotelian logic.

P.S. Am I mansplaining now? Wouldn't that be a little ...weird?

<comment><USER27> >> Kleene's that have three truth values (i.e. values assigned to literals): true, false ...and unknown. ... which is to say, "null".

Regardless of what logics exist the statement you make - that "unknown" is "null" \- is actually wrong and the heart of the problem. "Unknown" is only one semantic interpretation of null; there are many others, and problems arise in software development because of those (sometimes slight) differences in the interpretation of what "null" should reflect in the real world.

Some sources suggest as many as 129 possible semantic meanings for "null", which is why Date rails against "null" values in SQL. With Option/Maybe we're constrained to the universe of values of that type plus exactly one more value (None); with null who knows how many of the 129 possible meanings of the null value we are dealing with in addition to the base type? Null is computationally and mentally expensive to deal with.

<comment><USER28> The same is true for true and false. What meaning gets attached to Boolean values is immaterial to how they act.

That null is implemented oddly doesn't negate the fact it's a meaningful and well defined mathematical construct.

I don't see people saying false doesn't exist because forth implements it as -1.

<comment><USER26> This.

Edit: removed unnecessary blablah.

</comment></comment></comment></comment><comment><USER29> The functional paradigm answer to this is to have an Option<T> type, or Result<TSuccess, TFailure>, which allow you to flexibly account for the "null case" while still having total functions ([https://en.m.wikipedia.org/wiki/Total_functional_programming](https://en.m.wikipedia.org/wiki/Total_functional_programming)).

The only catch, is now you have to unwrap your function results somehow (functional languages provide ways to do that, like the scary monad).

I like this website, which demonstrates the concept: [https://fsharpforfunandprofit.com/rop/](https://fsharpforfunandprofit.com/rop/)

<comment><USER30> Option monads have the same semantics as C# null described in the article; they don't apply the function if the value isn't present, you get another non- present value back out.

Result<,> has the same semantics as checked exceptions, BTW. The conversion between the two representations of code is mechanical.

Checked exceptions are a poor idea the more dynamically bound your language is, and are generally anti-abstraction in any case (failure modes are implementation specific, i.e. non-conformant with an information hiding interface). An error result is only useful if you can make a decision based on the specific value; that's not the case for almost all sources of error in most user (i.e. non-system) programs, where complete coverage of error cases with specific handlers is outside their design parameters, and termination (of program or request or whatever) is preferable.

<comment><USER29> It's about the ability to reason about the code. Option types force matching expressions whenever you encounter the wrapped value, forcing the developer to handle the failure case.

Equivalent C# code is to add checks for nulls all over the place, aka "defensive coding". C# has an Option type sort of with nullable types, but they are for value types only, and developers can still reach in and just grab the value, eliminating the safety that option types provide.

</comment></comment></comment><comment><USER31> I don't mean to defend Null.

 _> Null is neither true nor false, though it can be coerced through a truthy operation, so it violates Identity and Contradiction. It also violates Excluded Middle for the same reason._

Intuitionistic logic doesn't have the law of excluded middle and is the form of logic underlying the simply-typed lambda calculus.

There is a more nuanced relationship between logic and programming languages than is being discussed here.

</comment><comment><USER32> > Aristotle was the only logician and if you point me towards Buddhist or > Daoist philosophy, you're mansplaining!

OP should check out trinary logic and first-order predicate calculus. Just because OP doesn't appreciate "null" doesn't mean that it should be removed from programming languages or from existing programs.... false means not true, zero means no things, null means absence.

<comment><USER33> OP here - OP has checked out (and lived with) trinary logic. Just because you appreciate null doesn't mean it should be kept in programming languages and existing programs.

That there is a logical truism, isn't this fun?

Also: false means not true, zero is a number and null doesn't exist, by definition. We can model true/false/zero easily as they exist. Null is made up, so every language gets to think about what it means in an abstract made up way. Thus the pain, thus the post.

<comment><USER28> The last 100 years have been dealing with the fact that true and false are not enough to describe the world of computation. You also need undecidable, or null, for statements that can be proved to never terminate.

It is very much still an open question if a statement is absolutely undecidable and if we need to add something like null in all logic [0].

As for your arguments on why we don't need null, they sound exactly like the arguments against zero from the middle ages [1].

>Just as the rag doll wanted to be an eagle, the donkey a lion and the monkey a queen, the zero put on airs and pretended to be a digit.

[0] [http://logic.harvard.edu/koellner/QAU_reprint.pdf](http://logic.harvard.edu/koellner/QAU_reprint.pdf)

[1] Menninger, Karl (1969), Number Words and Number Symbols. Cambridge, Mass.: The M.I.T. Press.

</comment></comment></comment><comment><USER34> As a programmer with assembly language in my blood, all I can think is "Why should I care that this silly person thinks 'zero' doesn't exist?"

<comment><USER35> It's not that 'zero' doesn't exist.

It's that in assembly Null's just a zero.

</comment></comment><comment><USER36> I like the fact that the author says: "don't be complacent and mansplain your feelings about null", but that is exactly what he does...

People claiming the industry is wrong and that we should use some logically pure language are usually impractical and deny the compromise that must be made for systems to be usable by the masses.

<comment><USER37> A language does not need to be logically pure to avoid null. Having null in a modern language is simply a boneheaded mistake. There are no compromises that need to be made to get rid of it. Optional types are superior in every way.

<comment><USER38> How are they superior?

</comment></comment></comment><comment><USER39> C++ would be a lot better off if references were used more heavily. (And C ought to have references by now.) One still sees too many asterisks in C++ code. References are not supposed to be null. Sometimes they are, though, because there's no checking when a pointer is converted to a reference.

"this" should have been a reference, not a pointer. Strostrup admits that was a mistake.

<comment><USER40> technically references can't be null ever. To create a null reference you would have to deference a null pointer and then you are into nasal demons territory.

/pendantic

</comment></comment><comment><USER41> How is it possibly mansplaining to respond to this with an opinion or alternate explanation? Also... isn't the other's gender fairly important to the mansplaining comment since the term references the phenomenon of women being explained things they already know?

<comment><USER22> When a man is condescended to by other men we call that "communication", when a woman is its called "mansplaining".

</comment></comment><comment><USER42> C# has null because all new memory is initialized as all zeros. The constraint is that any object or struct needs to be valid if it's in-memory content is all zero. Thus, null must be supported for object references because the pointer has to support zero.

Value types can work without null because 0 is valid.

Could the language designers implement object types without null? It would be very difficult for fields, especially in structs, because it's nearly impossible to force memory initialization. You couldn't do "default (StructType)" if it had a not null object as a field.

<comment><USER43> It would be nice if C# simply had a nullable type for reference types. So like int? you could also have string? or SomeClass?. Structs with non-nullable reference types would have to be initialized at creation time. This would solve a lot of errors. But you still need to have the option to have nullable references.

</comment></comment><comment><USER44> Clearly there's a place for null: most languages have it, most developers have no problem with it, it does represent something (lack of information). It is logical and mathematical--I suggest you read the GEB book for tons of more info on that.

That said, people are _also_ free to experiment with null-free languages, or to avoid null. If it works for their use case, fantastic!

Just the attitude of the post is terrible. For example the user creates a sock puppet and posts a trolling/edgy question to Stack Overflow... just to see if it's toxic.

Sorry, these posts are toxic, in my opinion.

<comment><USER23> Yeah, it was super weird how the subject migrated from programming theory to a rant about stack overflow.

On the actual topic, I think a good compromise is what typescript and I think rust do, which is, a value is only nullable if you explicitly declare it as such. It forces you to be judicious, while still allowing you the option when you need it.

<comment><USER44> I've been trying that, but so far I don't find a big advantage, but it _is_ a bit annoying to have to annotate all types that could be null.

This is to say: it could be good, or it could be another "exceptions in Java" moment

</comment></comment></comment><comment><USER45> It's about leaky abstractions.

If programming is about managing complexity and status is ideally specified explicitly, then null is simply the option in a mathematical set defining that status which corresponds to the option commonly seen on surveys: _Other (please specify): ..._

While it can be handy to have this 'extra value' in a set, and it is most commonly used to denote special meanings within a carefully controlled context (eg. SQL column in a result set is empty, a variable is of no type - ie. not defined at all, etc.), issues arise when people accidentally carry context or presumptions about the meaning of null across contexts, creating a leaky abstraction.

Most of the author's article appears to deal with differences in these context-specific assumptions.

Perhaps the Java approach: throw an exception.

Unix approach? Nonzero return values and arbitrary stream or file data to clarify. In edge-case leakiness, very similar to the Java approach.

The functional and dedicated non-OO procedural programming approach: define exit parameters to your function, specifying complete precision and ending any ambiguity.

Since a type is a formal context (set), then using a typed language is another solution, although that adds overhead it brings benefits in rigor.

 _Sometimes, the elegant implementation is just a function. Not a method. Not a class. Not a framework. Just a function._ \- John Carmack

</comment><comment><USER46> Is "null" really the problem, or is not knowing the state of something the problem? I agree that it would be better for the world if we always knew what a "thing" was or referenced, but more often than not, we don't. Having a construct that expresses this uncertainty nicely models our own uncertainty.

</comment><comment><USER47> I always found this[0] analogy quite accurate whenever I discussed this issue with others.

Setting aside how different languages (mis)treat null as a concept, I think the whole discussion is about convoluting boolean logic with memory addresses and some languages do a better/worse job at being 'intuitive' than others.

I had great success with this[1] whenever I felt things were going in the wrong direction or when the language constructs of dealing with nulls were in the way of the domain design.

[0] [https://www.b4x.com/android/forum/attachments/unbenannt- jpg....](https://www.b4x.com/android/forum/attachments/unbenannt-jpg.54095/)

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

</comment><comment><USER30> C# has (a subset of) SQL null semantics because of LINQ. That's the answer to his specific question.

Null values propagating through expressions SQL style is an approach to handling unknown values. Whether it's desirable is somewhat besides the point; databases have null values, and LINQ enables capturing expression trees that get converted into SQL, so keeping similar semantics makes a kind of logical sense.

Nulls are undesirable in a language until you want to initialise large structures in a simple language with a simple compiler. Staying away from the temptation then takes ingenuity and discipline.

<comment><USER48> Was the behavior of null with integers really changed when LINQ was added? What would his examples have done in C# 1.0?

</comment></comment><comment> tuna-piano In an integer column in a relational database, what is the alternative of having null?

0 is not an option, as that will return incorrect mean/median calculations. So what would be there? Or am I misunderstanding?

<comment><USER49> If there is missing data to occur within a column, then pragmatically, you split that column off into its own table with the associated key from the original and store only those keys that have valid values.

If you do anything else, such as using nulls, then you are just creating a problem that WILL come back and bite you in the nether regions of your psyche.

Of course, there will other opinions about how to handle this. As far as I am concerned, Nulls are a curse foisted on us by those vendors and standards bodies who took the the easy way out.

<comment><USER50> > you split that column off into its own table with the associated key from > the original and store only those keys that have valid values.

That will create real problems and bite you immediately.

<comment><USER49> Demonstrate that it will bite you immediately. This technique has ensured that only valid data has been kept and that reporting works.

When nulls are stored there are no guarantees that anything you ask of the database will ever turn out right. Especially when there are millions of records stored. Two queries that should give you the same answer give different results when nulls exist. Seen it too often.

<comment><USER50> Table separation leads to record fragmentation and big IO cost on record fetching. Your ideal academic world will be crashed under production reality. "Millions of records". Bwa-ha-ha.

<comment><USER49> If your DBMS is so poorly written that record fragmentation is an issue then you need to change the DBMS. Since most (>99%) of the database design and implementation work that I have been involved since the mid-80's was business related and for a variety of different industries, I didn't find table separation to be a problem. The appropriate designs led to faster applications.

I have also worked for companies that didn't use relational database theory for their products and they had far more issues. In a couple, I was able to hive off the database designs from the main systems and got the applications to actually work and work properly.

</comment></comment></comment></comment></comment></comment><comment><USER51> Haskell have the _Maybe_ monad, which is defined as _Just a | Nothing_. One may argue then that languages with nullable integers implicitly define this type as _Maybe Int_.

<comment><USER52> That's the Maybe _type_. The _Maybe monad_ is this:

      instance Monad Maybe where
        return = Just
        Nothing >>= _ = Nothing
        Just x >>= f = f x

(And is not really related to the discussion)

<comment><USER51> Right! that definition was the type, thanks for the correction :) still, the Maybe monad is used for computations that may fail, which is often the purpose of the null pointer.

</comment></comment></comment><comment><USER3> > _This leads to an inconsistency: if to_i will turn nil into a 0, why won't > that coercion happen when trying to multiply?_

Because Ruby doesn't automatically coerce arbitrary types to numbers when you try to perform arithmetic on them. This is a Good Thing.

        2 * "4"

> TypeError

        2 * "4".to_i

> 8

Interestingly, it _is_ possible to multiply a string by a number, but no coercion takes place.

        "2" * 4

> "2222"

<comment><USER33> OP here - Yes that's the operation the question wasn't supposed to be a literal one, rather a consistency issue, which illustrates the larger point that different languages deal with null differently because it's not logical and therefore confusing and a pain in the ass :)

<comment><USER3> Languages are definitely not consistent in what they do if you try to coerce null to various types, nor are they consistent (often even internally) about whether they perform coercions implicitly. The Ruby example seemed to deal mostly with the latter.

I think implicit coercion is bad, but that's a separate issue from null.

</comment></comment></comment><comment><USER53> I have no clue why coding languages need null. I mean, they're deterministic, right? If something is missing, undefined or whatever, that's an error. What does the null concept gain you?

In data, on the other hand, null is a very useful concept. It explicitly means that there is no value in a field. And that prevents such mischief as interpreting missing data as zeros.

<comment><USER54> In a language like C, NULL solves problems that are otherwise awkward to solve.

1\. What should `malloc()` return on failure?

2\. How should I indicate that I don't care about certain out parameters, e.g. the parameter to `time()`?

3\. How should I initialize variables that are going to be used as out parameters, e.g. in `strtol()`?

Other languages address these at the cost of significantly complicating their type system and ABI: generics, multiple return values, etc. In a language intended to be small like C, I'm not sure how you can do better.

<comment><USER53> Thanks. But ...

1\. Why not just return meaningful values? Wouldn't that help in debugging?

2) ???

3) That makes sense to me.

<comment><USER55> C functions can only return one value. Since the stdlib generally adheres to the idea of minimizing overhead, that would mean malloc would have to accept a mutable reference to a reference, so it could assign the reference it returns. Since null references are unusable, using that impossible value as your error flag is a pretty clever optimization.

<comment><USER53> Thanks, I see that.

But isn't ambiguity the tradeoff?

</comment></comment></comment></comment></comment><comment><USER56> Null/nil tends to represent the absence of a thing. That's perfectly logical. Things can be absent.

</comment><comment><USER57> Kotlin solves this problem nicely, assuming your codebase is all new or has been annotated with @Nullable/@NotNull

[https://kotlinlang.org/docs/reference/null- safety.html](https://kotlinlang.org/docs/reference/null-safety.html)

<comment><USER58> It doesn't seem that nice to me compared to making it impossible to assign nulls everywhere, without the need of annotating anything.

</comment></comment><comment><USER59> Surprised there's no mention of Kotlin here. It handles this really nicely, forcing you to declare if a value can be null and if it is null it requires a null check before it can be used (with some syntax sugar to make that cleaner)

</comment><comment><USER60> Even if you eradicate Null, programmers will create a singleton object to represent it.

<comment><USER61> Yeah, just like they invented Unit/Void singleton in functional languages.

</comment></comment><comment><USER62> Unknowns are not even remotely problematic for logic. Not only SQL, but illustrious languages such as VB6, include built-in trivalent logic.

<comment><USER63> Yeah and the results are so massively intuitive.

<comment><USER62> I suppose this is sarcasm but the results are quite intuitive to me. From my perspective, it's trivial to construct the truth tables for trivalent logic based on a sense of what "should" be in them. Maybe give it a try.

<comment><USER63> Well guess what. Your "sense" of what "should" be in them has no place in computer _SCIENCE_.

Computer _SCIENCE_ is that ugly thing that tells us that three-valued logic gives rise to 19683 distinct binary logical operators, while two-valued has 16.

Computer _SCIENCE_ is that ugly thing that tells us that if you want a computer language over a three-valued logic to be expressively complete, then you need to implement all of those 19683 logical binary operators one way or another. In the worst case, that's 19683 operator names for the programmer to remember. And you come here claiming that it's "trivial" because you have a "sense" of what the results ought to be ? That proves just one thing but site policy probably won't allow me to spell that out.

(In case you were wondering what the 16 names are in two-valued logic : they aren't needed because the system being two-valued gives rise to certain symmetries that gracefully allow us to reduce the set we need to remember to just {AND OR NOT} (or some such) which beautifully parallels the way we communicate in everyday life.)

<comment><USER62> Ah, you seem to be a bit nutters. So I'm not going to engage further but I do want to give you a serious response to the argument you seem to be making.

First, the same argument above is also an argument that, say, integers, are not "Computer SCIENCE".

More to the point, you might enjoy reading the work of Charles Pierce and other logicians of that era who began to explore many variations on formal logic. Note that just as many operations arise from trinary relations in bivalent logic. Are binary relations "Computer SCIENCE", but not trinary or higher relations? Before you answer, you might want to look into whether all possible relations can be expressed using only binary relations (hint: nope).

Look deeper into the concept of functional completeness (with respect to a subset of operators), which you reference above without naming. You might be able to understand how many of those many trivalent operators are actually necessary to reason with (hint: not very many, hardly more than for bivalent logic, where, as you note, we only tend to use a few, and need not worry about it).

Consider also the relationship between operators folks have identified as useful in bivalent vs trivalent logic (hint: they not picking at random).

Could it be that just as with the 16 binary operators, many of which have relations to one another (e.g. inverses and complements, among others) that the trinary operators could fall into similar groups, which, making the 3^9 number you mentioned seem a whole lot less complex? Could that be _why_ it's neither necessary nor customary to work with all the operators in either sort of logic?

Once you've caught up to state of the art in formal logic as of the 1930's you might have a new perspective -- perhaps you might even begin to let us know when "Computer SCIENCE" will catch up!

<comment><USER63> If you wanted that to be a _real argument_ then you _should have done the maths yourself_. Without those maths you are doing nothing but gratuitious handwaving. I've done them for you and they prove me right (and you wrong at least where you say "hardly more than for bivalent logic").

Oh, and if you want to know _why_ people don't _want_ to find more "useful" operators than what they're used to from good old two-valued logic then I have a hint for you too : it's because they all immediately sense that their brains are not up to it as soon as they actually try (and my actually doing the maths has very clearly shown me why - so as you suggested to me "perhaps give it a try").

</comment></comment></comment></comment></comment></comment><comment><USER64>
      > Logically speaking, there is no such thing as Null

Yes, there is:

      "Did you pass your test?"
      "I haven't taken it yet."
      "Okay, will you pass it?"
      "Null."

Suppose there was a database table of students, with a column called "passed," which is boolean. If it's in the middle of the semester, that column must be null. True means they passed. False is put there when they fail.

\---

Another example, in a table of help tickets, suppose there is a timestamp field called "closed," for when the ticket was closed. If the ticket is open, then that column must be null.

\---

      "Which show is currently playing on channel 3?"
      "It's just static. It's midnight, and channel 3 has stopped broadcasting."

(This of course must have been back in the '80s.)

If the TV guide were a database table, with time slots for each channel, then the columns for which show is scheduled for midnight on channel 3 must be null.

In fact, that's how I picture null: ever-shifting static inside the little cell in my database table. That's why I'm fine with how if you ask if two null values equal, the answer is null (at least in Postgres).

Someone may say that there is a show currently on channel 3, and the name of the show is "Static." But that's not quite true. If channel 3 recorded static and broadcast it, then yes. But channel 3 has literally turned off its tower. It is broadcasting nothing. Your TV is showing static because you tuned to a station that is not there.

\---

The writer complains about inconsistent implementations of null, like in JavaScript. I agree that there are misimplementations. I would not have had both null and undefined.

In fact, that's another way of understanding what null is. Suppose you say my earlier examples with SQL are flawed, because SQL is flawed, because it insists on every row having columns it doesn't need, that the field for "passed" should even exist in that row until the class is over. Say instead you were using objects. Within the semester it may look like this:

      {
         name: "Edgar Smith"
      }

Then at the end you add:

      {
         name: "Edgar Smith",
         passed: true
      }

Well, what if you asked for the value of student.passed in the middle of the semester? You might say it is a mistake, but it is a question that can be grammatically formed: "What is the value of the 'passed' key in the object?" The only answer is null. To me null often means "not applicable."

\---

Again, another example. In school we played a game of guess-the-object, where you could ask only yes-or-no questions. There were three possible answers: yes, no, or "does not compute." Clearly the answer of "does not compute" was needed for when the answer was neither yes or no. "Does not compute" was a fancy synonym for "null."

\---

Null is the answer to the infamous loaded question, "When did you stop beating your wife?"

\---

Null is quantum foam. It is what is happening at the base of the universe, if you look close enough. Is the particle here or there? Null.

You may say that doesn't make sense, that it's just that we don't have the right instruments. But that is Quantum Mechanics. If you wish to disprove Quantum Mechanics, Einstein and I would both be interested, as he was uneasy with it too. But going after quantum mechanics would be a better use of your time than going after null. Right now, null and the scientific consensus about physical reality agree.

</comment><comment><USER65> I've been coding since around 1981. What changed my coding style most, is Option when I've started Scala 10y ago.

<comment><USER66> Scala is a very confused language and specially about the use of Options vs null. I find that Rust and Swift enforce Options a lot better.

</comment></comment><comment><USER67> This was a decent post until he went on the stack overflow rant.

</comment><comment><USER68> Someone needs to write an essay on the productivity disaster of "considered harmful" essays.

We traded _goto_ for callback hell and ten-layer inheritance hierarchies. A null-purge would probably end similarly.

</comment><comment><USER69> What I'd like to tell the author.

Don't like null? Don't use it.. and you find null propagation ruining your abstraction then treat it as an error and fix your program.

<comment><USER33> OP here - as a matter of fact I try to do just this, starting with the database. I'm mostly a data person so I try to think through, as deeply as I can, what I should expect in every table - there _has_ to be a sensible default and if I can't find one then I rethink my design. You'll probably disagree with me and grunt out another single sentence missive, which is fine, but I think it's worth taking some extra time and using Null as a bit of a warning. It's a crutch! A way to stop thinking and say "whatever I don't know what this value is supposed to be so... it's null. Let's go shopping!"

<comment><USER70> What do you use in a database when you have a field where you literally do not know what the value should be?

<comment><USER71> If you have a PEOPLE table and some birthdates are unknown, then remove the "birthdate" column and make another table called PEOPLE_BIRTHDATES with a "birthdate" column and a foreign key pointing to PEOPLE. Now your queries can have lots of left joins. The results will still have nulls, however.

<comment><USER63> Which is the reason why you shouldn't write outer joins.

<comment><USER71> So if we don't know the customer's birthdate we can't serve her? I can imagine a problem with that...

<comment><USER63> Sigh.

Where have I said any such thing ?

<comment><USER71> If there's no row for the customer in the joined table, the customer won't show up in an inner join.

<comment><USER63> Great. Now if you can explain to me where you got the idea that a join (inner or otherwise) is the _only_ possible way to query two tables then we might get somewhere. Because you can also just do two queries. And no, that does not necessarily mean "two roundtrips to the DBMS" (which I know perfectly well is undesirable). There are techniques for avoiding that. Perhaps not in SQL, but that's a reason you should be pressing the vendors to improve SQL. Not for you to agree to the status quo of sticking with the vendors' old bypasses-and- hacks cheating bag.

<comment><USER71> Haha OK then use a UNION... oh wait we're gonna have NULLs with that too. One suspects you'll also have some vague objection to this point, but if the only way to address that is to wait on somebody to invent an "improved" SQL, one won't worry about it too much.

<comment><USER63> That "improved SQL" was already defined in the previous century, and has been implemented as well. Your ignorance drips off of every word you write.

<comment><USER70> E.F. Codd literally designed null into the relational model. I don't think calling someone ignorant is very helpful.

<comment><USER63> But the demeaning ridicule that gets thrown at me is ?

(BTW I doubt very much that "Codd designed null into the RM". Even his 12 rules mention only "a systemic way to deal with missing information", not "null".)</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment>


Life is all about killing the magic - <AUTHOR> http://www.micaelwidell.com/p/19/

<comment><USER2> If anything I've learned that the fastest way to discover just unboundedly large amounts of magic is to try to kill that of it which you know.

Fields don't die---they deepen fractal-like.

<comment><USER3> I agree with this.

The author said he has learned everything about computers and the magic is gone, because it understands them.

Is this really possible? The world of computers and the internet is so deep, it seems like someone could study for their whole lives and never fully understand it all.

<comment><USER4> > Is this really possible?

Yeah, you can definitely understand computers to the point that nothing about them is really mysterious. It takes a while, but lots of people have done it. There might be lots that you aren't aware of - but none of it will come as a surprise once you've learned how it all works.

I guess at some fundamental level, though, it's based on (quantum) physics, and lots of that is still mysterious to us. But that's way deeper than anything you come across with computers.

<comment><USER2> I suppose this is true, so long as you're talking about the physical artifacts that we've created as a society. I think it's importantly less true if you begin to ask questions such as why this particular machine is so powerful, what it's limits are, and how its operation relates to other things.

Perhaps I misspoke in saying that seeking to eliminate the magic is enough. You have to follow more threads than the ones that originally lead you into the wings.

</comment></comment></comment></comment><comment><USER5> If you think you've learned everything about a field, you've just scratched the surface.

<comment><USER6> That is, unless you do have a good general knowledge of the field, up-to-date with recent research and have publications of your own.

<comment><USER7> I can see why one would think they know everything about a field just because one "has a good general knowledge of the field, up to date with recent research, and have publications of your own" for the following fact (noted by Donald Rumsfeld)

"There are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don't know. But there are also unknown unknowns – there are things we do not know we don't know."

</comment></comment></comment><comment><USER8> The downside of attempting to kill all the magic in the world is that, should you ever succeed, you will be so bored you will want to die. I was never so happy as I was as a child, when everything was fresh and new. I try keep a little bit of magic unknown still. Fortunately that's pretty easy to do in today's world.

</comment><comment><USER9> If understanding computers kills the magic then someone has completely missed the point. Computers are a tool to be used,not a mystery to be solved,and there is plenty of magic using them to explore to build and to solve actual mysteries.

If you understand a hammer and chisel fully it does not make you Michelangelo.

</comment><comment><USER10> Why not try the opposite approach? That is, try to find magic in everyday things.

</comment><comment><USER11> If he knows all there is to know about computers, perhaps he can tell us whether P = NP.

<comment><USER12> Most computer scientists feel that P != NP and it's just a matter of figuring out a way to prove it.

<comment><USER13> Then it's a good thing computer science isn't driven by feelings.

<comment><USER12> You'd be surprised by how much of it (mathematics) is. You obviously can't prove anything with gut feeling, but you can sure find things to prove with it.</comment></comment></comment></comment>


Germany is testing public hazard alerting(now) - <AUTHOR> https://www.bbk.bund.de/DE/AufgabenundAusstattung/Krisenmanagement/WarnungderBevoelkerung/Bundesweiter_Warntag/Bundesweiter_Warntag_node.html <comment><USER2> As someone who is living smack in the center of the capital - I think this test was a pretty big fail. No sirens, no cell broadcast, people who had a hazard alerting app installed got the notification 30 minutes late. Lots of room for improvement, let's hope next years test will be more fruitful.

<comment><USER3> Actually, there are no sirens in Berlin at all. They got all decomissioned in the 90s.

Some municipalities still habe sirens, either because past experiences with industry accidents (chemical plants) or to summon the (citizen) fire brigate. Seems Berlin has neither.

</comment></comment><comment><USER4> bigger discussion [https://news.ycombinator.com/item?id=24430145](https://news.ycombinator.com/item?id=24430145)</comment>


From idea to core prototype in hours, not weeks - <AUTHOR> http://williamnewton.co/blog/prototype-in-hours-not-weeks/

<comment><USER2> Mockup.

This guy is talking about building mockups, and only mockups.

A prototype is a working version of all key features that can be used as if it were the final product albeit in a somewhat limited fashion (E.g. the edges aren't rounded)

A mockup demonstrates the value in a non-working fashion so people can respond to the general idea.

If you don't get mockup vs prototype right, it's pretty hard for me to value your opinion on these matters.

<comment><AUTHOR> This post is talking about prototypes from a usability perspective, not a technical perspective. A prototype by your definition ( a "real" prototype) would use data and be built in about the same way as the final product would be. I'm talking about how to prototype the experience. I see how it's easy for you to misunderstand me - apologies for not being clear.

<comment><USER2> Then it would be helpful if you qualify prototype as "ux prototype" or "interaction prototype". Paper prototypes, which this is fairly similar to, is a term that is lexically unambiguous. Without the qualification the title becomes confusing. I initially thought you were claiming to have a methodology to get a "real" non trivial prototype in a few hours.

</comment></comment></comment><comment><USER3> IMHO, I don't know why people keep confusing UI with UX like they are the same thing, do you actually design the "UX" base on your own intuition without even know or test what the audience you are targeting for the specific product?. This more a wire framing to me, since this "prototype" is far from finish. I wait to read the next chapter since you it seems that it will address some of my concerns above :). Cheers

<comment><AUTHOR> Exactly — start with intuition then get feedback and fix what you were wrong about. And it's definitely far from finished. Thanks!

</comment></comment><comment><USER4> I too am a fan of rapid prototyping, but the example app here is incredibly simple. More complex apps require more time to refine & prototype.

That said, this sort of flat prototype should be do-able in a few days for even the largest of apps.

So, I'm in agreement with OP — except on the timeframe :)

</comment><comment><USER5> This is a great post, but in these comments there is a strange fixation on the terminology. Is it really a mockup? Is the author describing an interface or an experience? None of these comments really say why the distinction is more important than the point of the post, which is to get an idea in front of users.

But if the obsession over the term is forcing you to ignore the point of this post, possibly this will help: a guy at Google apparently decided that the distinction was enough to coin the word "pretotyping": [http://www.scribd.com/doc/62418833/Pretotype-It-Second- Preto...](http://www.scribd.com/doc/62418833/Pretotype-It-Second-Pretotype- Edition#page=23)

(Even if the terminology doesn't matter to you, skim the book--it's free here and has got some great ideas).

</comment><comment><USER6> Nice job, though you could argue a big part of the prototyping (in fact, the main feature) was already completed. Most of the design decisions, illustration and how the information should be displayed had already been 90% provided by Neila.

<comment><AUTHOR> That's accurate, and I think that's all the more reason to jump in and start. The content is all there, but there's more detail needed to make an app like this awesome, including stats and UX polish. I'm advocating for the 'just start' approach.

<comment><USER6> Indeed, the "just start" approach is awesome. It cuts the excuses people find to continue to "prepare" or procrastinate.

</comment></comment></comment><comment><USER7> I completely agree with your last point on getting feedback and iterating on your designs. Prototyping is such an important part of the design process. ABP (always be prototyping.) I wanted a prototyping solution that worked within a designer's existing workflow which is why we built Stand In [[http://standin.io](http://standin.io)] on top of Photoshop. It allows us to keep the prototype always in sync with the design and truly becomes part of the design process — not just a step afterwards.

<comment><AUTHOR> I would use Standin if I used Adobe CC. Nicely done.

</comment></comment><comment><USER8> I'm a bit confused by the article's blurring of design and prototyping boundaries. Is it reasonable (i.e. useful) to convolute wire framing with prototyping? I once worked as a prototyper for a design studio, and to them prototype meant an approximation of the product that could be used for critique and evaluation with users (so maybe a lofi paper prototype, deck-like click-thru prototype, or even a quick/dirty application).

<comment><AUTHOR> Is it not clear that my approach is to 1. map out the idea (wireframing) and then 2. hack together a prototype?

<comment><USER8> Your post mixes together wireframing with prototype hacking. But I guess this is to be expected when programmers are doing design, a designer would look at this very differently.

<comment><USER3> Agree.

</comment></comment></comment></comment><comment><USER9> I worked in a large, supposedly ground breaking digital agency where we had a game manufacturer as client. The client were keen on agile and continuos prototyping / mockups. Sadly the designers (pardon, 'creatives') and ux didn't want to know, the were too set in their ways and couldn't get out of the old workflow: work Photoshop / OmniGraffle; refine until perfect; pass on to developer. Eventually the client got pissed off and we lost them. The visual people just couldn't get their head around not having complete perfection at each step of the way. Shame, because it was a great project.

<comment><USER10> This resonates pretty well with me due to my current role in an organization. Did anyone own the execution side of the project to hold the designers accountable for late deliverables?

<comment><USER9> Of course not, it was a creative agency, our job as developers was to cater to every creative's wish

</comment></comment></comment><comment><USER11> I think this is how most people work, unless you're a consultant that get paid by the amount of deliverables you produce. :-)

Prototyping to solve problems is often the quickest. Pulling other people's teeth to reach that point is what takes weeks. :-)

</comment><comment><USER12> nice</comment>


Ask HN: How did developers use to accept payment before Stripe? - <AUTHOR> <comment><USER2> For software, there were lots of services targeted at independent ("shareware") developers, who would host the SSL page order forms for the developer so they didn't have to deal with PCI Compliance.

Kagi was one of the earliest, especially on the Mac. But there were others like SWREG, ShareIt, eSellerate, Plimus, Cleverbridge and many others. The Black Cat Systems Overview Of Shareware Registration Services [1] used to be the chart you'd send newbies to when they asked which e-commerce service to use.

Whenever a new service started up, it would almost always get acquired by Digital River (aka "The Borg", since they assimilated everything and resistance was futile).

Some of those services are still around, like FastSpring and Paddle. Avangate ended up buying 2Checkout and then rebranding to call themselves 2Checkout. The main advantage of those companies now is they offer global tax compliance, now that the EU and several other countries want you to charge and collect tax based on where the customer is, not where your business is.

[1] [http://www.blackcatsystems.com/regservices/](http://www.blackcatsystems.com/regservices/)

</comment><comment><USER3> It was painful. I'm mostly referring to legacy apps like online bill payment and stuff, especially ones that also wanted to do ACH transactions. You had to sign up with some sort of "payment gateway". Usually they had an api spec of XML or other legacy web services, file formats for interchange, etc that filled a whole binder. Since many people didn't want the compliance hassle of storing credit card & ach info, this was still 'easier' to implement.

Stripe pretty much came along and crapped on all of that ( in a good way ). And lowered the barrier to entry so indie dev shops could accept CC payments seamlessly as the other big megacorps.

</comment><comment><USER4> PayPal, Authorize.net, Braintree, quite a few others, most still available.

</comment><comment><USER5> PayPal buttons made it pretty easy but the user flow for someone without a PayPal account or with a PayPal account but that wanted to pay with a credit card wasn't super great.

</comment><comment><USER6> This is so US-centric question :)

Stripe is not a thing in most of the countries on this planet.</comment>


Why isn't there more iPhone/Android applications that use speech recognition?  - <AUTHOR>

I was going through iPhone App Store and wondering why isn't there more apps that use speech recognition? Are there any good libraries (free or commercial) for speech recognition? <comment><USER2> Voice recognition is more or less included in Android. With the new updates, any text box can be filled with voice text. According to [http://www.4feets.com/2009/04/speech-recognition-in- android-...](http://www.4feets.com/2009/04/speech-recognition-in-android- sdk-15/) (first hit on Google) it looks like there's a class that you can use as well.

<comment><AUTHOR> Thanks. I didn't search that much on Android. I just assumed that situation would be similar to iPhone.</comment></comment>


Difference between law and official instructions - <AUTHOR> https://www.thetimes.co.uk/article/there-is-a-difference-between-the-law-and-official-instructions-j9tthqnrf <comment><AUTHOR> De-paywalled: [https://archive.is/Jf1P2](https://archive.is/Jf1P2)</comment>


Show HN: "rich text" for Twitter via unicode - <AUTHOR> http://bedazzle.gordn.org/

<comment><USER2> Nice idea. For anyone wondering how it looks in Chrome on Windows 7: [http://imgur.com/Weu6dpG](http://imgur.com/Weu6dpG) \-- so I hope that it doesn't catch on [until my OS can handle it]-

<comment><USER3> Can confirm the same for Chrome Windows 8.1 too, never knew my machine's unicode support was so dire.</comment></comment>


Theranos Agrees to Pay $4.65M in Arizona Refunds - <AUTHOR> https://www.bloomberg.com/news/articles/2017-04-18/theranos-agrees-to-pay-4-65-million-in-arizona-refunds <comment><USER3> The biggest takeaway from Theranos is that investigative Journalism is not dead. John Careryu (sp?) single handedly dug up the truth in a non disparaging factual manner and went up against a team of ruthless lawyers threatening to utterly destroy him, the Journal, and his source. That source was a 24 year old hero whose parents put up their house as collateral just to help their son do the right thing when he had no monetary gain from it. After learning so much about the bullshit Theranos did, every nail that pushes it further into the ground has given me a justice euphoria high. I'll be following this until it's end

<comment><USER4> That's John Carreyrou of The Wall Street Journal's investigative reporting team. [1]

[1] [http://www.wsj.com/news/author/1282](http://www.wsj.com/news/author/1282)

</comment></comment><comment><USER5> The story of Theranos makes me think about where the "great filter" lines for startups are.

My prior company - who I was with from ~20 people to the current 300+ - <USER2> been going through some shakeups that make me wonder. This adds to my thinking.

I'd have thought that both were past those lines - hundreds of people, multiple offices? Seems like it'd be solid at that point.

The common factor is that both have yet to release their "flagship" product, although they've released products.

Then you can think about small products with small teams - Sidekiq, Cards Against Humanity - that achieve substantial success.

It seems like this is the most telling "filter" \- did you release your core product?

Thoughts?

<comment><USER6> You could say Theranos' core product was "released" \- they were doing blood testing. Maybe _badly_. Maybe clandestinely on other equipment. But as far as the rest of the world was concerned it was "working".

Plus you have to define what "core product" means. Is it the bit that makes money? A lot of startups have slotted the money making bit in later and gone alright; others never really could figure that out.

And... relatively boring companies with real business can transform themselves into "house of cards built on lies" type businesses pretty easily, too. Think about Enron, or any financial firm that went heavily in on the subprime mortgages.

<comment><USER5> Maybe their core product, but not their flagship product.

Theranos was built on the promise of an amazing new tech for blood testing, not on the promise of blood testing.

By "flagship product" I mean the thing you're basing your corporate identity on. Like the stereotypical waiter in LA, they're actually an actor; their identity (flagship product) is actor, but their day job (released/core products) is something else.

</comment></comment></comment><comment><USER7> How long would this have gone on if not for the investigative piece? Would it have eventually cost someone their life? That's the scary part.

</comment><comment><USER8> where's fu*kedcompany.com when you need it...

</comment><comment><USER9> I remember thinking Theranos/Elizabeth Holmes was too good to be true from the very first time I read about it, no lie. Was it really plausible that this young woman could come up with an idea that the whole medical industry had missed? I can't quite articulate why, but it just didn't seem like medicine would be ripe for disruption in the same way as other industries that we've seen turned upside down. It takes _decades_ for advances in cancer etc. Had Theranos really managed to stumble on something the entrenched players had missed? Such a strange story, so much money apparently squandered, and yet the zombie still stumbles on. How long before it's finally put out of its misery?!

</comment><comment><USER10> Could we have a summary for people like me who are not familiar with them?

What's the case on Theranos? what did they do and sale? What happened?

<comment><USER11> [https://hn.algolia.com/?query=Theranos&sort=byPopularity&pre...](https://hn.algolia.com/?query=Theranos&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

<comment><USER10> It's clearly evil and bad judging by the title.

Opened two random articles... and they were two WSJ paywalled articles. OMG.

<comment><USER11> The Wall Street Journal did the initial, in depth reporting.

</comment></comment></comment></comment><comment><USER12> To my disgust, the biggest thing most people seem to take away from it is "Yup, that's what happens when a woman is in charge of a business."

I'm a woman. I am fine with her burning. But, geez, I hate the idea that there is lava-like splash back spattering all other women in the world who are trying to be taken seriously.

<comment><USER3> I think when this broke, her connection to Hillary and the Clinton Foundation kept being played. Also during that same week, news broke that Marissa Mayer hid the huge yahoo data breech from users for years and purposefully didn't take ethical actions addresssing known vulnerabilities. These are three of the most powerful self made women all of whom were heavily publicized for years. The anti-Clinton sentiment along with valid criticism against Holmes and Mayer very well could have burgeoned into an anti-women sentiment.

As for the sexism, I felt like it was more of a backlash against the unrelenting positive press Holmes received for years, right or not partly due to her gender. Every time someone commented on why they thought something was wrong with Theranos they were drowned out by voices telling them to stop being sexist and you want her to fail due to her gender. Justified or not, plenty were happy to see her fail after all the praise she had recieved and I am not surprised at all if some of the blowback was sexist.

That being said, the majority of the discussion was anti-Theranos though I do agree with you there were a fair bit of anti-woman backlash though like I said much of it I feel was prompted by the positive praise she received.

<comment><USER13> At what point does positive press become "unrelenting"?

This is just stupid.

Are you saying that Theranos was over-hyped?

If that's what you mean then just say it.

This is really survivor bias talking. If something actually succeeds at delivering the moon, then there's no unrelenting positive press. There was an accurate depiction of what was going on. It's only in hindsight that you can call it hype or unrelenting.

And the schadenfreude is doubletime now because not only did the hype fail, but she was also a woman.</comment></comment></comment>


Google begged Steve Jobs for permission to hire engineers for its Paris office - <AUTHOR> http://pando.com/2014/03/27/how-steve-jobs-forced-google-to-cancel-its-plan-to-open-a-paris-office/

<comment><USER2> Isn't it a good thing? Companies should be competing for talent, not vice versa.

Once you reach the level of Jean-Marie Hullot and his team, you are lifetimes past the _please hire me_ routine. So he spent the next couple years travelling instead of helping Google sell more ads... good for him, his old friend Jobs did him a favour.

<comment><USER3> And the engineers who worked for him and apparently stayed unemployed for quite a few months due to the Google carrot in front of them?</comment></comment>


Play Deals – Get list of paid apps which are currently free or has deal - <AUTHOR> https://play.google.com/store/apps/details?id=me.sujanpoudel.playdeals <comment><AUTHOR> It is currently in public beta, if there are any feedbacks please let me know.

Thank you</comment>


A D3 visualization of drone strikes in Pakistan since 2004 - <AUTHOR> http://drones.pitchinteractive.com/index.html <comment><USER2> Interesting, especially cause the final graph goes somewhat against the point (I think) they are trying to make.

It seems the last 2 years have shown a drastic decrease in civilian and children casualties.</comment>


Microsoft's Hottest New Profit Center: Android - <AUTHOR> http://www.networkworld.com/news/2011/070511-microsoft-patent-android.html?hpg1=bn One of Microsoft's hottest new profit centers is a smartphone platform you've definitely heard of: Android. Google's Linux-based mobile operating system is a favorite target for Microsoft's patent attorneys, who are suing numerous Android vendors and just today announced that another manufacturer has agreed to write checks to Microsoft every time it ships an Android device. Vendors paying off Microsoft for the right to use Android now include HTC, Velocity Micro, General Dynamics, Onkyo Corp. and Wistron. Microsoft likely makes more money from Android than its own Windows phone platform, and its latest patent agreement announced Tuesday indicates Microsoft is also going after Google's Linux-based Chromebooks. <comment><USER2> "We are pleased that Wistron is taking advantage of our industrywide licensing program, established to help companies address Android's IP issues," Microsoft general counsel Horacio Gutierrez said in a press release.

That is the most infuriatingly worded press release ever. Might as well just say that you're very pleased Wistron agreed to let you bend them over the counter to address Microsoft's inability to compete issue.

<comment><USER3> The smugness just _oozes_ through the page. These kinds of chickenshit tactics are the desperate moves of a stagnant company. The happiest development of my career has been watching the industry emerge from under the shadow of the software mafiosos at Redmond. If the U.S. patent system isn't reformed soon the baton of innovation will pass to other countries that don't enable these extortion schemes.

</comment></comment><comment><USER4> What specifically are the IP issues that Android has? I looked in the article but there was only a passing mention of some claims in a link. A couple of the claims looked like they were about long and short filenames. If that's true then software patents are truly evil and should be abolished yesterday. :/

<comment><USER5> MS maintains that Linux kernel violates its patents, and sues anyone who makes enough money with a product using Linux (e.g., TomTom [1]).

MS likes to refer to "235 patents" that Linux allegedly violates, but they aren't forthcoming with what the specific violations are. That said, they do have some fairly ridiculous patents under their belts, (like the FAT filesystem [2]), so they could probably dredge something up.

With Android more specifically, there is also ActiveSync (Exchange's protocol).

[1] [http://www.techflash.com/seattle/2009/02/QA_Microsofts_chief...](http://www.techflash.com/seattle/2009/02/QA_Microsofts_chief_patent_lawyer_on_TomTom_and_Linux_40354407.html)

[2] [http://news.cnet.com/Microsofts-file-system-patent- upheld/21...](http://news.cnet.com/Microsofts-file-system-patent- upheld/2100-1012_3-6025447.html)

</comment></comment><comment><USER6> This is America's new legal strategy: beating up the small guys with big sticks. Companies with patents go after small companies or individual developers with their patents -- IBM never gets sued for patent infringement. Companies with copyrights go after as many little guys as possible, and make their money "in volume" because file-sharing lawsuits are cheaper to settle than to contest.

This is not "promoting the progress of the arts"; it's bullies shaking us all down, with the government happily watching.

</comment><comment><USER7> B-B-But I thought that Microsoft was only acquiring patents to protect itself from evil other companies that would have patented these things and then sued Microsoft! They were supposed to be _defensive_ patents... </sarcasm>

<comment><USER8> I'd like to see a citation of Microsoft saying their patents were going to be used only defensively.

I think it's _completely_ in their nature to block and bleed competitors.

<comment><USER9> Quite the opposite in fact. MS has been rather blunt that they haven't been pleased with Linux's use of what they believed was patented technology and that they'd take action. IMO, the real question is what took them so long, since the first threats were made years ago.

With that said MS has never threatened anything beyond Linux, at least that I can recall. Linux appears to have a special place in their heart.

</comment></comment></comment><comment><USER10> Is there any reason why Microsoft isn't going after Google? I recall reading somewhere that it's because Google isn't actually producing the phone. Can anyone confirm this, or is just cowardice?

<comment><USER11> There is a difference between direct and indirect patent infringement. Google provides the Android source, but the companies that are being sued are directly infringing by selling and distributing products based on these patents. [http://en.wikipedia.org/wiki/Patent_infringement_under_Unite...](http://en.wikipedia.org/wiki/Patent_infringement_under_United_States_law)

Google naturally has the choice to indemnify Android distributors and protect them from patent infringement. Google chooses not to do this, presumably because they do not want to expose themselves to the costs of direct patent infringement.

<comment><USER12> Does the Nexus One or Nexus S blur this line at all? In that case, it seems like Google is doing more than simply making the source code available. Those phones actually carry its brand.

<comment><USER9> Microsoft has a deal with Samsung already in place. See: [http://news.cnet.com/Microsoft%2C-Samsung-in-patent-swap- dea...](http://news.cnet.com/Microsoft%2C-Samsung-in-patent-swap- deal/2100-1014_3-6177381.html)

 _the software maker specifically notes that the deal will allow Samsung to offer products using Linux without concern that Microsoft will sue it or its customers._

And another deal with HTC. [http://www.androidguys.com/2010/04/28/htc-pay- microsoft-roya...](http://www.androidguys.com/2010/04/28/htc-pay-microsoft- royalties-android-phones/)

So both of those phones are covered.

</comment></comment></comment></comment><comment><USER13> Interesting news. But has a page 2. So, I can't read the story to the end, nor give you the actually earned upvote. Really sorry, Jon.

<comment><USER14> Like a lot of sites there is the print button which includes the entire article.

[http://www.networkworld.com/cgi- bin/mailto/x.cgi?pagetosend=...](http://www.networkworld.com/cgi- bin/mailto/x.cgi?pagetosend=/news/2011/070511-microsoft-patent-android.html)

<comment><USER13> It's a really nice trick. I keep that in mind. But beside that, is anything wrong as a person who often reads a lot of articles to ask for articles beein shown in a way that is more easily readable?</comment></comment></comment>


Elon Musk Is the Most Admired Leader in Technology - happy-go-lucky http://fortune.com/2016/12/03/elon-musk-admired-tech-leader/ <comment><AUTHOR> no shit, i'd install ovaries and have this man's children, then sue him for alimony because i know that's the closest thing i'll get to having him reciprocate my love.

people make mistakes and he sure made his share, but his tenacity, the way he founded Tesla despite being ridiculed by german Auto manufacturers is awe inspiring. his success is very well earned.</comment>


Simple tf-idf in 30 lines of Idiomatic Clojure - <AUTHOR> http://thecomputersarewinning.com/post/simple-tfidf-in-clojure

<comment><USER2> Apparently, everyone knows that tf-idf stands for "term frequency-inverse document frequency". I had no idea, and the article didn't have time to include a link to <http://en.wikipedia.org/wiki/Tf%E2%80%93idf> or even type out the acronym.

</comment><comment><USER3> Two remarks:

1\. Don't 'earmuff' your stopwords, since you don't intend them to be rebound. An according guideline can be found here: [http://dev.clojure.org/display/design/Library+Coding+Standar...](http://dev.clojure.org/display/design/Library+Coding+Standards)

2\. You could replace _(remove nil? (map db (tokenize raw-text)))_ with _(keep db (tokenize raw-text))_

<comment><AUTHOR> Thanks!</comment></comment>


Supervised Learning: Localizing Novice Type Errors with Data-Driven Diagnosis - <AUTHOR> https://arxiv.org/abs/1708.07583 <comment><AUTHOR> Yet another tool which uses machine learning to ease software engineering. A very appealing approach !

Yesterday, there was that post [[https://news.ycombinator.com/item?id=15125621](https://news.ycombinator.com/item?id=15125621)] about a tool which explores a target system to improve code with error and vulnerability checks.

Now, this tool, which uses a database of ill-typed programs with their fix, to improve the error messages returned by a compiler on typing errors.</comment>


Transcrypt Python-JS compiler now supports async/await - <AUTHOR> http://www.transcrypt.org?3 <comment><USER2> Went to check out the samples page to see what Python interacting with a Node module looks like after implementing this myself recently in another project. However the sample page throws a 404 with debug output.

<comment><AUTHOR> That's very bad! I'll repair it!

<comment><AUTHOR> It has been fixed. Sorry, it's the demo devil, I guess...

<comment><AUTHOR> By the way, the Node demo isn't online, but available on github (and in the pip-installation):

[https://github.com/QQuick/Transcrypt/blob/master/transcrypt/...](https://github.com/QQuick/Transcrypt/blob/master/transcrypt/demos/nodejs_demo/nodejs_demo.py)</comment></comment></comment></comment>


The Sources of Intergenerational Mobility in Denmark and the US - <AUTHOR> http://www.nber.org/papers/w22465.pdf <comment><USER2> Ugh. I saw one of the researchers was from University of Chicago (economic "Mordor"), and really struggled not to expect some kind of [Mussolini/Franco/Pinochet-style] "fascism is good" spin on the whole thing.

Slavery is freedom, or some such thing. "Only when 50% of the population is in danger of homelessness will there be incentive to get advanced education". OK, it doesn't say that, but part of the conclusions seem to lean that way: security is bad for educational level, which is an end unto itself???

</comment><comment><USER3> The key take aways appear to be:

> Scandinavia invests heavily in child development and boosts the test scores > of the disadvantaged. It then undoes these beneficial effects by providing > weak labor market incentives.

> The U.S. excels in incentivizing educational attainment. The Danish welfare > state promotes cognitive skills for the disadvantaged children.

<comment><USER4> Or, from the abstract:

" While Danish social policies for children produce more favorable cognitive test scores for disadvantaged children, these do not translate into more favorable educational outcomes, partly because of disincentives to acquire education arising from the redistributional policies that increase income mobility"

As the equality of outcomes is achieved by transfers, it makes the equality of opportunities meaningless (money-wise), and therefore makes education hereditary.

<comment><USER5> > As the equality of outcomes is achieved by transfers, it makes the equality > of opportunities meaningless (money-wise)

It's actually worse than that; Danish equality of opportunity isn't just "meaningless", it doesn't exist (relative to the US). There was a recent study done that indicated that income mobility (after taxes and transfers) in Denmark isn't any higher than in the US. This means that the taxes and transfers aren't actually having much of (any?) effect on equality of opportunity, as measured by the outcomes of the next generation.

<comment><USER6> The elephant in the room on many such topics is that state policies are a part of the picture, but often a limited part.

It's not just material advantages that child members of a class or subculture receive relative to peers. It's soft education, example and such. A child of a doctors and lawyers extended family is more likely to conform to this pattern than a child of a subculture where this is foreign.

Educational parity and even parental income parity can narrow the gap, but it can't close it. Who your parents are matters, apples fall close to trees.. Pick your cliché

<comment><USER7> Denmark was rich (by international comparison) and equality was a well established value long before the welfare state. A song written by one of the most popular poets of the time, Grundtvig, in 1820, contained the line "Og da har i rigdom vi drevet det vidt, når få har for meget og færre for lidt." ("We have achieved much in wealth, when few has too much and still fewer too little". My translation does not do the poetic qualities of the original justice, but it's pretty accurate for content.)

</comment></comment></comment></comment></comment><comment><USER8> Note: Working Paper = not peer-reviewed

The premise seems flawed on its face. If people are able to make a living wage and are happy with what they do, why do they need to worry about an advanced education?

Having a better educated populace regardless of how they choose to proceed from it seems like a positive outcome on its own.

Similarly, if a Danish person can have a good quality of life without having to engage in an American-style employment grind, why would they choose to follow that path?

The scope of this paper seems entirely too narrow.

</comment><comment><USER2> On the plus side, somebody has to work at the coffee shop, and they can earn a living doing so. Plus, said person doesn't feel like he/she should fill a chair in University for 4 years (at _somebody 's_ cost) doing something he/she doesn't _really_ care about.

Winning.

<comment><USER2> PS - I suppose, "winning" based on _my_ value system.

YMMV - your value system could be more in line with Mel Brooks' History of the World Roman Senate: "F--k the poor!" (vs more like that 1st century jewish guy...)</comment></comment>


Alleged Massive Technical Trading Fraud At Goldman - <AUTHOR> http://market-ticker.denninger.net/archives/1192-FLASH-Goldman-Code-Theft-BOMBSHELL.html

<comment><AUTHOR> Gotta say right now, Karl Denninger, Certified Crazy Person. I don't buy this story.

But hey this is definitely Hacker News. What do you think?

<comment><USER2> I think the author has the subtlety and clarity of the Timecube guy, but I can't wait to see a Matasano writeup of NYSE protocols and security.

<comment><AUTHOR> And you'll get it, coming to you LIVE, on SUNDAY SUNDAY SUNDAY (plus 3 days), LIVE AT VEGAS, with a SPECIAL GUEST APPEARANCE by _TRUCKASAURUS_ , and LIVE MUSIC by Kip Z'Nuff of Enuff Z'Nuff and WARRANT tribute band _CHERRY PIE_.

[http://www.blackhat.com/html/bh-usa-09/bh- usa-09-speakers.ht...](http://www.blackhat.com/html/bh-usa-09/bh- usa-09-speakers.html#Ptacek)</comment></comment></comment>


5 Distractions To The Nesting Entrepreneur - <AUTHOR> http://www.thebeefjerkyblog.com/5-distractions-to-the-nesting-entrepreneur/

<comment><USER2> For me, a guaranteed paycheck is definitely a distraction. We've been formed our whole lives to believe that going to school and getting a job was the path to go. Slowly, I'm beginning to realize how to break free from that. If I go for a period of time without a steady income, so what?</comment>