What is wrong with NULL - <AUTHOR> https://www.lucidchart.com/techblog/2015/08/31/the-worst-mistake-of-computer-science/ <comment><USER2> It's worth noting that having a NULL, somewhere, is not so much a problem as forcing types to have a NULL. In this respect, e.g. Python and Rust both get it right: while Python has a None, and Rust has std::ptr::null(), an object that is a string cannot be any of those, because those are different types (NoneType and raw pointer, respectively). C's problem is that a string could be null, and there's no syntax for a non-null string.

Python's problem, meanwhile, is that any parameter could be _any_ type. In C, you can pass NULL to a function expecting a non-null string. In Python, you can also pass 42, [], or the sqlalchemy module. None isn't special here. :)

Also, to quibble a bit: Rust's std::ptr::null() is just a raw pointer, and isn't actually _usable_ in safe Rust. Actual safe pointer types are guaranteed non-null and you'd use Option<&T> to specify that they're nullable. Raw pointers cannot be dereferenced in safe Rust. It is true that std::ptr::null() is in Rust's standard library, but Foreign.Ptr.nullPtr is in Haskell's, and the purpose is the same (a special raw-pointer type only used for FFI purposes), so Rust isn't any worse than Haskell here.

<comment><USER3> I also think that Go did pretty well to fix NULL. It didn't get rid of it completely, but it (nil) is only valid for pointers and interfaces, so it's not possible to use it in place of a string, integer, etc. It's not as bulletproof as Rust or Haskell, but something as simple as disallowing nil strings can make a world of difference.

<comment><USER4> This is what C does, so I don't think Go deserves much credit for innovation on this point...

</comment></comment></comment><comment><USER5> _Uglier than a Windows backslash, odder than ===, more common than PHP, more unfortunate than CORS, more disappointing than Java generics, more inconsistent than XMLHttpRequest, more confusing than a C preprocessor, flakier than MongoDB, and more regrettable than UTF-16, the worst mistake in computer science was introduced in 1965._

That could be the greatest intro sentence ever seen on Hacker News.

<comment><USER6> Pretty good, but I've never had a problem with an _XMLHttpRequest_ being inconsistent. Everything else seems spot-on though.

<comment><USER7> I think they're joking about the capitalization of the name.

<comment><USER8> Yeah. That's what I was going for ;)

<comment><USER6> I get it now! Duh.

</comment></comment></comment></comment></comment><comment><USER9> One of the problem's Maybe still has is in the deeper question of "why are you expecting None to be here?". Don't get me wrong, there are valid cases for this, and Maybe is certainly preferable to null across the board, but I think the movement to Maybe in the greater programming space will in many cases practically result in trading one set of explicit errors (crashes) for (a more subtle?) set of errors (behavioral). In particular, this style of programming will become frequent (from Swift documentation):

       if let roomCount = john.residence?.numberOfRooms {
          println("John's residence has \(roomCount) room(s).")
       } else {
          println("Unable to retrieve the number of rooms.")
       }

Or from this blog post's own example:

       option.ifPresent(x -> System.out.println(x));

In other words, I think the core problem still hasn't been attacked and we may end up in the same situation we were in with exceptions originally: programmers will just throw up their hands and wrap everything in a Maybe/Optional and/or just maybe-protect until the compiler stops bugging them. At the end of the day, if you ? all your values then you end up with something equivalent to having everything be nullable and correctly null- checking them.

Obj-C had a form of this with nil calling of methods silently doing nothing (so you end up with methods that "conveniently" don't happen, and don't crash! when the receiver is nil). However, despite having lots of legitimate uses (don't bother checking your delegate exists), it can still very silently sneak in to other parts of the code.

<comment><USER10> This is a concern, but the advantage to Maybe is it makes this concern very explicit. SML/NJ code will not compile if you don't have a binding to handle the None for an option 'a type. The programmer does of course then have the option of doing

None => raise Error

but practically speaking, when deciding it's time to make your code more robust, it's a lot easier to text search for instances of "None => raise" than to search for the absence of proper handling of the possibility of a null arg or return value.

<comment><USER8> Exactly. You can still get errors due to things not being there. But your assumptions are _explicitly_ stated.

You see None => raise Error, and a little alarm goes off in your head, and you look around for a reassurance that we _really_ want to do that.

In contrast, you don't give x.toUpperCase() a second glance.

</comment></comment></comment><comment><USER11> The mistake is an unsafe null: making every object type carry a value in its domain which says "Oops, though my type says I'm a Foobar, I'm not actually an object, la la la! Have a free exception on me, in your face!"

Lisp's NIL is brilliant. It's in its own type, the null type! And it's the only instance of that type. No other type has a null instance.

Null references in the language simply reflect the tension between the static type system which is supposed to assure us that if static checks pass, then values are not misused, and the need to have sometimes (at the very least) a "Maybe" type: maybe we have an object, or maybe not. Null references are the "poor hacker's Maybe": let's make every type support a null value, so that Maybe shows up everywhere.

Maybe, or something like the Lisp NIL, are themselves not mistakes by any stretch of the imagination. Sometimes you really need the code to express the idea that an object isn't there: directly, not with hacks like some representative instance, and some booelan flag which says "that's just a decoy indicating the object isn't there". You _want_ the exception if the decoy is used as if it were an object; that's a bug. Something is trying to operate on an object in a situation when there is no object; safely operating on a decoy just sweeps this under the rug. (Yet, not always: sometimes operating on the decoy is fine. Lisp's NIL lets us specialize a method parameter to the NULL class and deal with it that way in one place.)

<comment><USER12> ruby nil is similar in that it's an instance of the Nil class. though, calling a method on nil that isn't there is a common error.

I like how swift handles things. strong type system that makes it a little painful to do things unsafely. guarantees some things that make it a powerful and more safe language than objective c. I think they lost a few dynamic patterns though in the transition but that's just what i recall from a blog post and the details of it are a little fuzzy.

<comment><USER13> I agree, Swift's optionals are really great. But I also like Objective-C's nil: you can send messages to it and it won't do anything. That too solves a ton of problems with NULL.

<comment><USER11> What solves problem with null is if you can send messages to it, _and have it do exactly what you want_ depending on the nature of message.

</comment></comment></comment></comment><comment><USER14> We don't need to get rid of null, we need _more, type-specific and context- carrying_ nulls: types need a way to signal various error states via an enumeration of instance constants that carry the error state in a type- compatible manner without some syntactically crappy mechanism like Maybe.

      class Connection {

         //Error instances
         BAD_ADDR("The given address was not correct...")
         ...

      }

These constants should throw, just like a null value would, but with the specific error-state message, and should be testable for both the general and specific cases.

Try/catch has its place, but the persistence of null-as-error-state behavior among programmers shows that signalling-via-return-value is a practical and intuitive way to handle error states. We should make that better, rather than simply tipping our nose at null.

<comment><USER2> If you have a language with enum types (Haskell, ML, etc., or any of the languages inspired by them like Rust, Scala, etc.), that's straightforward. In e.g. Rust, you'd have

        enum Connection {
            ValidConnection {fd: RawFd, address: SockAddr, ...},
            BadAddr,
            BadPort,
            ...
        }

In fact Rust's representation of the maybe type is just a generic

        enum Option<T> {
            Some(T),
            None,
        }

so all you're doing is getting rid of the two layer Option<Connection> syntax and making it a single Connection, so you're not writing Option<this>, PossiblyBadAddress<that>, etc. everywhere.

Then all your call sites can do one of two things. Either they can check for specific errors, like

        match conn {
            Connection {fd, address, ..} => write(fd, ...),
            BadAddr => /* handle error */,
            BadPort => /* handle error */,
        }

or you can write a simple function that throws an exception, if you really want an exception-handling style:

        impl Connection {
            fn get_fd(&self) -> RawFd {
                match *self {
                    ValidConnection {fd, ..} => fd,
                    BadAddr => panic!("The given address was not correct"),
                    BadPort => panic!("The given port was not correct"),
                }
            }
        }

and then call conn.get_fd(). For a simple command-line app, panicking and aborting is pretty much what you'd want to do anyway. For a test suite, panics are caught per test case (and you can even test that a function _does_ panic with a given message), so it's very testable.

<comment><USER14> You shouldn't have to specify the error states in each method, this is why what I'm advocating is different than a simple enum:

\- You don't need to define a constructor to take the error string

\- You don't need to implement method dispatch (all methods of an error state instance automatically throw, like null does)

Enums are close, but not quite right.

<comment><USER2> Hm, I think what you might want is an enum / sum type, but with the ability to state that a particular variable is statically a particular variant of that enum. So, for instance, I can write fn serve(conn: &Connection::ValidConnection), and it's a type error to pass a generic unchecked Connection to it. Then serve() can go and call other functions that take a ValidConnection without doing any further error handling.

You might, for convenience, have a single method that turns a Connection to a ValidConnection, or else throws, and you can encode your error messages in one place in this method.

I _think_ this proposal permits such a thing, although I haven't read it closely yet: [http://smallcultfollowing.com/babysteps/blog/2015/08/20/virt...](http://smallcultfollowing.com/babysteps/blog/2015/08/20/virtual- structs-part-3-bringing-enums-and-structs-together/)

</comment></comment></comment></comment><comment><USER15> I agree with the article, yet, despite what the table at the end suggest I got significantly less problems with NullPointerExceptions since I switched from Java to C++ for my work.

C++ has an inbuilt alternative: references. References in conjunction with the Null Object Pattern have solved my problems until now.

References simply cannot be null -- and I generally do not use raw pointers in my code unless some library forces me to.

<comment><USER16> A null pointer can be dereferenced into a "null reference" which can be passed around, however. Theoretically UB, in practice, typically represented identically to the null pointer and behaves the same when used. Still helps in that the null bug root cause can hide in less places (modulo memory overwriting which adds root causes unimaginable in Java)

</comment></comment><comment><USER8> The title originally matched the blog post ("The worst mistake of computer science"), but then it was changed by a moderator.

Maybe it could have been a less drastic change?

"NULL, the worst mistake of computer science"

or

"The worst mistake of computer science: NULL"

</comment><comment><USER17> Here is what is wrong with Option.

option.ifPresent(x -> System.out.println(x));

So instead of just checking to see if it is NULL you want me to create an instance of a specialized class that holds my variable that has a method that acts like an "if" statement that I need to pass an anonymous function to that receives the value I already have?

Why not just do:

x && System.out.println(x)

or:

System.out.println(x) if x

Or if you want to skip over the rest of the logic if it is null:

return unless x

System.out.println(x)

I don't see why I need to introduce a new type system and complicate things.

For default values you want me to create an instance of specialized class that holds my variable and has a method that allows me to get my value or return a default value?

option.orElseGet(5)

So instead of a memory lookup I now need the overhead of an entire function call?

Why not just do:

x ||= 5

Or better yet, just put it in your function declaration as a default value:

myFunc = (x=5, y, z) -> ...

The one benefit I see is type safety but it is extremely rare for experienced programmers working in dynamic languages to have bugs related to type.

You are layering on abstractions and forcing programmers to go through hoops just to get at their data. It is more complicated and increasing the cognitive load.

There's also the fact that you are going through functions and classes instead of just memory accesses. This makes code less performant as well.

<comment><USER18> > The one benefit I see is type safety but it is certainly not easier

Type safety is one benefit, but composability is an important benefit (as, you know, is extensively discussed in the source article.)

<comment><USER17> Composability comes from functions, macros, and inheritance. What does that have to do with types?

"In fact, composibility is really the fundamental issue behind many of these problems. For example, the Store API returning nil for non-existant values was not composable with storing nil for non-existant phone numbers."

That's only because you invented some abstraction that got in your way in the first place. NULL is a perfectly acceptable value in dynamic languages and even in most document store databases.

<comment><USER8> This is not contrived.

(1) A cache returns something or NULL. It's generic; i.e. implementation doesn't care what it is storing: integers, strings, etc.

(2) A particular value of interest may be NULL or non-NULL.

But now I can no longer use my generic cache and my values of interest together.

A very real example of this is Java's Map interface. It's completely up to implementation on how they handle null, making interpreting null results difficult.

While often you use NULL and everything works, you're still limited to a certain set of circumstances. You can't pick up thing A and thing B and just use them together. Hence non-composable.

<comment><USER17> You're conflating the meaning of NULL in that case. That's not a problem of NULL, you're using NULL to represent multiple different things. You can use exceptions to handle that scenario.

      cache = {}
      getFromCache = (key) ->
        return cache[key] if cache[key]?
        throw "not found"

      doSomethingWithValue = (key) ->
        try
          value = getFromCache(key)
        catch
          value = getValueFromNonCache(key)
        return _doSomethingWith(value)

<comment><USER18> You can, but resorting to exceptions for what may not be an exceptional circumstance is a workaround for not being able to think of a way to communicate results correctly through the return value. Which illustrates the need here as effectively as the ambiguous use of null in the article.

<comment><USER17> You don't like exceptions so your solution is creating an instance of a specialized class that holds my variable that has a method that acts like an "if" statement that I need to pass an anonymous function to that receives the value I already have?

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> C++ introduced non-null references. But they didn't enforce them. There are still "I'm so l33t I can use null references" people. The new move semantics use null references for things moved from. C++ is trying to do Rust-like borrow checking without a borrow checker. Errors result in de-referencing null and crashing.

Rust doesn't have null, but it has Option<T>, which is often syntactic sugar for null.

It's not that null is bad in itself. It's that having variables which might be null need to be distinguished from ones which can't be null.

<comment><USER20> _The new move semantics use null references for things moved from._

No. When you move the contents out of somewhere like an std::vector instance, that object is left in an undefined but valid state. You're free to continue working with that object (though the only meaningful thing you can usually do without undefined behaviour is destruction or the equivalent of _clear_ ). That's very different from null references.

<comment><USER19> Right; you can't have an array of references, and it's "unique_ptr", not "unique_ref". But pointers do get set to null.

If p1 is a unique_ptr, and you do

        p2 = std::move(p1);

p1's pointer is set to null. Further uses of p1 will fail, or crash, or something.

        p1.get()

returns the underlying pointer or null, apparently escaping the unique_ptr protection.

It's far inferior to Rust's borrow checker.

</comment></comment></comment><comment><USER21> This mistake is fixed in Haskell.

<comment><USER22> Rust, too!

Edit: Btw, I disagree with how the article categorizes Rust in comparison to Haskell. It shows that Rust has std::ptr::null, but neglects the fact that Haskell has Foreign.Ptr.nullPtr. Either both should be "5 stars" or both should be "4 stars".

<comment><USER8> Author here. I didn't know that about Haskell.

Admittedly, the "rating" is pretty rough, maybe even a bad idea.

I've seen std::ptr::null more than I ever have Foreign.Ptr.nullPtr.

But really, both are usually used for compatibility with external libraries/programs/runtimes, not for idiomatic language programming.

Both great languages in my book :)

<comment><USER23> > I've seen std::ptr::null more than I ever have Foreign.Ptr.nullPtr.

Probably because we need to work with the C API a great deal right now, but that should change as more and more things are written in Rust. Still, the unsafe boundary helps by removing the ability to dereference a raw pointer in safe code - something that Haskell doesn't have.

</comment></comment></comment></comment><comment><USER24> >NULL is a terrible design flaw, one that continues to cause constant, immeasurable pain

Exaggeration much? Certainly not "the worst mistake of computer science". IPv4 is much worse, just for one example. NULL isn't even visible to end-users, many mistakes in CS are quite visible and really impact non-programmers' lives. NULL is just the color of the wallpaper in the engine room.

<comment><USER25> It is vastly more destructive than IP v4. This affects end users directly, every single day. The number of times applications have crashed due to NULL related errors is probably in the tens or maybe hundreds of billions. Each time is an interruption of people's work and in some cases it destroys hours of work.

</comment></comment><comment><USER26> No mention of SQL, where NULL's behavior in the standard can lead to some quirky behavior that I've seen bite back in poorly designed systems. I've included a brief illustrative example. The expectation is that the UNION of two WHERE clauses, one using IN and the other using NOT IN should be equivalent to the same SELECT without any WHERE:

        WITH NullCTE AS
            (SELECT a.*
            FROM
                (VALUES (NULL), (1), (2)) a (Number)
            )
        ,One AS
            (SELECT Number = 1)

        SELECT *
        FROM NullCTE nc
        WHERE nc.Number NOT IN
            (SELECT Number
            FROM One)
        UNION
        SELECT *
        FROM NullCTE nc
        WHERE nc.Number IN
            (SELECT Number
            FROM One)

Running this will give you back a two-row table, containing 1 and 2, but the NULL is excluded from both WHERE conditions.

The naive expectation is that the combination of a condition and the NOT of that condition cover all possible circumstances.

<comment><USER8> I thought of including SQL NULL. Unfortunately, I felt I would do such a poor job of enumerating the problems or describing them in a somewhat comprehensive way, I didn't even try.

</comment></comment><comment><USER27> I was with the article until the part about null terminators on strings. Null terminators are nothing like a NULL reference. We could just as easily have dollar-sign-terminated strings and no one would be conflating that idea with the concept of NULL.

Also, NULL pointers are the least problematic type of pointer if you ask me. If a pointer is NULL it is not likely a security problem, and certainly not on its own. Accidentally using a NULL pointer will cause a crash, but accidentally using _any other_ pointer could cause unlimited damage.

<comment><USER8> To quote the article:

> This is a bit different than the other examples, as there are no pointers or > references. But the idea of a value that is not a value is still present, in > the form of a char that is not a char.

It has nothing to do with the similarity in name (NULL / NUL). As you said, it could be terminated with $. The similarity is that they are both sentinel values. NULL is a sentinel for types; NUL is a sentinel for char arrays.

In both cases, they create exceptional and non-composable situations.

Good explanation here: [https://www.reddit.com/r/programming/comments/3j4pyd/the_wor...](https://www.reddit.com/r/programming/comments/3j4pyd/the_worst_mistake_of_computer_science/cumbius)

<comment><USER27> I know the author _claims_ that there's a meaningful similarity beyond the names. But that's where I disagree.

I get that a NULL pointer is in some meaningful way not a pointer. Because it literally isn't pointing to anything. It is not the case that NUL is a char that is not a char. NUL is a perfectly good char. _Some_ functions treat it specially, but other than that it's just a regular char.

Even the sentinels similarity is quite weak. NULL is a sentinel that indicates "no valid object" whereas NUL is a sentinel that indicates the end of a perfectly valid object. Notice how we're not having this discussion about '\n' or the whitespace chars in general, even though they're also treated as sentinels by some functions.

</comment></comment></comment><comment><USER28> Many modern languages (Kotlin, Rust, Swift) handle this problem well.

Though I'm not sure if that problem is really that huge. Bad code will break in many ways. And breaking on nulls usually isn't that dangerous, data isn't corrupted and stack is safe.

There's another mistake of computer science in my opinion is inefficient array bounds checking and implicit integer overflow behavior. And those mistakes are more dangerous, they lead to data corruption and exploits.

</comment><comment><USER29> Well the article doesn't talk about performance, but at least for the double- maybe in the store example, there is one level of extra indirection in the machine code: return pointer to maybe, then return pointer from string from it.

If you care about performance, you really need two predicate values to cover this case. You could have (void * )0 for no entry, and (void * )1 for entry exists, but is blank.

</comment><comment><USER30> I've never had a problem with NULL as a "value". Null is the absence of content, a container that is truly empty, and that is frequently useful. As an example it allows you to differentiate between a numerical field that was never populated vs. one specifically set to Zero. This is often an important distinction.

</comment><comment><USER31> > If x is known to be a String, the type check succeeds; if x is known to be a > Socket, the type check fails.

So the author is trying to explain what the null pointer exception is, but uses the concept of sockets in his example. I wonder, how many people know what a socket is but don't know what null pointer exception is?

</comment><comment><USER32> NULL is okay as long as you pretend it doesn't exist. I mean, in these languages, uninitialized variables exist at some point (fields start uninitialized in constructor bodies, etc), and that's why there's null, instead of defining them with some garbage value that has undefined behavior. But the right solution for users is to just _pretend_ that it can't exist, and that uninitialized variables have a garbage value.

Of course, that's idealistic, most languages don't have some Option<T> type without a performance penalty, and pre-existing libraries exist. (Usually you should design around needing Option<T> too.)

The right language design decision for these languages (managed languages like Java) might have been to make uninitialized references have a garbage value that reliably throws an exception when used (i.e. null) -- you can copy the reference and pass it around, but you _can 't_ compare it for equality and any attempt to inspect its value results in an exception.

<comment><USER33> > _The right language design decision for these languages (managed languages > like Java) might have been to make uninitialized references have a garbage > value that reliably throws an exception when used (i.e. null) -- you can > copy the reference and pass it around, but you can 't compare it for > equality and any attempt to inspect its value results in an exception._

That's just a different kind of null. You still have the original problem: this thing is declared as a T, but sometimes it's not a T, so you have to inspect how the value is used before you can conclude whether it's a T or not.

The correct solution is to structure the language so access can't occur before initialization. For example, you could place severe constraints on constructors so they must initialize all the fields and do nothing else until that's done. Think initializer lists from C++ (but stricter), or tagged unions from Haskell.

<comment><USER32> That is not an option. Things like arrays need to be allocated with a default initialization and then filled.

<comment><USER33> You can absolutely work around that:

\- Require an explicit initial value to be provided.

\- Or require that a collection/iterator/generator of values be provided (and fail if it's not large enough).

\- Or have a built-in ArrayBuilder<T> type that accumulates all the needed values before allowing you to retrieve the array.

\- Or make your language dependently typed, and change the signature of Array.get to take both an index and a proof that said index has been initialized.

<comment><USER32> \- Require an explicit initial value to be provided.

Let's say you want an array of FileHandles. Under this proposal, you'd need to create an "empty" FileHandle value that you can use to fill arrays with and such. You'd have to create some "empty" state for every type. This is worse software engineering than having the possibility of a null pointer exception. (Also, you couldn't write generic code to implement an ArrayList<T> efficiently without some way to generically default-construct the T to fill most of the array entries, or the constructor would have to take a filler value.)

\- Or require that a collection/iterator/generator of values be provided (and fail if it's not large enough).

This is a needlessly complicated way to use an array, and it still has the same downsides.

\- Or have a built-in ArrayBuilder<T> type that accumulates all the needed values before allowing you to retrieve the array.

And how do you implement your own ArrayBuilder? What if you need something with a slower growth rate, or some other data structure that you could build out of an array with uninitialized elements, such as a deque?

\- Or make your language dependently typed, and change the signature of Array.get to take both an index and a proof that said index has been initialized.

A far worse alternative.

Late edit: Generally speaking I think you're completely missing the problem of null pointers. The problem is not that a class of error exists. It's that people try to use null values in surprising ways in their APIs. If you make the null value impractical as a sentinel, you remove the mismatch between what programmers expect about whether a value can be null.

</comment></comment></comment></comment></comment><comment><USER34> Another reason that, even despite sharing a lot of syntax with PHP, Hack is one of my favorite languages:

[http://docs.hhvm.com/manual/en/hack.nullable.php](http://docs.hhvm.com/manual/en/hack.nullable.php)

</comment><comment><USER35> As a mathematician I still think making "-1 % 7 == 6 % 7" evaluate to false is worse.

<comment><USER8> So you like Python.

</comment></comment><comment><USER36> For statically typed languages this is definitely an issue, but for dynamic languages less so. In Python, I wouldn't use an optional value,

      x is None

seems to be just fine. I'm still waiting for

      std::optional

for C++.

<comment><USER37> It's only not an issue in dynamic languages in the sense that you have the same issue anyway without null because you have no type safety at all.

<comment><USER11> You have a ton of type safety in Python, which is one reason why Python programmers are cranking out large bodies of working code representing all kinds of applications that Just Work.

"No type safety at all" means you can misuse a value of one type using an operation that is appropriate for a different type, and some nonsensical behavior silently occurs (or perhaps some nonportable behavior that you sneakily intended). This characterizes assembly languages, certain machine- oriented languages like BCPL, and some immature dynamically typed languages which omit run-time-type checks (the type information is there, but not checked, so that string_length happily tries to operate on an integer, so that a type problem occurs in the interpreter's kernel itself.)

<comment><USER37> Python has some safety checks that are missing in other languages, and this is a good thing. But it's misleading to call them "type safety", because they aren't connected to anything that can be meaningfully called a type system - all those checks happen at the value level (e.g. you can make a particular integer amenable to string_length, by monkeypatching the relevant methods onto it).

</comment></comment></comment></comment><comment><USER38> lol the null / undefined issue in javascript is further exacerbated by the fact there is no int type and everything is just a "number".... yet the number 0 is still treated the same as null/undefined by js special forms like "if" and "==". This is particularly hilarious because it leads to some null-check bugs like:

if ( user.getScrollPosition() ) { whatever(); } else { die(); }

99% of the time, the code would be fine, but if the user scrolls just right, the whole thing would die. Stuff like this is literally death to debug because this bug is effectively indeterministic and can't be reproduced.

<comment><USER17> Why would you check the value instead of the presence of the value? Rookie mistake.

user.getScrollPostion() != undefined

or in CoffeeScript just use:

user.getScrollPosition()?

Arrays have various types of ints and floats of various word lengths and signs.

[https://developer.mozilla.org/en- US/docs/Web/JavaScript/Type...](https://developer.mozilla.org/en- US/docs/Web/JavaScript/Typed_arrays)

</comment></comment><comment><USER39> > 4\. NULL makes poor APIs

Then don't use it. The example given is a bad design. No phone number and not in cache should not return the same value. That bad design has nothing to do with nil, Return '' for no phonenumber.

<comment><USER40> When I look at my coworker's code, or an open source project's code, there is going to be usage of NULL. Your strategy is not pragmatic. The problem with language features is that people use them.

</comment></comment><comment><USER41> Reading this article is like listening to a republican arguing against taxes.

</comment><comment><USER42> I'm still not entirely convinced that NULL is a problem. But how NULL (and pointer types in general) work in C leads to much, much greater problems.

Though, I think uninitialized variables or memory might be just as bad.

</comment><comment><USER43> NUL-terminated strings aren't _that_ bad:

* unlike Pascal-style strings, they can be usefully sliced, especially if you can modify them strtok-style.

* unlike (ptr,len) "Modern C buffers"/Rust-style strings, references to them are pointer-sized, and they can be used as a serialization format.

This makes the kind of application that is based on cutting pieces of a string and passing them around a good measure faster, especially compared to say C++'s "atomically reference-counted, re-allocating at the slightest touch" std::string.

This style of programming is not particularly popular nowadays, so buffer- strings are better-fitting. Its main problem is its multitude of edge-cases, which tend to demonstrate C's "every bug is exploitable" problem well.

<comment><USER33> > unlike Pascal-style strings, they can be usefully sliced, especially if you > can modify them strtok-style.

Slicing Pascal-style strings is also easy and constant-time: just track the buffer, offset, and length of the slice of characters you want. Java used to do it implicitly whenever you called `substring`.

> _unlike (ptr,len) "Modern C buffers"/Rust-style strings, references to them > are pointer-sized, and they can be used as a serialization format._

Every C method that takes a character buffer either a) has a corresponding length parameter or b) is avoided because of the security risks. In practice this means that C also stores the length information, just on the side instead of combined into a struct with the buffer.

<comment><USER43> > Slicing Pascal-style strings is also easy and constant-time: just track the > buffer, offset, and length of the slice of characters you want. Java used to > do it implicitly whenever you called `substring`.

That's just coercing into a "modern C buffer" and slicing it. It has the disadvantage that coercion is not equality or subtyping - i.e. you will have to do lots of wrappings and unwrappings in mixed code.

> Every C method that takes a character buffer either a) has a corresponding > length parameter or b) is avoided because of the security risks. In practice > this means that C also stores the length information, just on the side > instead of combined into a struct with the buffer.

You are surely talking about the buffer's capacity, not the string's length. These are distinct concepts. Anyway, functions that only _read_ strings, and structs that only store them read-only, aren't interested in the capacity of any buffer.

Anyway, C strings aren't responsible for the fixed-size buffers of Cold War- era code - _that_ code uses fixed-size buffers for _everything_. Their main claim to fame is their popularity in parsing code, which is edge-case- and bug-prone.

</comment></comment></comment><comment><USER44> I'm not a c++ expert, but doesn't

      char *myChar = 0;
      std::cout << *myChar << std::endl; // runtime error

compile because it's undefined behavior?

<comment><USER45> the point is that it's a straightforward-looking piece of code that has really strange behavior.

</comment></comment><comment><USER46> In case the author is reading this thread:

The entry for C++ in the final tables is:

        C++  | NULL  | boost::optional, from Boost.Optional

It does ignore that C++ has nullptr since C++11

</comment><comment><USER39> > if (str == null || str == "")

Why not have null (and emptystring) eval to false? And

        if not str:
           str = 'wordup'

</comment><comment><USER47> The best phrase from the article: "confusing sources of sloppy nullish behavior."</comment>


Announcing the Github Commit Status API - <AUTHOR> https://github.com/blog/1227-status-api

<comment><USER2> This is awesome, I really like how github has been exposing so many API's lately so we can use their tools in whatever way we see fit by simply tying several api's together.

Hooking this into our CI server and using the Merge API (for keeping PR's up to date) is the next 20-minute task I will take on.

</comment><comment><AUTHOR> Note that separately CI-ing each individual pull request still consumes what in past years would be an enormous investment in build automation. Luckily this is increasingly becoming a SaaS thing.

</comment><comment><USER3> More discussion over at <https://news.ycombinator.com/item?id=4475152></comment>


I feel like Sherlock, if he were a developer - <AUTHOR> https://medium.com/@86ea956994f3/4a303ebdaf63 <comment><USER2> Thank you for posting.

> If you know some basic C, take a look at this block of code, and see if you > can find a clue as to what went wrong:

> char *filename="models/";

> strcat(filename,"bullet");

> strcat(filename,".h3d");

That code being written in the first place does not inspire confidence. "strcat" has almost no valid use cases, and the suggested solution of using a fixed-size buffer is likely to lead to further instances of exactly the same variety of error at some time in the future.

> char filename[256];

The sane solution here is to use strncat or another, more appropriate, function such as snprintf. The length of the buffer should at least be a macro rather than a magic number.

</comment><comment><USER3> The six animated gifs on that page, placed so that as soon as one scrolls away from the introductory material there will always be one visible, make the page annoying to read.

Approximately _half_ of the vertical space in the body of the article is occupied by animated gifs!</comment>


Which Way Do You Run? - <AUTHOR> https://a16z.com/2019/10/17/how-to-be-effective-ceo-leader/ <comment><USER3> [Me reading the article]: Hrmm, I'm not sure I understand the point of this article. Seems like vague hand wavy advice and platitudes (I mean c'mon "run towards your fear"? Cheese-factor 1000).

[Me gets to the end of the article] Oh, Ben has a new book coming out so he needs to shill it. Makes sense.

<comment><USER4> Running toward your fear isn't hand wavy advice. It is in essence what modern therapy around fear, panic, and anxiety teaches. It's good advice because it works. Running away only makes the problem worse. Be that losing $30M or not being able to walk out of your house.

<comment><USER5> Fear might be the most important emotion from an evolutionary perspective. Pretending you can simply run towards your fears and things will get better is awful, awful advice. I am not saying you should let your fears consume you or that they can never be conquered, but maybe an alcoholic's fear of being in a bar is a healthy thing (there are plenty of other examples but that was the first I thought of after 5 seconds).

<comment><USER6> The point about running toward your fear isn't that things will get better, it's that you'll _know_ which of your fears were valid and which were illusory. Oftentimes the thing you're most afraid of is simply _not knowing_ what's going to happen next.

In the context that Ben is writing this post (founding a startup), basically the worst thing that can happen to you is that your company goes bankrupt and you have to look for a job. It _feels_ a lot scarier than that because your ego gets wrapped up in the startup and all sorts of negative events can be existential threats to the startup, but there are basically no physical threats to your person other than yourself. If a tiger comes running at you or someone points a gun at you, by all means, be afraid and run away, but if you're signing a $30M lease, be afraid and then face that fear and rationally analyze the risks.

<comment><USER7> The hard part of juggling startup risks feels more of the reverse of what Ben's remembering.

It's not that you need to spot a ball is about to drop and catch it. Founders are up at 2am and every e-staff & advice meeting thinking about them & then acting on them. However, running at all of them will give you a heart attack, burn out your team, and derail your mission.

Instead, you have to accept that a ton of balls are dropping, and somehow get good at guiding which & how. Now that's a chapter I'd like to read :)

</comment></comment></comment></comment></comment><comment><USER8> For context I have an anxiety disorder. This makes entrepreneurship even more difficult as these hard decisions are very hard to intellectualize even if you want to as it can cause panic attacks and in extreme cases disassociation events.

One helpful thing though is the same framework I use to manage my anxiety is a great decision making tool for business. Forcing yourself to actually ground yourself where you are right now and look at what's actually going on. Basically cutting through the meta narrative and seeing things as they are. Early on in dealing with my anxiety the name of the game was pain avoidance. Use whatever I could to go numb basically. After a while, some of us at least, realize what's happening and are able to take the steps to change that perspective. Going numb constantly is no way to live. A focus on the process and what's happening right now as opposed to the maybe outcomes is really key. You learn to basically coexist with the anxiety, and as weird as it sounds, find a place of peace inside of it. To me that's what this post is saying. See things as they are, and lean into the pain rather than go numb. Ironically when you do that you realize the imagined horror is usually worse than the reality and in terms of business you make the hard decisions to get things done.

This post resonated pretty deeply with me and I appreciate him sharing.

<comment><USER9> Your experience is interesting: entrepreneurs take a lot of responsibility with lots of uncertainty - feeding lots of raw material directly into the anxiety disorder. How and where did you learn your techniques for managing your anxiety? How long did it take before you were able to see positive changes? Any diet and/or daily routine changes?

Wouldn't it be less stressful to get a job?

<comment><USER8> >How and where did you learn your techniques for managing your anxiety?

Trial and error over a period of about 8 years. Lots of suggestions from folks. Some worked out, some didn't. Lots of incremental change, but mediation, exercise, stoic journaling, and therapy were the big 4 leaps I made. The therapy mostly focused on process orientation and self esteem/self worth for me personally.

>How long did it take before you were able to see positive changes?

Usually a few weeks with any of the 4 above. If I keep in my routine I usually can feel positive change within 1-2 weeks.

>Any diet and/or daily routine changes?

Limiting alcohol helps a lot. Generally avoiding processed foods and high sugar or starch foods helps. Supplements are a very mixed bag, but vitamin d, vitamin b, fish oil, magnesium, a mens daily vitamin help. Everything else either had no effect or negative effects for me. Also it seems silly but drinking enough water is a big deal.

>Wouldn't it be less stressful to get a job?

Almost certainly it would be easier. Though a different more existential anxiety sets in after a while whenever I stop working on my own thing so it's a bit of give and take.

<comment><USER9> Thanks for answering. I find it valuable to understand how others manage their emotional states. I find regular exercise, meditation and good sleep hygiene to be effective. I'm reading about stoic journaling now. I did not know about this.

</comment></comment></comment></comment><comment><USER10> I think the vague and abstract way Ben Horowitz has worded his essay makes the lesson he's trying to impart very confusing. Here's my interpretation of his advice into more concrete terms:

\- _" fear"_: "dot com boom will crash" ... but I can't articulate why I believe that in perfectly logical statements

\- option (1) is to run away or ignore the fear: delegate to somebody to go ahead and buy more office space for $30 million and make the fire marshall happy

\- option (2) to "run towards the fear" is to _cut spending immediately_ which may also include _laying people off_. E.g. create a new MS Excel spreadsheet, put all the staff's salaries on it and start making the hard decisions of who needs to be let go. In other words, your _business actions_ still need to match your fears -- even if your "fears" are poorly articulated gut feelings

As a bonus, the _painful exercise_ of doing Option 2 _may reveal the logic_ of why you believe the dot com boom is ending.

(Of course, an alternative to Option 2 is to _find new revenue_ but that's often 100x more difficult than cutting costs.)

In other words, it's way easier to have your office admin shop for a new office building than to _fire people_ \-- some of whom are your friends that took a risk and depend on you.

<comment><USER11> A better way to phrase it might be "trust your fear". Not sure that is always the best advice because sometimes fear is justified and sometimes not. In this case, it was.

<comment><USER12> It feels to me like he is just to taking the very old advice to "face your fears" and make it seem like he has something new to offer.

<comment><USER13> Yeah, but it goes a little deeper in the sense that sometimes you feel fear but don't understand it, and you can try to go deeper understandig and confronting the fear, or since you are not sure what is happening, let go the situation and try to hide, escape it, delegate it, distract yourself. The point is more about the sense of fear that you don't understand where it comes from, and you prefer not to dig deeper understanding the fear because you fear that you will find something ugly. And instead confront it.

</comment></comment></comment></comment><comment><USER14> There are a lot of people in the comments that seem confused by the point of this article. I think if you have ever run a business (managing a team is _not_ the same) then this article is clear as day.

Owners have infinite ways to allocate their time. Many owners feel problems in their gut but they are uncomfortable to deal with, and so instead they do other things (which are easy to rationalize as more important). E.g. firing someone, perhaps someone that was just hired two months ago who moved across the country to take the job but is not working out. Many people would come up with a hundred reasons to keep the person even if their gut is saying to fire them, because of how uncomfortable it would be to actually do it. This article is saying you need to run towards those moments of fear and discomfort and do the right thing, not run away from them and dig the hole deeper.

<comment><USER15> Yes I think everyone understands that's the point he's trying to make, it's just that he's doing it in such a vague and generalized way and trying to pass it off as actionable advice that it becomes almost comical.

There's nothing revelatory about telling someone to "face your fears" but a pseudo-philosopher VC is trying to pass this off like it's this sage piece of advice no one has heard before.

<comment><USER16> > it's just that he's doing it in such a vague and generalized way and trying > to pass it off as actionable advice that it becomes almost comical.

Totally.

1) Vague advice is much easier to sell and elevate ones position (look at Tony Robbins). There's no negatively correlative impact to the advice so its hard to argue if someone is wrong.

2) Providing concrete advice is impossible to "scale" (e.g. books, podcasts, video, etc) as it requires context.

<comment><USER17> > Providing concrete advice is impossible to "scale" (e.g. books, podcasts, > video, etc) as it requires context.

Wouldn't that make it easier to scale, since there's more context you can provide?

<comment><USER18> The context is specific to the recipient of the advice, making it effectively impossible to scale.

<comment><USER17> the scale is you're reaching a different audience and can provide different context for the same message on top of a different medium.

<comment><USER18> You're describing the type of impersonal advice that the parent poster said was generally unhelpful for the recipient.

Everything you said sounds great for the person selling advice, but not great for the consumer, which was the point of the original comment.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> Many people, including Ben Horowitz and Andy Grove, have also identified how many CEOs are often overly optimistic or even irrationally optimistic.

If that's the case (I personally think it often is), then it that much more important to run towards the fear in the relatively rare cases that you do see the possible indicators.

I have also found it useful to document key assumptions, and the reasons behind those assumptions, and then compare to actual as actual materializes. That comparison sometimes unearths problems (or opportunities) that may have otherwise been obscured by other items.

Any other methods that folks use to have more open eyes and ears to potential problems, or to assure you act upon them in the right manner without rationalizing them away?

<comment><USER20> The truth is startup CEOs have to be overly optimistic, otherwise there's no way they'd ever start a company. The dark side of this is then often don't believe something is "wrong" until it's too late.

</comment></comment><comment><USER21> I'm having trouble following the example. If running away from the fear is delegating an employee to find more office space due to the fire marshal's requirement, what is running toward the fear? Saying no to the fire marshal?

It's probably finding the office space themselves, and presumably for cheaper. But this is kind of left for the reader to conclude, so I'm not sure what the message is here.

<comment><USER22> He chose not to think about the decision by just rolling with it. Alternatives, off the top of my head:

* Fire people?

* Do a cost-benefit analysis - could they sustain a new space? Or would they have to move everyone to somewhere cheaper?

* Would shifting some people to work remotely work?

Delegating getting more office space was running away from fear because it was the option that required the least thinking about his fear.

<comment><USER23> Loudcloud was at the peak of the dot-com boom, late '90s to early '00s. Working remotely wasn't really an option then.

</comment></comment></comment><comment><USER24> I don't suspect that his "dark" feeling came from prescience about the impending dotcom crash. Locking a fledgeling business into a $30M lease should feel dark in any economy.

<comment><USER25> I can't work out this $30MM - was it a deposit? That seems...insane.

<comment><USER26> Five years, $6M a year, 60,000 sq feet (roughly 150-300 employees, depending on how it is organized). You lock a lease and you're on the hook.

</comment></comment></comment><comment><USER27> I just feel like the example Ben Horowitz gave here is likely colored by his experience. Were his gut feelings really foretelling the dot-com crash? How many times were similar anxieties wrong?

<comment><USER28> The point though is how you handle it, not necessarily that you were a good fortune teller or not.

What I'm not quite clear on is how he would've handled the situation differently by "running towards" the fear. Handle the building search personally? Letting the Fire Marshall shut him down? Act on his gut feeling that something was wrong and start slow slowing down? Those don't seem like that's what he meant. Maybe I would understand more if I knew more of his story.

<comment><USER27> I personally am a little too paranoid to act on most of my suspicions. So running towards all my fears would lead to me tackling mostly false positives. I think that's probably a growth area for me.

</comment></comment></comment><comment><USER29> If this is any indication, I think I'll pass on the book... vague reflections of a no-longer-hungry exec remembering what happened through the rosy lenses of survivorship bias isn't my cup of tea.

</comment><comment><USER30> I found this article somewhat high on the fluff and low on the substance.

To me the biggest takeaway might not be what the author intended... never ever sign leases which put unreasonably large amounts of cash at risk. To answer his question, I'd certainly run away from those!

</comment><comment><USER15> It's blog posts like these that totally break down the "mirage" of the philosopher VC for me. This completely lacks any substance or meaning or relevancy, and makes me question why we pay so much attention to glorified check writers.

<comment><USER31> I appreciate it because I've read his other book. If I had not, or maybe if I didn't enjoy it as much as I did, I wouldn't get much from this either. It's purely a promotional component for his upcoming book so it's more of a teaser than anything.

</comment></comment><comment><USER32> This is a thing I've noticed in all the very successful people I know. It's a sort of schlep-sight[0] that they have. Something is wrong, and instead of pushing it to the back of their mind, or letting this critical thing be ignored, they put it in the front and worry about it. And prod it. And attempt to deal with it.

I don't have this skill automatically so I'm trying to cultivate it. Ironically, I'm here on HN because I'm dodging a fear.

0: As an antonym of the famous schlep-blindness [http://www.paulgraham.com/schlep.html](http://www.paulgraham.com/schlep.html)

<comment><USER33> Interesting, reminds me of seeing Chris Stolte's presentation on Polaris which was all about schlepping SQL and which would eventually become Tableau

</comment></comment><comment><USER34> > "[O]nly the truly elite ones run towards the fear."

Every time I read the philosophizing of a venture capitalist, it sounds more and more like an indoctrination into how to run your company in the venture capitalist's favor.

If you're a venture capitalist with a portfolio of dozens of CEOs running toward their fear, odds are a few of them are going to crash through and win, and the rest you can just disregard as the cost of doing business.

If you're the CEO actually running toward the fear, it's more of an all-or- nothing thing.

<comment><USER6> Running towards your fear is generally a good strategy even if you're not a CEO running a company. It's particularly relevant for young adults just starting their careers out of college: there's a very strong tendency to not want to make hard choices about what you want your life to look like, which avenues will you close off, and what you put your effort into despite not knowing whether it'll ever pay off, but people who avoid those choices get to 40 and then find that not only has their life not amounted to much so far, but everybody they meet expects that their life will never amount to much and writes them off.

The reason it's a good idea is because it forces you to really confront your feelings, examine the present moment, and identify which are rational and which are assumptions that you were just raised with. If you run away from your fear you'll always be boxed into the path that you were on in high school; if you run towards it you have the option to really decide what you want your life to look like.

</comment></comment><comment><USER35> This should not lead to the will to never "run" ("never forfeit"), as it is as counter-productive as the will to "take any challenge".

If a challenge induces a major risk with a subpar reward, just don't take it, or drop it.

Churchill's "We shall fight on the beaches" is sound when the stakes are at their max, when there is no other way around.

Moreover there are challenges imposed to you, and challenges you chose (among those last there are rewarding ones and also (whatever the reward) too dangerous ones).

Expertise is the best tool when it comes to select a challenge rewarding and adequate for you, to avoid/drop other challenges and to avoid having anything imposed to you.

As Frank Borman said "A superior pilot uses his superior judgment to avoid situations which require the use of his superior skill."

However in order to gain expertise you have to tackle challenges. Generally life and our family and friends let us start with non-dangerous ones, therefore the best way to gain pertinent expertise is, especially as a youngster, a "realistic" and guided will to explore.

</comment><comment><USER36> There's something valuable in this post although I do agree with everyone's comments that the messaging is poorly communicated or even biased.

For me, I think the actual takeaway here is: _Find what scares you, and figure out why you fear it_

Then, rather than making a blind decision to "run towards or away" from it, you can actually try to make a more calculated decision.

</comment><comment><USER37> I feel like there are more alternatives to a 30M lease. Maybe a a second, smaller site? Maybe allowing everyone/some-group/rotate-people to work from home?

There should be an executive other than the CEO who can solve the problem with the given constraint ("don't spend too much")

</comment><comment><USER38> I naively thought this would be an article discussing overpronation and supination.

<comment><USER39> I was ready to weigh in with a defence of Naruto style.

</comment></comment><comment><USER40> "Correct" intuition is the underlying key to this article.

The smartest people I know tend to often see things correctly, or do things correctly. Their intuition is just a form of intelligence, where something has been recognised but it can't necessarily be rationalised. Intuition has deeply negative connotations to many people, so we often use other words instead like: pattern matching, foresight, common sense, seeing connections, feeling in my /\w/, etc.

The problem with the word intuition, is that plenty of people have "incorrect" intuitions that fail, and often they overestimate their intuitive abilities (Dunning-Kruger intuition?). It is very hard to identify people with good intuitions, and sometimes we just say they have good luck.

Good intuitions are especially valuable with soft skills - anything where you have to deal with people and you start to spot someone with a knack - <USER2> should be highly prevalent in successful CEOs (and politicians, marketers etcetera).

"Obvious" is another way to say this: seeing something is obvious, then stating the rationalisations why it is obvious, only later to find out they were right but their rationalising was wrong (I find this frustrating).

From another comment: "it's just that he's doing it in such a vague and generalized way and passing it off as actionable advice that it becomes almost comical" \-- it really is _extremely_ hard to write about intuitions, and we often dismiss good commentary (even when written by a smart person trying to communicate something difficult to us).

Disclaimer: I am an engineer type that loves rational thought. I see my smart friends come up with intuitive answers that turn out to be correct, and then I struggle to try and learn the same skills.

</comment><comment><USER41> The corollary to this is that you have a CEO that overreacts to every bump and is constantly changing priorities to fight the latest fire their 'gut' is telling them about so nothing gets done. Your gut can't predict the future - solicit input and plan a strategy, agree with the data you have it's the best choice, define what metrics you'll use to know it's working and when you know it isn't and then execute.

</comment><comment><USER42> Sounds like they almost went bankrupt. As if the probability was very high. If that's the case, I'm not sure running towards fear is good advice because if someone else follows that advice, they will most likely end up in jail or something... Kind of like what happened to Elizabeth Holmes; look where runnning towards her fear got her. That's the normal outcome. The outcome OP got was abnormal, not a rational outcome and not a reasonable decision.

</comment><comment><USER43> I wish there was a little more to the article. I'm not a C-level, but that physical feeling of a big project possibly going south is real. Gut wrenching, sleep losing, fear.

</comment><comment> d--b Maybe it's good advice to address what you fear most first, but the problem is you're never sure that what you fear most is what's going to get you!

</comment><comment> kris-s Snake oil wisdom.

</comment><comment><USER44> this strike a chord with me. I am facing a bit of procrastination, that pretty much caused by fear. Fear of interviewing. I'm pretty unhappy with how things are but absolutely afraid to apply and interview for other jobs. Fairly pathetic state. I should definitely face this fear.

</comment><comment><USER45> I can never tell if he thinks the rap lyrics are funny or if it is cringe-ly serious.

</comment><comment><USER46> Every point in this article can also be used to talk about technical debt.

</comment><comment><USER47> "Do you intellectualize it away? "

This hits pretty hard.</comment>


Paying Skilled Workers More Would Create More Skilled Workers - <AUTHOR> https://hbr.org/2016/05/paying-skilled-workers-more-would-create-more-skilled-workers?utm_source=twitter&utm_medium=social&utm_campaign=harvardbiz <comment><USER2> This is a long way to spell "we know nothing and have nothing of substance to say".

"Market salary" by its very definition is what employers want to pay workers. It's hard to argue that most of the employers pay below market.

Employers' whining about shortage in technology sector is caused less by actual shortage and more by them unwilling 1) to pay more than currently and 2) to train unexperienced candidates (making them employees), expecting instead a supply of already well-skilled workers.</comment>


Wind powered car breaks speed record - <AUTHOR> http://news.bbc.co.uk/2/hi/technology/7968860.stm

<comment><USER2> Interesting looking vehicle. More photos here:

[http://www.motorauthority.com/gallery/ecotricity- greenbird-w...](http://www.motorauthority.com/gallery/ecotricity-greenbird- wind-powered-car.html)</comment>


Some Notes on Distributed Key Stores - <AUTHOR> http://randomfoo.net/2009/04/20/some-notes-on-distributed-key-stores

<comment><USER2> It's not perfect, but it's nice to see someone pop CouchDB's bubble.

It took me quite a while to realize that for all it's bluster, the all the talk about CouchDB being 'distributed' is at best conjecture, and mostly just bullshit.

</comment><comment><USER3> What exactly is a distributed keystore? Google's 1st result on this is the linked article.

<comment><USER4> He's talking about distributed key-value stores (aka distributed hash tables).

</comment></comment><comment><USER5> Nice writeup. Should have mentioned hbase as well.

<comment><USER6> No, it wasn't. When someone starts off with what appears to be a limited understanding of the difference between replicated and distrbuted, lumps systems that are clearly _not_ key-value stores in with the list (apparently so that he can throw in an vague dismissal and move on), and then ends the whole lame wrap-up by declaring that he just decided to write his own version of a system that was already on his list (but was dismissed because he thought parts of it were too complex for him to understand) then warning bells should be going off in your head.

<comment><USER7> _decided to write his own version of a system that was already on his list_

It isn't necessarily unreasonable to write your own version of an existing system. Sometimes you can do something much simpler that meets your particular needs. Also, in many cases it's easier to write code than to read it. Edit: the OP makes a similar point in an amusing way: _at least when it breaks, you'll be more fond of it_.

</comment></comment></comment><comment><USER8> Skeeviness? Did memcachedb offer him sex for crack?</comment>


Anonymous Calls For Internet Blackout On April 22 To Protest CISPA - <AUTHOR> http://www.huffingtonpost.com/2013/04/19/anonymous-blackout-cispa_n_3116509.html

<comment><USER2> Too little, too soon.</comment>


Paying For Privacy? - <AUTHOR> http://rayracine.github.io/posts/2013-09-25-github.html <comment><USER2> My team uses pull requests extensively. The master branch is considered good, clean, production-ready code. Anything you want to get into production gets there by way of a pull request. Want to add a feature? Fix a bug? Make a branch, do your thing, and create a pull request against master. The rest of the team reviews your code in the pull request; the comments in a pull request are an excellent feature. My job would be ridiculously harder without pull requests.

<comment><USER3> Right, I thought one of the big benefits about pull requests was that it let other devs easily view the diffs before merging a change in, not to mention making it easier for people to discuss the changes. I guess if you don't want to do that then it's easier to just pass around patches and merge.

<comment><USER4> Viewing changes in a pull request is no easier than viewing the changes in a patchset (or rather, if it is you're using the wrong tools). For an established team, a PR-based workflow and a mailing list based workflow (where you mail patchsets to the mailing list and discuss them there) are not very different, but PRs are a lot friendlier to outside contributors.

</comment></comment></comment><comment><USER5> Off topic: People who use Mother Teresa as the canonical example of selfless altruism need to read something about Mother Teresa so they don't look so silly.

<comment><USER6> Yeah, no kidding. Feeding and providing medical care for the Untouchables in India? She should have made an iPhone app to help find friends in restaurants nearby, that would have made he a real selfless altriust.

<comment><USER7> in her letters she said she was forbiden to provide actual health care. all they gave was a place for the sick to convalesce.

also, she and most othe rreligious still advocate over population and against several sane health treatments. not to mention education.

no little good religion does compensate for the long term damage.

<comment><USER6> They were given medicine, not just a place to convelesce, but even just providing a place to convalesce is a great mercy to people who were (and often still are) dying on the sides of the street, thrown away by their society as if they were nothing more than trash.

But then, what do I know, I am sure that you must know vastly more than I do, seeing as to how as a Christian I must advocate against education now. I should write letters to all of the universities I have attended, asking them to please revoke my diplomas on the basis of my religious freedom.

</comment></comment></comment></comment><comment><USER8> Just a reminder, if you want a private Git repo, you can always use BitBucket, which provides you free private repos. And, it's also an excellent service in it's own right.

<comment><USER9> +1

My public stuff all goes to github, and my private repos are all on BitBucket; virtually no cost to me that way and I use each service as it's promoted (imo).

</comment></comment><comment><USER10> In my opinion, and for almost any other remotely similar service, it's not about paying for privacy, it's about paying for convenience. You don't go home to get a beer, when you are going out, you pay extra money for the convenience of not having to carry around beer, an instead be able to buy it on the spot, in any wanted quanitity.

</comment><comment><USER11> First, I applaud the "rugged individualist" style of netizenship that the OP is advocating. Hear hear.

But (and you knew that "but" was coming) github is particularly useful and not amenable to the kind of gaming that Facebook and Google have indulged in. Git is truly distributed, and if github ever tried to block or manipulate repos there are full copies all over the place. It would be very easy (and dare I say such action would come swiftly) to _react_ to any such wayward behavior on the part of github, mainly because of the nature of git.

So: definitely host your own git repo, but if you use github for collaborating on public open source projects, you really aren't running any kind of risk that github will ever hinder your access or control in anyway.

</comment><comment><USER12> I pay github for the same reason I pay heroku. It _just works_ and I don't have to do anything. That is why they exist. Sure you can set up your own git server, but what do you do when it goes down?

<comment><USER13> The same thing you do when GitHub goes down...

 _PANIC_ and flock to HN to comment on a minor outage!!! - wait, no. git is a distributed system. You continue as you were and nothing changes.

</comment></comment><comment><USER14> yet another article that values our time at $0. come on, we all make something like $80-130/hr.

Are you really going to spend less than 1 hour maintain this sort-of-github instance you have?

<comment><USER15> He gains not only hosting value from maintaining the instance, but also the experience. And the experience is a valuable asset that you can't really buy with money.

Obviously, a sort of pre-built image to spawn "own" Gitolite/Gitlab/whatever instance would be nice, so noone but those particularly interested in the process would have to spend their time setting things up. But I suspect such images/build scripts already exist, it's just that I didn't even bothered to search for them.

<comment><USER16> Check out turnkeyliniux.org. They offer prebuilt linux images of popular apps - including Gitlab:

[http://www.turnkeylinux.org/gitlab](http://www.turnkeylinux.org/gitlab)

</comment></comment></comment><comment><USER17> I keep a lot of personal/private data in git repos. I'd rather have this data on my own hardware or servers I admin, can audit, can apply unusual SSH security policy to, etc. gitolite and gitlab are great Github replacements for this purpose.

That said, I still use github (or bitbucket, etc.) when I want to share code - it's still the best place to do that.

I just don't need their private service, which appears to be the same case as the author.

</comment><comment><USER18> If you don't use or like github features, you don't really need to pay for it. Sounds like common wisdom. OP listed points which do not define github. If you want unlimited private repos "in the cloud", just use bitbucket.

Github provides excellent interface and workflow patterns for code collaboration. I don't know, maybe for some it's reasonable to swap patches via mail, but for me hassle of downloading attachments from gmail into the right folder is just not worth it.

Also, laugh all you want, but rendered README.md and having all code at glance are life-savers. It's so much easier to get a hold of what another open source library does, if it has nicely formatted README with examples. Bonus points for gh-pages hosted docs.

</comment><comment><USER19> Watch out with the sending email directly from an EC2 instance. You don't really have a fixed IP so rDNS isn't going to work very well, and that's still a front-line filter for a lot of big email providers.

<comment><USER20> If you are an Amazon EC2 user, you can get started with Amazon SES for free. You can send 2,000 messages for free each day when you call Amazon SES from an Amazon EC2 instance directly or through AWS Elastic Beanstalk. Many applications are able to operate entirely within this free tier limit.

[http://aws.amazon.com/ses/pricing/](http://aws.amazon.com/ses/pricing/)

You could also use Mailgun, mandrillapp.com, etc. I believe they all provide at least 10-12K emails/month for free, by calling a RESTful web api.

<comment><USER19> Yeah, those are all great options. I know for sure Mandrill lets you send SMTP through them and I think Mailgun does too. It's just a matter of configuring your Postfix server to relay through them.

</comment></comment></comment><comment><USER21> I applaud the writer for his approach to making his own hub for his team. However, this is not a real 1-1 swap. In terms of pure functionality this may be an even exchange; his own platform might meet his needs just as well as GitHub. Yet it lacks major benefit - the community/public aspect of that environment. Duplicating that factor would take too much time an effort when you could just pay 7 bucks a month for the same thing.

Sometimes, while its fun to reinvent things, it just makes more sense to use what's there.

</comment><comment><USER22> I pay because github is a fantastically useful tool. I am willing to pay for quality software. If I wasn't and other people like me weren't willing to pay for software, a lot of us wouldn't have jobs.

</comment><comment><USER7> summary: paying a vps is cheaper and gives you more than git hub.

in my experience, pros: \- full control (he is not using this as he and all other probably commit as user git) \- commit hooks

contra: \- you take the time to setup, debug, maintain. (track all those pesky security updates) \- you have to backup. \- people already have their keys setup at github.

also, about the paying for privacy... i have two github accounts. one with my real name another with a pseudonym.

and to conclude, after some time, i just moved all my code to bitbucket. initially because i rather mercurial and they have both. but then because you get a few private repos

<comment><USER15> > i have two github accounts. one with my real name another with a pseudonym.

Until relatively recently (at least that was the case about an year ago) having multiple GH accounts was a TOS violation. (And I needed a pseudonymous account, so that drove me off to BitBucket.) They seem to have changed that, so you're not allowed to have more than one _free_ account per human.

</comment></comment><comment><USER23> Kind of OT: I have just opened a free github account to follow a project. Any tips for a painfully pathetic n00b for learning to use github generally?

<comment><USER24> If you understand Git well enough, then the only major difference Github adds is pull requests, which is a pretty intuitive concept once you understand Git branching.

Try [http://git-scm.com/](http://git-scm.com/) for a great (official) tutorial.

<comment><USER23> I actually know nothing about Git. But thank you for replying. Will check the link. :-)

<comment><USER25> I'd saved this link of an interactive "Learn Git" training program: [http://pcottle.github.io/learnGitBranching](http://pcottle.github.io/learnGitBranching)

</comment></comment></comment></comment><comment><USER26> How are you only paying $7? The lowest tier I can see is $25/month for 10 private repos.

</comment><comment><USER27> How does using Amazon's services make you any less of a "product"?</comment>


Intro to graph compression techniques for in-memory graph computation (2015) [pdf] - <AUTHOR> https://www.cs.umd.edu/sites/default/files/scholarly_papers/Chavan.pdf <comment><USER2> This appears to be a paper written for satisfying a CS Master's degree requirement. If you are looking for a survey on this topic, this is probably a better starting point: [https://arxiv.org/abs/1504.00616](https://arxiv.org/abs/1504.00616)

<comment><USER3> The authors website says they are studying for a PhD. Could it be their PhD thesis? [http://www.cs.umd.edu/~amitc/publications.html](http://www.cs.umd.edu/~amitc/publications.html)

<comment><USER4> That program has a requirement for writing a "scholarly paper" described here: [http://www.cs.umd.edu/grad/policy-manual#7.2.MS-nonthesis- re...](http://www.cs.umd.edu/grad/policy-manual#7.2.MS-nonthesis-requirements)

This was most likely done to satisfy that requirement to earn a MS "along the way" to a PhD.

</comment></comment></comment><comment><USER5> When was this written?

I personally hate non-dated preprints or technical reports. Only way to guess is to use max(date(ppaper) for paper in references), which may or may not be close the the actual date of writing.

<comment><USER6> Creation-Date of the PDF is 2 Dec 2015, 17:18

</comment></comment><comment><USER7> Thanks</comment>


Practical Project Management - <AUTHOR> http://www.telirati.com/2014/12/telirati-analysis-16-practical-project.html

<comment><USER2> It's about a practical hybrid approach to agile. This approach won't solve every project management problem, but it tackles several, among them:

a) Lack of overall control of project scope in Agile-mangaged projects.

b) Lack of tactical flexibility, especially in resource assignment, in "waterfall" style project management</comment>


Ask HN: What are your security tips for a person who has done the basics?  - <AUTHOR>

I am looking for advice targeted at an audience such as Hacker News. Thanks! <comment><USER2> Security tips for what? Your premises? Your laptop? Your network? Your home? Your servers? Apache? PHP?

</comment><comment><USER3> Do you manage your own server or use a PasS?</comment>


Speedup 12 machine learning algorithms with mapreduce on multicore machines - <AUTHOR> http://www.scribd.com/doc/508084/Map-Reduce-Multicore

<comment><USER2> This is a neat paper from NIPS 2006- and here is a PDF you can download without Scribd (which seems to require a password/login to download): [http://www.cs.stanford.edu/people/ang//papers/nips06-mapredu...](http://www.cs.stanford.edu/people/ang//papers/nips06-mapreducemulticore.pdf)</comment>


Social Resilience in Online Communities: The Autopsy of Friendster - <AUTHOR> http://arxiv.org/abs/1302.6109

<comment><AUTHOR> Link to full PDF, <http://arxiv.org/pdf/1302.6109v1.pdf></comment>


Alarm / Warning Fatigue - <AUTHOR> https://en.wikipedia.org/wiki/Alarm_fatigue <comment><AUTHOR> Alarm fatigue is quickly becoming an issue in warnings shown within browsers. Cookie warnings especially.</comment>


Should a non-technical co-founder learn how to code? - <AUTHOR> <comment><USER2> Everyone would benefit from a high-level understanding of programming, if that constitutes "learning how to code" then I guess so. If you mean should you be able to meaningfully contribute to the actual work of the programmers, probably not, as a co-founder you likely have better things to be doing.

The reason everyone would benefit from this high level understanding is the ubiquity of computation. It's going to affect all our lives, like it or not, you should understand at least a little about something like that if you can. You want a population who have a useful mental model when they're told e.g. that parole will now be decided by "an algorithm" and will ask useful questions like "Will we be provided with an understandable explanation of the algorithm or its decisions that we can criticise?" or "What parameters is the algorithm to consider?" not "Will the algorithm have a man's voice or a woman's voice?" or "What if the algorithm becomes sentient and tries to kill us all?"

</comment><comment> jerome-jh It is always beneficial to learn something new, but do not expect to write production ready code in less than two years learning/practice. So learn how to code as a hobby, and for your business concentrate on your field of expertise, deepen it, communicate a lot with technical people.

</comment><comment><USER3> My answer is yes. Of course, everyone does its own job, and can't learn everything but basic essentials in programming will help to understand each other better</comment>


Jumbo: Privacy Assistant for iPhone - <AUTHOR> https://www.jumboprivacy.com/ <comment><USER2> I'm willing to bet good money this app still leaks data in the form of app analytics.

<comment><USER3> From the privacy policy:

"Analytics Our iOS application can send analytics to our analytics providers: Segment and Amplitude. We do not track or store any personal information in our analytics. Instead, we ask Apple to generate a unique deviceID which we use as a unique token for analytics purposes. Our analytics are 100% anonymous."

<comment><USER4> I feel like a unique ID isn't enough to protect your identity from an analytics provider, especially if they're receiving analytics on you from multiple sources.

<comment><USER2> Exactly. They just have to correlate device type & OS version & IP address & date/time to have a pretty good idea of which other apps (& their "unique" IDs you have).

The more they do it the more they can narrow it down, until they reach the point where they have a set of IDs that _only_ ever come from the same device/version, IP address as well as very similar times of day.

<comment><USER5> No, because we've designed protection against collecting IP address, device type and OS. We don't use any SDK from Segment, Amplitude, or any third party analytics. Our iOS app only sends a device UUID, an event name (user:opened:app) and some event properties (not personal information). Someone should feel free to reverse-engineer our network requests to confirm what I'm saying.

Also, let's talk about IP address.

We have a CloudFlare worker that sits between our app and our analytics proxy (which role is to send data to Segment). And this worker from Cloudflare is a piece of code that removes the user ip address from the request made to our proxy, hosted on Heroku.

Here is the worker code: [https://gist.github.com/pierrevalade/85bbe1e5278b81813e08e7e...](https://gist.github.com/pierrevalade/85bbe1e5278b81813e08e7ed9a76250b)

That way, only Cloudflare gets the user IP address (and to my the best of my knowledge I don't know how to access it), and our servers never get it.

<comment><USER2> How can I confirm what you are saying is true regarding the IP address, other than taking your word for it (I heard that worked great with Facebook)?

Why does your privacy policy mention third-party analytics then? Why do you mention "Segment sends the data to Amplitude" in another one of your comments if you claim here that you don't use any third-party analytics service?

Also, just wondering - why do you need to send _anything_ in the first place? People have been building software just fine for decades before this whole "analytics" plague started going around, and I didn't notice software quality being improved by it (if anything software has gone significantly downhill).

<comment><USER5> 1/ What do you mean confirm what I'm saying for the IP address exactly?

2/ I said we don't use any (mobile) SDKs from 3-parties analytics, but we do use their backend (Segment, Amplitude). We send the requests from our anonymous proxy directly to their servers.

I was worried that mobile SDKs would leak other data (iOS version, device size, ...) that I don't want to know about. And as a general rule we don't like to use SDK/code from 3parties for security reasons.

3/ We use analytics to track how many users are using the app, and how many users are using the cleaning features. This data does help us to make strategic decisions.

<comment><USER2> 1) I mean how can I prove what you're saying is true as a user? As far as I'm concerned the app is sending a packet to a domain name you control. Nothing guarantees me this is actually a Cloudflare server running your code to remove my IP address. Ten years ago I would've just trusted you, but in today's day and age where _everything_ tries to stalk you in one way or another with full impunity, trust no longer exists.

2) Good thinking!

3) Doesn't the App Store give you stats on how many people downloaded their app?

Also I'm concerned about "strategic decisions" - so it's a business behind this app then. What's the business model? Last time we had a business claiming to unsubscribe you from newsletters... turns out they were actually sharing data with marketing companies, so I'm rightfully concerned.

<comment><USER5> 1/ I'm thinking about ways to have trustable 3-parties audit us. Open for more ideas. What do you think?

3/ yes, unroll.me made the wrong calls. But for Jumbo we can't even access your data, everything happens client-side. You could say that at some point the client will upload all your to our cloud, but that's really not going to happen. Again, here, how to trust us? First, audits. Second, my reputation. Third, independent researchers would reverse engineering our app, and look at the networks call made. Open for more feedback

Our business model is the one of Dropbox. Pay (you or your employer) for more features.

<comment><USER2> 1) your idea would probably be a lot more costly (you have to pay for the audit after all) and even then some people still wouldn't trust it. Maybe just design your product in such a way that there's nothing to audit? People have built software & successful businesses around that for decades without the "analytics" cancer, so please don't tell me that you can't do the same.

If your model is a good old "pay for good software" model, then why not just _ask_ what features people want? Why do you feel the need to _stalk_ what people do instead of politely asking?

<comment><USER5> How would you trust me if I tell you that there isn't any analytics?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> I used it to remove old tweets, but nothing else. The presets aren't very flexible. The oldest tweets I could delete was anything more than 3 months old. I would have preferred a longer timeframe like older than 2 or 5 years.

I didn't try it for Facebook. It has three general settings (public, friends, and just me). I've already tuned Facebook as best as I want. It wasn't clear what FB would overshare or under-share with Jumbo's settings.

<comment><USER7> I also dislike how they've conformed to Facebooks notion of privacy (it's private if only Facebook can see and use it, not others), as opposed to the traditional definition of retaining individual decision-rights over disclosure.

<comment><USER8> Agreed, but it's still better for most people than having things shared with everyone.

This seems like the sort of app one might use to prevent James Gunn style problems from old content.

</comment></comment></comment><comment><USER9> Anyone have a sense of the business model? Seems like a handy way to help folks manage privacy, but without understanding how they plan to generate revenue I'm hesitant to get on board.

<comment><USER10> Pierre Valade, the creator, stated on ProductHunt that they will monetize via a premium version in the near future.

[https://www.producthunt.com/posts/jumbo](https://www.producthunt.com/posts/jumbo)

<comment><USER5> that's correct. like Dropbox. thanks for sharing that link ekovarski

Pierre, CEO

</comment></comment></comment><comment><USER11> I'm in my mid 40's.

I've learned in my life of computing since the TI-99/4A is that privacy is not an app or program or device... It's all analog - what the end use does and does not do. I don't see this really pushed today, the personal responsibility of personal data.

<comment><USER12> >> what the end user does and does not do

You hit the nail on the head, I couldn't possibly agree more. People have to think(ahead - sometimes quite a ways) before they act.

</comment></comment><comment><USER13> The sentiment is nice, but is it naive? (Even having accounts with any of the listed services feels dubious these days)

Are there (or will there be) any features/benefits for people who don't have social media accounts?

<comment><USER14> Managing social media permissions is the point of the app.

Is there any benefits of auto insurance for people that don't have cars?

<comment><USER13> Being dubbed a "Privacy Assistant", it could be construed as having implications beyond just social media.

<comment><USER5> Jumbo helps in deleting old Google Search, and Alexa voice recordings. So it's beyond social media in that sense. Tomorrow we will support Tinder, and more.

</comment></comment></comment></comment><comment><USER15> I'm perplexed as to why this is an iOS only application. Surely most of the actual API calls are being done server-side? It have made more sense for them to launch a web app instead while they expanded the product offering, and then brought it to native apps.

<comment><USER5> You are raising a good question..

Jumbo works 100% client-side, that's why we have built it as a native app.

You can read more on our architecture on our blog: [https://blog.jumboprivacy.com/secure-jumbo-never-sees- your-d...](https://blog.jumboprivacy.com/secure-jumbo-never-sees-your- data.html)

It's quite cool. We don't have any servers processing your data.

Pierre, CEO Jumbo.

</comment></comment><comment><USER8> This looks really nice - There are browser extensions to do a lot of these things, but those don't work on iPhone, so having a native app is a nice touch.

I also appreciate that they know they're selling to a privacy-conscious audience, so they go over the top in assuring that it's all done client side!

Very nice so far.

<comment><USER3> I like it on first impression but I wonder whether tools like this will convince people they have privacy, when really they are getting a better interface to semi-privacy settings in existing privacy invasive apps.

<comment><USER16> I really like the idea of the app because it lowers the barriers to entry for an entire set of people who otherwise might not take the necessary steps to increase their privacy.

These are baby steps for sure, but maybe one day all these people will be ditching google for duckduckgo and protonmail, etc.

<comment><USER5> Absolutely, I've designed the product so that my mom can use it. She can't use a Chrome extension, but she can download an app like Jumbo.

</comment></comment></comment></comment><comment><USER17> Pretty cool that this is done client-side, although it does need more presets. I'd also want to be able to export/import my old posts, or at least manually review, but that's getting into the kind of features I'd expect from a paid tool.

</comment><comment><USER18> My years-long history of using Facebook as an idea log (often with long long posts) is what has stopped me from deleting altogether. This promises to be a simple way of downloading everything.

Facebook should be scared. It's at least X% of the lock-in they have on people.

<comment><USER19> You can just download an archive of your Facebook data, no need to use this app:

[https://www.facebook.com/help/212802592074644](https://www.facebook.com/help/212802592074644)

<comment><USER20> There's also a plethora of parsers available at this point to output your data to any format imaginable

[https://github.com/ownaginatious/fbchat-archive- parser](https://github.com/ownaginatious/fbchat-archive-parser)

</comment></comment></comment><comment><USER21> I like the concept. Simplified privacy settings management and content deletion make a lot of sense for non-technical users.

</comment><comment><USER20> Nobody works for free. If there's no direct cost, you are the product not the customer.

<comment><USER5> You're right. Like Dropbox has a free version, and a paid one. Right now we are launching the free version, and paid features will come later.

</comment></comment><comment><USER22> Man I'm so pumped for iOS users!</comment>