Java 8's new Optional type doesn't solve anything - <AUTHOR> https://medium.com/@bgourlie/java-8-s-new-optional-type-is-worthless-448a00fa672d <comment><USER2> The lack of pattern matching doesn't make it useless. The existence of Optional reminds the programmer to check whether the value is present, and the type system does enforce this; you can't accidentally treat an Optional as a reference of the same type. The type system does help us remember to handle things; it is a reminder enforced by the type system that's easy to examine during code review.

Yes, you can write get() and risk an exception. So don't do that. I'm still glad get() is present because there are times when the human knows the value will always be present, but sometimes in a way that can't be encoded in the type system. Alternatively, sometimes an absent value is an error and get() is an acceptable way to check-and-throw.

I agree with the suggestion that static analysis can be useful, though many users had that already with FindBugs or Fortify. If we're talking about annotations based analysis, then it only goes so far. Optional and streams provide useful new tools for documenting intentions from my perspective. Another reason I enjoy the type is because it makes it a little more reasonable to say that, at least in new code, all references are nonnull references by default, since they'd be Optional otherwise.

<comment><USER3> Exactly, it forces the programmer to think about whether something can be null or not and actually had a behavioural change in my java coding.

<comment><USER4> Wouldn't it be better to have a non-nullable type, akin to C++'s return by value? That way, instead of forcing the programmer to think, you are removing the problem that they would need to think about.

<comment><USER5> In other languages that use Option types more natively, like Scala, anything that isn't optional is assumed to just not be null: The compiler doesn't guarantee it (it's not as if it can, we are dealing with a JVM here) but it works in practice. I've not seen a NullPointerException in years.

Option has other advantages, like its compositional qualities (thanks to Option being a monad). So imagine the following code

def foo(x:Option[String]) = x.filter(_.length<10).map(_ + "More data")

If the function returns None if it receives either None or a string longer than 10 characters, and if we got Some("short "), foo will return Some("short More data"). The alternatives without an option type, involve at least a couple of branching statements, even if you have a non nullable type, to convert from nullable to not nullable, while Option does it all for us.

<comment><USER6> > _I 've not seen a NullPointerException in years [in Scala]_

This sounds odd. Does your code never interface with Java libraries and frameworks? I envy you! It's all too easy to forget to wrap a suspect value from Java-land with an _Option(..)_. And cumbersome even if you do remember.

And then, there's the code written by Scala novices who just love using nulls. Yes, yes, "code reviews", we all know they are always practiced all the time :/

<comment><USER7> The Scala landscape is very, very quickly creating their own libraries for similar popular Java libraries/frameworks. It is entirely possible to create an application, web or otherwise, that uses no Java libraries at all (save for the sbt dependency tree).

As for "Scala novices who just love using nulls", if you're seeing that, then the coder in question missed day 1 of Scala training, which is always "if you are writing the word null, you are doing something wrong" (right up there with "if you are writing the word var, you are probably doing something wrong").

<comment><USER6> Maybe, but if true that's still in the future. The OP claimed they hadn't seen a NPE "in years", which simply doesn't match my own experience.

As for novices: yes, novices tend to do that. They tend to miss, misremember or fail to put into practice what they should have learned on day 1. I've also seen senior devs who were not exactly newbies (in general) still using nulls because they don't grok Scala; the famous "you can program Fortran in any language". The _reality_ of software development is that you have to deal with all these people.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Adding my voice to the din of people noting how far afield of the point the author is:

You should almost never call .get(), except in cases where the code path does not allow an empty optional.

Even so, calling .get() on an empty optional is better than handing nulls around. A null may -- by chance, really -- make it several lines down the code, so that the stack trace points you much later in the code than where the null originated. Calling .get() on an empty optional _immediately_ throws a NoSuchElementException, pointing you directly to the line where the optional was empty where it shouldn't have been.

Consider this code:

        User user = getUser();
        // other stuff here
        // ...
        // ...
        String userSummary = formatUserSummary(user);
        // ...
        // ...

where

        public String formatUserSummary(User user){
            return "Franchise Location: " +
                user.getFranchise().getLocation().getName() +
                " Username: " +
                user.getUsername();
        }

An NPE occurs inside of formatUserSummary. Where did the null come from? Is the user's Franchise null? Maybe the Franchise's Location? Or is it the User that's null?

If you instead took an Optional<User>, _even if_ you just immediately unwrapped it with .get(), you'd at least get an error that unambiguously told you that it was the user that was missing.

<comment><USER9> > Where did the null come from?

A bit offtopic but SAP JVM puts that info in NPE error message[1], I don't know why others implementations don't, maybe it is incurring too large overhead?

[1] it is something like "Attempted to call getLocation() on Franchise object returned from getFranchise() but it was null"

<comment><USER10> Interesting, first time I heard SAP has a JVM implementation.

[https://scn.sap.com/people/desiree.matas/blog/2011/12/07/sap...](https://scn.sap.com/people/desiree.matas/blog/2011/12/07/sapjvm- overview)

Here is a presentation with some interesting points, wonder if anyone has any real-life experiences?

[https://www.youtube.com/watch?v=arryAs9lqfE](https://www.youtube.com/watch?v=arryAs9lqfE)

</comment></comment></comment><comment><USER11> The author is missing the point. The fact that Optional can result in a nullpointer doesn't mean you should use in the same manner as null-checks.

You _shouldn 't_ replace:

      if(x == null)
      {
        y = x.doSomething();
      }

with

      if(optionalX.isPresent())
      {
        y = x.doSomething();
      }

You should replace it with:

      y = Optional.ofNullable(x)
        .map(ClassX::doSomething)
        .orElse(null);

<comment><USER12> _The author is missing the point._

Is he? The point is that in Java you are still able to treat x unsafely, while languages with stronger typing do not. E.g. in Haskell, if a function returns a _Maybe a_ , it will always be a _Just a_ or _Nothing_ value. Moreover, such languages allow you to make non-exhaustive matching against all constructors a compiler error.

tl;dr: Haskell, Rust, et al. put the burden on the compiler. Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.)

<comment><USER13> >tl;dr: Haskell, Rust, et al. put the burden on the compiler. Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.)

Actually, (much to my disappointment as I'm just learning rust) you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. For such a "safe" strongly-typed language, I'm surprised that _so much_ new rust code does this when:

* the developer believes the Option/Result can never be None/Err (oh come on, just wait until you refactor your code a bit one day and miss a spot)

* the code is example code (I've had little luck finding "good" examples sprinkled about github)

* the developer is lazy (see above)

Allowing unsafe unwraps defeats a core purpose of rust, and the unwrap method shouldn't even exist in the API.

<comment><USER14> I completely agree. unwrap() is a huge mistake in Rust. There are brilliant ideas implemented in Rust (primarily the borrow checker) but their advantages seem to be wiped out by the kludge of unwrap.

<comment><USER15> Care to explain why? Whatever unwrap provides can be done with a match+panic. Which is more explicit, but that's just splitting hairs -- unwrap is pretty explicit anyway.

<comment><USER16> I understand the anger but at the same time I don't.

Overall unwrap() isn't good. Really it should be replaced by TODO WRITE ERROR HANDLING in 90% of its cases. That being said there are still good uses for it.

The main _safe_ use for unwrap() I find is when dealing with an iterator of Results/Options (which seems to happen a lot). The pattern:

          .filter( |x| x.is_some() )
          .map( |x| x.unwrap() )

Is safe, and I really don't know a more eloquent method of handling these operations.

<comment><USER15> I'm not angry.

> Really it should be replaced by TODO WRITE ERROR HANDLING in 90% of its > cases.

That's what the Rust community reads it as, mostly.

I've seen it occur very infrequently in libraries (aside from example/benchmark/test/mocking code, of course). When it does its usually for really out of whack errors like poisoned mutexes, crashed threads, etc (mind you, these are for unwrapping error values, not options, but it's almost the same thing). Or for cases where it's known to be valid due to invariants that can't be expressed in the normal way.

I did a quick grep of hyper, and the unwraps are almost all in "dev" code (tests/benchmarks/etc). The cases where they aren't are where there was an `is_some()` earlier (and due to some reasons it couldn't be restructured as a match, perhaps just because of rightward drift), or the "invariants" thing -- i.e. it often calls `<some url>.serialize_path().unwrap()`, which is OK, because hyper only ever deals with relative schemes (e.g. `[http://`](http://`) and `[https://`](https://`), not `data:` or `mailto:` -- the latter two don't have paths), which is checked in the constructors, so this should NEVER panic. I didn't go through all the code, but in the main HTTP and HTTP2 code serialize_path was the only offender, which was one that was justified.

I see it more often in applications. In the following cases:

\- Example applications in blog posts (because you want to explain something else, not spend too much time on error handling)

\- Slightly less out of whack errors which are weird enough that they should close the app

\- Normal errors which should close the app (e.g. "insufficient permissions" for a command line util, or a port-opening error on a network app). unwrap() prints out the error message so this is a very rudimentary form of error handling anyway.

\- Laziness, or often with a TODO. Not too common.

So, it's mostly used in justifiable ways, and that's why it exists in the stdlib. It doesn't "wipe out" anything that the borrow checker provides (borrowchk and exhaustive match are two different things), and while it's a kludge if used often there are legitimate reasons to use it; enough reasons to have it in the stdlib.

> I really don't know a more eloquent method of handling these operations.

        .filter_map(|x| foo(x))

:)

(but yes, in general there are situations in which you _know_ an Option is unwrappable, e.g. the serialize example above)

<comment><USER16> > filter_map(|x| foo(x))

Thanks :D

I've been really struggling to _get_ iterators in rust. I don't have a very strong functional background :|

<comment><USER17> Note that anytime you see a closure in any language that just takes a single argument, calls a single function with that argument, and returns the value of that function, then you can eliminate the closure entirely by just passing the function instead.

So `filter_map(|x| foo(x))` can be written more simply as just `filter_map(foo)`.

<comment><USER16> I know this but I can never get my code to compile when doing this. I always seem to get huge type errors even when I know the code is correct.

         map(|x|foo(x)) //clean compile
         map(foo) //type error

The number of times I've had this happen has just lead to me giving up on simply just passing the lambda as a variable instead of wrapping it in another.

<comment><USER17> Curious. Can you provide a full code example so that I can try to determine what's causing that error?

<comment><USER15> Usually in these cases the culprit is autoderef/deref coercions.

<comment><USER17> I don't see anything in `|x| foo(x)` that could be causing `x` to be deref'd.

<comment><USER15> A deref coercion can happen there

[https://github.com/Manishearth/rust- clippy/issues/116](https://github.com/Manishearth/rust-clippy/issues/116)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> I've been using Swift for over a year now, which has had an Optional implementation from day one. I see a lot of people defending Java's implementation in this thread, can someone check my understanding? I did Java in a past life but am not super familiar with Java 8.

In Swift, types are non-optional by default. You can never end up with a null, the compiler makes it impossible. Optionals are out of the way until you need them, and if you use them properly (i.e. avoid the .get() equivalent), it's still impossible to crash from a null.

In Java 8, things can still contain null by default and you might not know about it, right? You can express that something is Optional in your API, but that's only marginally better than documentation, doesn't solve "unexpected nulls" whatsoever, and makes this only halfway to a solution and therefore broken entirely. Why not just use annotations?

Are my assumptions and understanding correct?

<comment><USER19> I don't think anyone thinks that Optional as it is in Java right now is the perfect solution. The article seems to be making the case that Optional isn't an improvement of what came before, which is what people are having issues with.

<comment><USER18> Ah. Right! "doesn't solve anything" is definitely not the case:)

</comment></comment></comment><comment><USER20> I've only used the Guava version of Optional, which appears to have a slightly different API than Java 8's. (You can tell there's a Java 8 committee, that's for sure.)

The biggest problem I found in applying Optional is that Optional is very much a Haskell-y concept to me, and Java programmers and Haskell programmers don't really overlap much. Therefore, to me, Optional is just a functor like a list or a set. So doing Optional.asSet() and iterating over the result is, to me, the correct way way of handling an optional value. If there's something in there, the loop runs once. If there's not anything in there, the loop runs zero times. This is exactly like "fmap" in Haskell:

      Prelude Data.Functor> fmap (+1) $ Just 42
      Just 43
      Prelude Data.Functor> fmap (+1) $ Nothing
      Nothing

(Except that Haskell automatically preserves the type safety, whereas you have to re-wrap the value if you're using Java. Functional programming in Java never works, and this where the Optional idea starts to go wrong.)

But I got "I don't really understand this" in code reviews every time I did that; the Java way is to check if it's set, then do a type-unsafe unboxing. Thus, like the article said, completely defeating the purpose of the Optional type.

That said, it's pretty rare to need exactly 0 or 1 of something. If you're doing a database query, you can probably make the API return a set of rows. Then it's natural to loop over the results and nobody raises their eyebrows.

<comment><USER21> It always bothered me that Java8 and Guava optionals don't just implement Iterable. There must be a good reason for this, and I'm guessing they're worried about confusion when you have an `Iterable<List<T>>` but still, it'd be really nice to be able to just write

       for (T result : potentialResult ) {
          //...
       }

I agree with you, that just seems so much more idiomatic than

        if (potentialResult.isPresent()) {
           T result = potentialResult.get();
        }

But maybe it comes from my mental model of Optional being a 0- or 1-length collection. It's at least definitely treated as a functor in that for pure functional operations, you have .map (or .transform for Guava).

<comment><USER22> The Guava authors believed Iterable would be confusing without calling .asSet() first.

</comment></comment></comment><comment><USER23> Brian Goetz's response: _" They didn't solve the problem I thought they should have solved, so their solution is worthless." Thank you, internetz._[0]

In any case, that's not what Java's optional is there for[1]. Solving the safety problem is the job of Java 8's pluggable type systems[2] that are both more powerful than the static-analysis tools listed in the article _and_ had Oracle's official support (in the form of JSR-308).

[0]: [https://twitter.com/BrianGoetz/status/656860771196887040](https://twitter.com/BrianGoetz/status/656860771196887040)

[1]: [http://stackoverflow.com/a/26328555/750563](http://stackoverflow.com/a/26328555/750563)

[2]: [http://types.cs.washington.edu/checker- framework/current/che...](http://types.cs.washington.edu/checker- framework/current/checker-framework-manual.html)

</comment><comment><USER24> TL;DR You can call `Optional.get()` to deliberately circumvent the safety mechanisms of Optional.

The author apparently concludes that since it does not solve ALL error cases it does not solve ANY error cases...

<comment><USER25> The problem is that you don't get guarantees that something is not null; you can still do Optional<T> myOptional = null. Second, you're not required to handle the not-present case. Third, if you attempt to get the value of an optional (using .get()) when it is not present, you get an (unchecked, so no requirement to catch) exception - basically replacing NullPointerException with NoSuchElementException.

The only value Optional has over regular values is that the developer has to assume the value can be missing - but the same was true for nullable properties.

<comment><USER2> > Optional<T> myOptional = null

That hasn't been a problem for me in practice. It's pretty clear that a reference to Optional should never be null. It can be statically or dynamically checked with @Nonnull or a precondition.

> but the same was true for nullable properties.

It's inconvenient to have to treat everything as possibly null. It's a lot nicer to create the convention, within one's codebase, that references are always nonnull and only Optional are nullable.

<comment><USER26> > That hasn't been a problem for me in practice.

It has for me. Functions have multiple return points, some of them returning "null". Lead developer insists we use Optional<> to clarify that these functions can return null. People go over the function, replacing each instance of "return null" with "return Optional.empty()", but forget some instances. Now we have Optionals that are sometimes null.

<comment><USER27> But that's a bug in the library (or code you're calling into), not a bug in how you're using it. That's the main difference in my opinion.

Optional allows the code to say "I never intend to return null, only an Optional that may be nothing". In theory, a library/module/whatever that's been converted to use Optional should not have any calls that do return null.

In theory, its no different than a C API that can return a size or -1 for failure. Sure, it could return -2 because the language allows it, but you shouldn't need to check for that in your code that uses it.

</comment></comment></comment></comment></comment><comment><USER28> I don't program much Java, but how expensive are exceptions? Wouldn't it make more sense to expect functions that could return null to instead throw a checked exception if something goes wrong?

eg

         public dbResult doDatabaseThing(stuff) throws DatabaseException

So if you do

         result = doDatabaseThing(stuff)

the compiler will require you to do something about the DatabaseException.

It seems to me that the point of, for example, Option and Result in Rust is to avoid the whole checked exception mess while still passing useful information about things that go wrong. But, given the problems pointed out in this article (lack of pattern matching and algebraic data types mostly), checked exceptions might be a more correct way to do it in Java.

<comment><USER29> Yes. In this case the No-result means that the database query was successful, but no record was found. A connection error etc. should almost certainly still be thrown as an exception in Java.

Without exceptions you would have to return a value that could discriminate between all 3 possible outcomes: nothing, error, result. In Rust this is the `Result<T, E>` struct.

<comment><USER28> It that case, wouldn't it be better to return something other that `null` for no-result (an empty iterator? an empty list?)? That might be where Optional comes in, but I'm still not sure why a new language feature is needed for that.

<comment><USER29> Yes, the Optional<T> is a "0 or 1 result" type. It's little more than a list with max length 1.

</comment></comment></comment></comment><comment><USER30> Optional is planned to become a value type in Java 10, so while the current situation is less than perfect I don't consider it a big problem.

</comment><comment><USER31> Using get() is just bad style and so is returning null where you could return Collections.emptyList().

Previous discussion on reddit: [https://www.reddit.com/r/programming/comments/3pl7o0/java_8s...](https://www.reddit.com/r/programming/comments/3pl7o0/java_8s_new_optional_type_is_worthless/)

tl;dr: use map, orElseGet, orElse

<comment><USER32> Why it's bad? If I'm sure that this optional contains value, I don't see why it's bad. May be I checked this value presence few lines above.

<comment><USER33> If you are certain optional has a value, don't use optional.

Checking presence of value of an optional is an anti-pattern, the same as doing != null checks.

You should treat Optional the same as a List type with size 1. You never check if a list is size 1 before doing map or filter.

<comment><USER32> I'm not always own code. Simple example:

        getCharsetOpt("UTF-8")

There is no way this code will return None in this particular case. So any additional checks are unnecessary and make code less readable.

<comment><USER34> I don't know who said it, and this is probably a paraphrase:

"If it can't happen, it will".

If a function says the result is optional, then it's optional. It's not _not_ optional because you decided it can't ever fail.

</comment></comment></comment></comment></comment><comment><USER35> Shameless self plug

"Comparing Optionals and Null in Swift, Scala, Ceylon and Kotlin"

[http://codemonkeyism.com/comparing-optionals-and-null-in- swi...](http://codemonkeyism.com/comparing-optionals-and-null-in-swift-scala- ceylon-and-kotlin/)

<comment><USER36> FYI your Scala example doesn't work.

        Welcome to Scala version 2.11.6 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_45).

        scala> var h:Option[String] = "Hello".some
        <console>:7: error: value some is not a member of String
           var h:Option[String] = "Hello".some

<comment><USER37> The author is using the scalaz syntax, you could substitute it for the "vanilla" syntax:

        var h: Option[String] = Option("Hello")

or import scalaz (in case you have it in your classpath etc):

        import scalaz._, Scalaz._
        var h: Option[String] = "Hello".some

</comment></comment></comment><comment><USER38> I think the main use of Optional is in a codebase which doesn't _ever_ allow "null".

If every method call either returns an actual object then you can get rid of null checks, and not bother doing any checks on method returns that don't return an Optional.

<comment><USER39> That is exactly how we use Optional.

</comment></comment><comment><USER40> Optional (either JDK or Guava) is not perfect but is infinitely better than hand-checking for null. Among other things, it expresses the intent of the API writer that their method may or may not return an absent value and this is expressed via the type system. This is in stark contrast to using null as a primitive, which has no such transparency. For instance, there is no difference in Java's type system between a method that intends to always return a non-null String, and one that intends to return a null String under certain circumstances. Thus it is impossible for the user of the API to determine when to build conditional logic to check for null or when not to bother.

In any case, the concept of null as a primitive is fundamentally broken. Due to Java's backward compatibility requirements, it's too late to resolve this in that language. However, newer languages don't need to make this mistake. However, there are "interoperability" requirements for new languages interfaces with legacy runtimes that tempt language designers to build escape hatches. These escape hatches exist in Swift, Kotlin, Rust, etc even though they're not recommended and their usage presents edge cases.

Ceylon and Haskell seem to be the only two languages to get this completely right. Ceylon expresses optionality as the union between the present value type and null, which is an actual type separate from Object. An optional String is therefore a String|Null, or a String? Haskell accomplishes this with the Maybe type.

All this to say that null should not be a primitive but should be banished to its own corner of the type system with clear compile-time semantics for dealing with the absence of values.

<comment> nv-vn There are actually a lot of languages that do it in the same way as Ceylon does. However, Haskell goes a step further than most other languages by defining Maybe as a monad in the standard library.

</comment></comment><comment><USER26> We tried to use Optional<> instead of returning null. Accidentally returning null from methods returning Optional<> is something that actually happens, especially when migrating existing code. Of course you can solve that with @Nonnull annotations, but then why use Optional in the first place?

The other problem is that the Optional<> interface is clunky. There is ifPresent(), but no ifAbsent(). The stream syntax is incompatible with the rest of the Java world, in the same way that List<T>#toArray has always been ridiculous. And if you use ifPresent(), you have to live with the fact that you cannot return from Java lambdas, and you cannot change any variables or even use non-final variables. I want to scratch my eyes out when I see people allocate one-element arrays on the heap just to work around Java's lambdas.

I don't see the value of Optional<T> if you already have @Nullable.

<comment><USER41> >if you use ifPresent(), you have to live with the fact that you cannot return from Java lambdas

That's what map/flatMap is for, ifPresent is really only useful for side- effects.

</comment></comment><comment><USER42> All of these problems seem trivial to me. The problem with Optional is that it isn't baked into the API, nor can it ever be, so any use of Optional is after the fact, applied only by the application, which means you need to wrap api calls in Optionals manually, which is something that gets real old, real quick.

</comment><comment><USER32> I don't understand what's wrong with get() method. Swift has built-in null- safety and it has "!" operator. Kotlin has it. Even Haskell has fromJust function which does exactly the same.

May be name "get()" is too short and innocent-looking.

<comment><USER12> Partial functions such as _fromJust_ are generally frowned upon in the Haskell community. There was a relatively recent proposal to deprecate and then remove fromJust:

[https://mail.haskell.org/pipermail/libraries/2015-February/0...](https://mail.haskell.org/pipermail/libraries/2015-February/025010.html)

<comment><USER43> The equivalents are not celebrated in other languages.

</comment></comment></comment><comment><USER44> I think in this thread when we talk about "pattern matching" (which _is_ awesome) were caught up with two notions: pattern based destructuring of input and type enforced exhaustiveness checks. Java 8's Optional does give the latter:

> maybeT.map(t -> ...).orElse(...)

The author does make a good point that 'get' is unsafe. I think it was a necessary concession to team members who are learning how to program in this manner.

</comment><comment><USER45>
      public Optional<Long> badIdea() { return null; }

I think the fact that this compiles is all the argument necessary. What java needed was a ThisWillDefinatelyExist<Object>. Not the opposite, but java just can't do that.

</comment><comment><USER46> Where did this myth that Option types are the "solution" to nullable references come from? That's got it perfectly backwards. The solution to nullable references is to remove them from the language; Option is just a means for languages that have already done this to encode nullability into the type of a value add necessary, as it should be. And people claiming that a language needs pattern matching or it doesn't solve the problem?! It makes me worry that those advocating these ideas are just part of the latest cargo cult and don't really understand the underlying principles or why these are good ideas in the first place.

</comment><comment><USER47> I thought Optional was mostly for the steam API, and not just general usage?

<comment><USER47> Also, despite it not being "standard" @NotNull, and @Nullable have worked really well for me so far. And I don't think Optional was meant to replace them.

</comment></comment><comment><USER48> We've been using Optional<T> a lot in recent years (via Guava). It's useful, and has certainly reduced the number of NPE we've had slip through as it forces the developer to consider nullability up front. Looking forward to migrating to the Java 8 version when we upgrade to that JDK.

One addition that would be useful would be some syntactical sugar to reduce the verbosity of using Optional<T>. But otherwise I'm happy and if you combine with @Nonnull and @Nullable annotations you get the best of both worlds.

</comment><comment><USER49> some have already commented here that author maybe complains too much (e.g., calling .get() on an Option<T> is a deliberate move, meaning that the developer explicitly took on the risk of that exception. that's very different than implicitly assuming that a regular ref is not null, using it and getting bitten in the ass.). but this one really hurts:

"The last flaw with Java's implementation is a bit ironic — It's possible for the optional reference itself to be null."

ouch.

<comment><USER50> This is another off-base point, in my opinion. Sure, it's possible for it to be null, and that isn't great - but the vast majority of null problems come from the user assuming the interface won't give you a null. Something returning an Optional should never return null, so the ambiguity is resolved. Sure, it still could as a bug, but that's actually a pretty rare case. I don't see it being a real problem.

<comment><USER49> that makes sense. i think an important question here is - what does "return null" in a method which returns Optional<T> do? will it return a null Optional<T>, or will it return a non-null Optional<T> which is empty?

sorry to rub it in, but Java needs value types. this whole issue, however maybe irrelevant, does not exist in C#.

<comment><USER51> It's a very simple question to answer: "return null" returns null.

<comment><USER49> then this abstraction has sprung a serious leak. the article seems to be fully right.

<comment><USER50> The point is that wherever that happens, it's an obvious flaw with the method returning the null, and can also be caught by static analysis. It means that in general, the problem is avoided.

Yes, it's not ideal, it's still a flaw that should be caught at compile-time, but it's not a big real-world problem, as returning null by accident instead of an option is a pretty rare bug.

The much more common bug (you didn't realize no return value was a case), the Option is a good counter to.

No, it's not a perfect solution, but it's not useless either.

<comment><USER49> i understand, and agree. i would personally, though, avoid adding it, and add attributes for the same purpose instead. just as the article suggests... it achieves the same without introducing a new class, thus also remaining backwards compatible.

</comment></comment></comment></comment></comment></comment></comment><comment><USER52> Implementing a monad like structure without a monadic for loop syntax sugar tends to confuse people. It's hard to picture writing most operations as map or flatmap.

</comment><comment><USER53> I love Haskell, but the existence of a bottom type throws all run time guarantees out the window.

        import Control.Monad
        ex1 = Just 1 :: Maybe Int
        ex2 = undefined :: Maybe Int
        inc = liftM (+1)
        main = do
          putStrLn . show $ inc ex1
          putStrLn . show $ inc ex2

Yes, you should never use `undefined`. Now replace `undefined` with `null` and it becomes apparent that Maybe and Optional have exactly the same amount of power.

<comment><USER54> > Yes, you should never use `undefined`. Now replace `undefined` with `null` > and it becomes apparent that Maybe and Optional have exactly the same amount > of power.

Null is encouraged and pervasive in Java, undefined is sometimes used as a placeholder and could be forgotten. You can't say that Maybe and Optional have the same amount of power because of this.

</comment></comment><comment><USER55> It's not a get out of jail free card no, but it's value isn't in preventing null pointers. The value of Optional is in providing intent.

You also get map, filter, flatMap, orElse, orElseGet, ifPresent. These are all great ways of making your code more functional, and do more with less.

I don't think annotations are the answer either, as you can't always rely on static analysis to prevent errors, a lot will still appear at runtime.

<comment><USER56> It does provide some type-level information, but if you're already writing documentation, the benefits are marginal. Add to that the fact that it really pollutes your interfaces, I would argue that it is almost always better to just pass a null and force people to check it, or read the documented guarantees.

Basically, just assume _every_ Java type is wrapped in Optional implicitly. But by adding Optional (and using it in standard libraries) it's often a matter dealing with code that interfaces between the two styles -- another problem that didn't exist without Optional.

And even if you think Optional is worth the small gains, it's still a sad mimic of the Option types implemented in other languages.

</comment></comment><comment><USER57> Would be handy if I could filter out all medium.com entries from the front page for me. Never read anything mildly researched or balanced there...

</comment><comment><USER58> This remind me of a old say:

"What is worse than not given anything to somebody that need it? Give to him something broken".

</comment><comment><USER59> Static analysis is great, but excessive annotations are not fun.

In my (admittedly limited) experience, people omit them, forget to update them, and then rely on the analyser to magically catch everything.

Sure, library solutions like Optional can always be misused, but there's no silver bullet to negligence.

</comment><comment><USER60> I really wished C# would support Nullable for reference types too. This + the new traversal operator (?. ) would be a great combo to get rid of NullReferenceExceptions.

To me Optional<T> without pattern matching seems crap.

</comment><comment><USER61> I have the same feeling about boost's optional. It's a bandage on a wooden leg.

<comment><USER62> But is it really? Maybe I'm missing the point but it is a nice way to express that a function may or may not calculate something, no? At least it seems way better than returning bare pointers or pasing an argument by reference+returning bool, or returning a unique_ptr, or ...

<comment><USER61> If you come from ML or Haskell and start using boost or Java's option, you actually feel ripped off.

Some people claim it's a sort of documentation denoting 'intent', but I don't want documentation. I don't want options to infect the whole codebase, I just want to pattern match once and extract the value, and never have to check again for None or null.

The problem in Java is the type system has references. X static use_it(X x){ ....}

really has a signature something like this: use_it : X ref -> X ref

no little library is going to fix that.</comment></comment></comment>


The Future Is Not Retro - <AUTHOR> https://pedestrianobservations.com/2019/09/08/the-future-is-not-retro/ <comment><USER2> We recently moved to a large-ish (but not huge) city and since I would be working downtown we looked at becoming urbanites (easy commute, can get rid of one of our cars, proximity to restaurants, shopping, things to do, etc.).

Then we discovered that urban accommodations for a family of 5 do not exist at _any_ price (and small 3bdr apartments can be had but are hard to find and extremely expensive). So, into the suburbs we went. The only people that seem to live in/around downtown here are either young singles (with good jobs, given the costs) or homeless.

Maybe when the kids move out and I'm close to retirement, but then I'd rather live in a shack on/near a beach somewhere, so nah...

<comment><USER3> I lived in the downtown of a major metro for close to two decades. Many of my neighbors vowed to raise urban street smart kids but when the children actually came plans changed. They'd quickly discover their current condo wasn't large enough, so they'd upgrade to something larger. Then transition to a townhouse and eventually a detached single family home, though often inside the city limits. Once they hit school age, things split between those who could afford private school and those who made convoluted excuses as to why the nearby inner city school wasn't appropriate for their child and then move somewhere else. Most often to the suburbs but sometimes to wealthier part of town. I moved away before any of the children became teenagers but it would be interesting to check in and see how things evolve once that happens.

<comment><USER4> > a detached single family home, though often inside the city limits

Wow, to even have that as a viable upgrade path.

I don't even live on the coast and in my metro, with the local range for a middling middle-class income, having a detached house within the city limits is an absolute pipe dream.

<comment><USER5> It is weird how a house in Minneapolis has ended up costing more than a comparable house in the Jacksonville, despite the latter having twice the population, being in the tropics, and located on the coast.

<comment><USER6> Jacksonville is a weird case, because the city limits include a freakishly large area compared to almost every other large city in the US: Jacksonville's city limits span ~875 square miles, vs. ~58 square miles for Minneapolis (and another 56 square miles of St. Paul). Jacksonville essentially includes a huge chunk of its suburbs within the city limits. If you drew an 875 square mile region around the MSP area, you'd find houses that were comparable in cost to the ones you're referencing in Jacksonville.

</comment></comment></comment></comment></comment><comment><USER7> Alon's continued insistence on super spiky housing with a focus on towers remains something I can't get behind.

The East Village is mostly 3-5 story mixed use apartment buildings. It has a population density of 82000 people per square mile.

If we could get Queens and Brooklyn up to that, we could literally double the population of the city.

We know what happens when NY gets big tower housing - it turns into the Upper West Side, Midtown West or FiDi all of which are miserable places to walk through.

It's not just NY. I spent a few months living in São Paulo (Pinheiros and Jardin's) which does exactly what Alon suggests - big towers near subway stations that are spaced far apart often with awkward tiny buildings next to them and fall off in density a kilometer or so away. Also miserable.

What the spiky housing near trains theory fails to address is that ultimately housing is for people to have lives. And there is a scale at which life is comfortable - it's like the East Village, like Miraflores in Lima, like Ximending in Taipei.

If we reduce the problem to people per square meter and transit carrying capacity problem we can theoretically make space for people but I'm not so sure they'll want to live in them.

It is really hard for me to believe that it would be better to push past the 5-7 story mark instead of just trying to spread the 5-7 story housing zoning wider.

If I haven't convinced you yet, consider this - if you brought the greater NY area to the density of the East Village it could fit over 370 million people or roughly the entire population of the United States.

So yeah, no towers please.

<comment><USER8> Why can't we simply say, "what are the greatest places to live densely" and just copy-paste design elements?

The Netherlands is one of the most dense regions in the world. But it doesn't feel like it -- at all. It is human-scale.

We don't have to sacrifice our humanity or quality of life. There is plenty of room.

<comment><USER9> Are people in the Netherlands similar to people in the United States? In the US you will primarily get a neighbor that is watching football, shouting swear words and always accompanied with the smell of budweiser as you pass them in the halls. You will always know when they are home... And if you don't get that guy it will be the screaming couple.

<comment><USER10> I think the problem perhaps is that in house-owning countries, the apartments are usually cheaply built, or cheaply converted, so leak sound like sieves, because everybody who has any money wants to live in a suburb. In apartment- living countries, they put earth between the floors, and the walls are pretty heavy duty. So you don't really have that much noise pollution.

</comment></comment></comment></comment><comment><USER11> As it relates to the US, this post had interesting ideas regarding urban development, and no grasp at all of suburban development.

While urban lifestyles are becoming more fashionable in the US, growth is higher in the suburbs[1]. Whether this is because suburbs are the only option for people moving to new cities (as urban cores become "full"), or because Americans (including millennials) are much more comfortable with suburban lifestyles than they are given credit for is up for debate. But to speak as if a sharp turn towards public transit based cityscapes is America's fait accompli betrays a serious lack of understanding of the country and it's people as they currently are.

[1][https://www.brookings.edu/blog/the-avenue/2019/05/24/big- cit...](https://www.brookings.edu/blog/the-avenue/2019/05/24/big-city-growth- stalls-further-as-the-suburbs-make-a-comeback/)

<comment><USER12> Indeed.

There is also this statement:

> It's not even an imposition. It's opportunity. People can live in high- > quality housing with access to extensive social as well as job networks

Here's the author is saying that "high-quality" housing and social network is supposedly stronger in urban areas. With regards to housing quality, I think the urban/suburban quality is highly debatable. In terms of social network as well, I think this is probably most true in the context of "professional network". Many people move to more suburban or rural areas precisely because of feelings of alienation and lack of personal connection traditionally associated with large urban areas. This has been remarked on by social observers for well over a century.

The most ironic thing about this whole post though is that it gives no credence to how the "future" predicted by the '90s kind of won: The Internet has made many professional and communication opportunities available to people wherever they may live. While we might not live in that IBM commercial version of an anonymized future where "The Internet does not care if you are X", we do live in a world where the internet has disseminated many of the traditional benefits of cities (and "civilization") to wherever a person may live. Knowledge, education, communication, art, work: all of these are much easier to obtain outside of cities now, and that has massively factored into why our current "future" has allowed that demographic shift into the suburbs to continue.

<comment><USER13> >Knowledge, education, communication, art, work: all of these are much easier to obtain outside of cities now, and that has massively factored into why our current "future" has allowed that demographic shift into the suburbs to continue.

This is really underselling the simple fact that our federal dollars still heavily subsidize suburban development at the expense of urban amenities and development patterns. Most of the rapidly growing cities haven't actually built any expansions of transit capacity or coverage since they hit their growth spurts over the past few decades, and the housing supply hasn't kept up either. If it's functionally illegal to build urban capacity you're not going to get urban development. It's a much simpler story than grandiose tales about how the internet obviates the need for human interaction.

<comment><USER12> > This is really underselling the simple fact that our federal dollars still > heavily subsidize suburban development at the expense of urban amenities and > development patterns.

This is simply not true. Secondly, the restrictions around urban development are self-imposed at either the State or Local level. SF, NYC, Chicago, etc. have zoning and development restrictions that Houston, Atlanta, Austin do not.

Astute observers may determine for themselves why that is, but this is not a federal or subsidy issue. (Just how much has the CA never-to-be-completed train cost again?...)

<comment><USER14> Honest question: Have you lived in Austin?

Because there's no way it's going to survive the influx of people it's seeing, in part because it faces the exact same urban development crisis that other cities are facing and making the exact same mistakes. For every person that points to Houston or Austin as being exemplary examples, I wonder if they have actually tried living there. This is before we even start talking about the dire nature of trying to walk anywhere in these cities.

<comment><USER12> Honest answer:

I have lived in Austin for 10 years off-and-on (I had a startup where I had to drive 6 hours to a different State every 2 weeks for 3 years). I have lived there permanently for 7 years.

I have also lived in Houston, 2 other cities in Texas (including Midland), 6 other states in the U.S., and was not born or raised in the United States.

For the last 7 years, I have also worked for companies where the tech headquarters were either in NY or SF.

</comment></comment></comment></comment></comment></comment><comment><USER15> I don't feel this article has a very strong point or that it offers strong arguments towards why this non-retro future is unavoidable and / or better.

> "The status anxieties of Basil Fawlty types who either can't or won't adapt > to a world that has little use for their prejudices are not a serious public > concern."

This is exactly what Urban Planning is concerned with. If Urban Planning ignores a subset of people as they are not a serious public concern (hint: they are), is it really building a future for people? Or a future designed to optimize moving cargo (people?) around...

<comment><USER16> Furthermore, it seems like a "strawman" argument. Where exactly are people arguing that the future of urban settlement must be exactly the same as it was pre-auto?

</comment></comment><comment><USER17> The title of the article should be "I do not want the future to be retro" or, more honestly: "I do not want the future to be traditional."

Given the authors biography, frequent relocation amongst expensive, elite international cities, this is not surprising. The fact that the author ended up settling in Paris, however, is very funny.

</comment><comment><USER18> Having lived and worked in several highrises, I'll say that density advocates (which includes me, mostly) almost always glaze over vertical commute time and annoyance. Elevators and steps are a huge pain in the ass any time you're carrying anything more than a messenger bag/handbag and a travel mug. And there always seem to be way more doorways involved, somehow, with doors that don't really want to be opened or stay open long enough to allow real-world transit.

<comment><USER19> Now try it with a stroller and multiple crying children.

<comment><USER18> Yes, I can only imagine!

</comment></comment></comment><comment><USER20> > Already, people lead full lives in big global cities like New York and > London without any of the trappings of what passed for normality in the > middle of the 20th century, like a detached house with a yard and no racial > minorities or working-class people within sight. The rest will adapt to this > reality, just as early 20th century urbanites adapted to the reality of > suburbanization a generation later.

What patronising guff. Some people love city living, a lot can't stand it. You may be happy to live without a back yard and without your own space, that doesn't mean that we all will, nor does it mean that many of those already in cities aren't already compromising.

Yes, let's build train networks. No, let's not pretend that means everyone will be happy to live in a box ten floors up, or that this is somehow inevitable.

<comment><USER21> Not really an accurate picture of the big global cities in the middle of the 20th Century, either. If anything, the working-class density has declined in core areas of New York and London, hasn't it?

<comment><USER22> Well, by and large, people in the US at least who could afford to were _leaving_ city cores in the latter half of the 20th century. And, even before that, densities were down from their peaks as cities moved away from tenement housing etc.

</comment></comment></comment><comment><USER23> Solving population problems with density + transit isn't exactly non-retro. Building trains and subways has been a thing for longer than interstate highway connected suburbs.

It's historically rare for people to accept a reduction in convenience, or quality of life. Even then it's only a reduction as a trade off for other improvements.

If we are talking about future mass transit, I'd expect it to look more like a larger version of Uber pool. Where a destination is entered into a smartphone, and transit mode selection is handled in the background. Something along the lines of smart buses combined with micro mobility.

The future of transit appears to be headed towards the smartphones and e-bikes, not the train station.

<comment><USER24> That future cannot work. In dense areas there are too many people trying to get around and it leads to congestion just like individual cars do. Only mass transit can solve the problem. In less dense areas the wait for the car is too long as so you may as well have your own.

<comment><USER25> How are buses not mass transit?

<comment><USER26> They are, but for much lower passenger volumes than trains or subways.

A bus rapid-transit line with all the bells-and-whistles like grade-separation (don't share any roads with cars), elevated platforms at every station for faster boarding, etc. can't handle more than about 3k passengers per hour[1]. A standard bus-line without that extra infrastructure, much less.

A subway line can handle 30k passengers per hour. You could build ten times as many bus lines on parallel roads, but it's probably going to cost more than the subway line and you are going to run out of space when you consider locations that have a subway station every quarter to half mile. Fitting ten bus lines in that space would be one every 150 feet or so.

[1] [https://www.liveabout.com/passenger-capacity-of- transit-2798...](https://www.liveabout.com/passenger-capacity-of- transit-2798765)

<comment><USER24> The context here is app based transit. A fix route bus stuck in traffic can handle 30x as many passengers as the same bus running an app based route. Add in the other features you name and the bus can get 10x more than the bus in transit. Then you can go to a train (subway or elevated) and get another 10x over that!.

Conclusion: app based transit isn't useful if you need to move masses. (Apps can be useful if there are a few rare trips that the otherwise good local system cannot handle)

</comment></comment></comment></comment></comment><comment><USER27> The trouble with Alon is that he starts with the conviction that we should build more fancy trains, and then works backwards comes up with policy arguments so that makes sense.

</comment><comment><USER28> Given the huge spike in interest in outdoor recreation [1,2] we've seen in the US, I have a hard time believing that the future of tourism is urban. Even as someone who thinks decarbonizing should focus more on public transit than electric cars, outdoor recreation is one area where I think electric cars make sense. I also think it's not a crazy idea to build public transit to popular outdoor areas. Ski areas in Colorado and popular national parks have huge high-season traffic jams that would be helped immensely by having public transit. Rail is nice if the traffic warrants it, but busses are great too.

[1]: [https://www.nps.gov/aboutus/visitation- numbers.htm](https://www.nps.gov/aboutus/visitation-numbers.htm) . [2]: [https://www.statista.com/statistics/191240/participants- in-h...](https://www.statista.com/statistics/191240/participants-in-hiking-in- the-us-since-2006/)

<comment><USER29> Passenger rail is barely economical for routes that are used year-round. Like it barely works in the NY-DC corridor, and not at all for SF-LA. It seems unlikely that it'd make sense for something as seasonal as a ski area.

<comment> barry-cotter Do the interstates make a profit? Municipal roads in New York? The economic reason to improve transportation is that reduced travel time leads to greater communication and commerce which increases growth. This applies as well to subsidizing rail as to subsidizing automobile use and rail is vastly safer per passenger mile.

<comment><USER29> Neither interstates nor rail make profits. But they are funded for with some consideration of ROI. The government shouldn't (and mostly doesn't) build interstates that are used only a few weeks a year.

If the government has money to spend on rail, it should put it where it'll serve the most passenger-miles/year.

</comment></comment></comment></comment><comment><USER30> I hope the future is more distributed teams and therefore more remote jobs, so people can get good jobs wi5thout having to move to a big city or its suburbs.

</comment><comment><USER31> I was following up until "They'd have uniform missing middle built form in most of the US and UK", at which point I threw an ERR_CANNOT_PARSE.

<comment><USER25> I believe it's

uniform(missing-middle(built form))

built form: function, shape and configuration of buildings as well as their relationship to streets and open spaces.

missing middle: built forms between high-rise buildings and single detached homes which promote walkable urban living and fit into the character of many residential neighbourhoods, which "have gone 'missing' from many of our cities in the last 60 to 70 years."

</comment></comment><comment><USER32> Is this group really any significant amount of people? In my experience most people realize that progress and change are inevitable, the question is only how.

"One faction of urbanists that I've sometimes found myself clashing with is people who assume that a greener, less auto-centric future will look something like the traditional small towns of the past."

<comment><USER6> Strong Towns has gained a decent following, and their core arguments[1] are pretty compelling, although their founder has the tendency to express half- baked theories about monetary policy that I think undermine his credibility somewhat.

[1] [https://www.strongtowns.org/newcomers](https://www.strongtowns.org/newcomers)

<comment><USER33> What are the monetary theories?

</comment></comment></comment><comment><USER34> National parks becoming less crowded seems especially unlikely. It's not that hard to rent a car. Hopefully electric cars will become more easily available?

</comment><comment><USER35> How do we feel about places like brooklyn and queens -- which are essentially urban in nature, but technically auxillary/suburban cities?

</comment><comment><USER36> > _The theme of the future is that, just as the Industrial Revolution involved > urbanization and rural depopulation, urban development patterns this century > involve growth in the big metro areas and decline elsewhere and in > traditional small towns. This is fine. The status anxieties of Basil Fawlty > types who either can't or won't adapt to a world that has little use for > their prejudices are not a serious public concern._

The world will go in a trajectory based on its current dynamics and the factors at play, not the author's ideologies. And it can develop new prejudices, compared to which Basil Fawlty types might seem inoccent and quaint if not preferable (much like the current era, with Trump et al, seems more frightening to the starry eyed days 90s).

In fact, if climate issues worsen, and the trade wars and splintering get worse, the future might do away with the whole "urbanization" concepts as peddled by the author.

So I wouldn't so so smug as to think some provincial echo-bubbly thinking is on right side of history...</comment>


Wikileaks promises release 7x bigger than Iraq War Logs, asks for donations - <AUTHOR> http://www.itworld.com/internet/128431/wikileaks-promises-release-7-times-bigger-iraq-war-logs <comment><USER2> One of the most disappointing things about Wikileaks is that the release of documents about the U.S. torturing people and the war going badly hasn't had any adverse affect on the support for the war. It's proof that people just don't care. It's depressing.

The need by governments to keep everything secret is a bit irrational. People don't care.

<comment><USER3> The main thing about the Iraq War Logs was that there was nothing particularly new or surprising or shocking. Details about incidents, but nothing war critics didn't already assume had happened many times.

When someone says "We've got horrible things to reveal", your imagination fills in the blanks, extrapolating from what we've already found out to even more horrible extremes.

But then what Wikileaks revealed didn't live up to that. It was pretty much more of the same things we already knew.

It's no wonder the reaction was subdued. It doesn't mean people don't care, it just means we're too burnt out to work up a rage about the sorts of things we already knew were happening.

<comment><USER4> Do you seriously believe the whole "the leak is very serious, but at the same time trivial"-story? It's a classic defense mechanism or tactic, depending on who you ask, in crisis management. I don't know any good English sources for this off the top of my head, but I it's called "trivialization", "minimization" or "disavowal". You can also google "crisis communication", "crisis management" or "image restoration" and you'll probably find something interesting like <http://www.ou.edu/deptcomm/dodjcc/groups/98A1/Benoit.htm>

<comment><USER3> "Do you seriously believe the whole "the leak is very serious, but at the same time trivial"-story"

All I know is that nobody looked through the leaked material and found something beyond what we already knew about.

</comment></comment></comment></comment><comment><USER5> ... In October the group released a package of almost 400,000 documents called the Iraq War Logs in coordination with major commercial media organisations.

7 x 400,000 = 2.8m documents?

You don't change people's minds by releasing 2.8 million pages of documentation, you change it by repeating your slogan over and over and over.

<comment><USER6> > _You don't change people's minds by releasing 2.8 million pages of > documentation, you change it by repeating your slogan over and over and > over._

Welcome to my quotes file. Do you want a name on that in case I use it sometime?

<comment><USER5> My handle's fine, I'm just summarizing Edward Bernay's ideas from Propaganda. <http://en.wikipedia.org/wiki/Propaganda_(book)>

</comment></comment></comment><comment><USER7> I can pick up that the intent of the poster of this was to imply that this promise was simply to gain donation money. While I don't know overly much about how such issues are typically handled in these communities, I'd far rather donate to Wikileaks's "secret docs coming over, keep us strong" then Wikipedia's "look at me, I'm Jimbo Wales".

</comment><comment><USER8> What's the significance of this release being seven times larger?

</comment><comment><USER9> I am extremely suspicious of wikileaks and its motivation. For example, they believe that WMD were found in Iraq. I won't be surprised if we find out in 15 years the whole thing was a DOD disinformation campaign.

</comment><comment><USER10> Hello kind Sers,

I am having the very good pleasure of speaking to you as Head of Wikileaks site for bad information on countries! Our previous Head has been removed for bad touching of females leaving Wikileaks with all his 2,800,000 seekrits but we cannot touch them!

All his seekrits are belong to you because our panel decided your are super most trustworthy of all on teh internets. All you must be doing to access your seekrits is by making donation first of small $10,000.00 and seekrits are in you hard drive!</comment>


The inside story of the iPhone X 'brain,' the A11 Bionic chip - <AUTHOR> http://mashable.com/2017/09/14/inside-apple-a11-bionic-and-silicon-team/#i6Q1ovKhkOqx <comment><USER2> It is striking that the iPhone with A11 is reportedly slightly more powerful than the current entry-level MacBook Pro. What more will it take for Apple to abandon Intel?</comment>


How to invite users to your app - <AUTHOR> https://medium.com/look-what-i-made/6089a7527566

<comment><USER2> Is it just me or are these blogs posts increasing more and more about name dropping?

Blah blah blah _artsnapz_ , blah _artsnapz_. 7 out of the 10 paragraphs had the word _artsnapz_ in it, and 1 out of 2 pictures had it.

It doesn't mean the advice is any less helpful or informative because of it, but reading it was like watching a commercial.

<comment><USER3> Because, you know, the entire point of the post is how they did it for their own product.

</comment></comment><comment><USER4> Is it really needed to have a 1226 x 515 px header image for a blog? I understand that some of the readers are using the latest "retina" Macbooks or 52-inch displays, but on my couple year old Macbook I can just see the top of the title when loading this page.

<comment><USER5> The body font is far too large as well.

</comment></comment><comment><USER6> Why not add a link as the 3rd step in addition to the invite code? Once the app's installed on a user's device you can pass through the code via a custom url scheme and avoid the possible drop off of having a user mis-enter their code. (you'd probably still want the code there in addition for users reading the email on a non iOS device)

<comment><USER7> You're already storing the code so why not just join the invite with the email and when the user logs in with an email flagged with an invite the user's state is already known?

</comment></comment><comment><USER8> I'm a big fan of delivering utility with less barriers. It probably is worse for your "active users" graph, but I always feel warmer and fuzzier about apps that I can engage with at my own pace.

So, in this case, that's an argument for attaching a reasonable-sized copy of the image to the email, or maybe a bit of embedded HTML with an obfuscated link or something that redirects if you want better tracking of what's going on / privacy knobs. Sure, some people will never register for an account because they'll get all their utility out of the emails. But on the other hand, all sorts of non-tech-focused family members will get to see the artwork, which is what your users want in the first place.

Glympse stands out in my recent memory as an app that did a great job of this.

</comment><comment><USER9> _Your children's profile photos and names (added during registration when the app is first installed) are included in the email. Isn't that cute? This immediately grabs the interest of the recipient.We think this makes it incredibly more likely that they will use the app._

Make the pictures bigger, and include a picture of some art. Also, don't think. Test. You can't guess your way to success. I see some issues with the ad you are currently sending, and testing would allow you to discover which (I'm not telling).

Also, this is a bit creepy. Once you start spamming the address book of your users, a lot of people will get pictures of the children. People who should not know them.

 _But when the recipient downloads the app, there is no way for artsnapz to know that they were invited by you. And this is where the Invite Code comes in - that's the alphanumeric code '123ABC' above. This code is generated uniquely to track each invitation you email out._

Can't you use an URL? The extra step typically reduces conversions.

I think this is a rather creepy product, and has many potential legal issues. Though the financials look good, given how this "company" can start selling overpriced printouts of the "art" to family members. Given 10,000 families. Three users per family (uncle, parent, grandparent). One printed art per month. Say $5 per printed art. That's a good amount of money for a simple social sharing app.

<comment><AUTHOR> (artsnapz founder here) Thanks for the feedback.

We don't (now or ever) plan on spamming the address book of our users.

We didn't show the entire flow, but the _user chooses_ who the email is going to - it comes up in the standard email dialog & they see it before they hit 'send'.

Try the flow, we don't think it is creepy at all but if you still do, shoot me an email with suggestions - email@example.com.

We are parents ourselves and are very sensitive to our children's privacy.

<comment><USER9> Are you A/B testing?

<comment><USER10> Depending on how many users this app has, A/B testing may not be possible. After working for a larger company that had lots of traffic, I started to take it for granted that I could run an experiment for a day and get an answer. When bootstrapping a new product, you just have to throw stuff at the wall based on intuition (and customer development) and hope something clicks so you can get that stream of traffic to A/B test with.

<comment><USER9> You can run very small tests, though. They will not scale, but will give some insight into what the current user base prefers.

<comment><USER10> That all depends if you can get statistical significance. The catch-22 here is that the only way to really get statistical significance without a lot of data is to have a clear winner, which would have probably jumped out as a better solution regardless of how rigorous your testing methodology is.

The worst thing you can do is run a test and jump to conclusions based upon limited data.

</comment></comment></comment></comment></comment></comment><comment><USER11> How about keeping track of the e-mail invites internally and as soon as an "invited e-mail" signs up, connect them with the users who ever sent an invite to that e-mail address? This way you don't need an access code (which can be very annoying, especially with mobile apps) or special links at all.

<comment><AUTHOR> Agreed - the only concern was that the user would sign up with a different email address than the one used to invite them with - in which case we wouldn't be able to link them together.

<comment><USER11> Well, how often do people sign up with a different e-mail address (especially the target group of parents and seniors)? You should measure this. Only solve it when it becomes a real problem.

I used to think like this as well, but you're basically falling in the trap of sacrificing usability for 95% while you solve the problem for the minority of 5%. Let's say your conversion rates drop by 25% because you have this hurdle. In an attempt to save the 5%, you're now at a net loss of 20%.

</comment></comment></comment><comment><USER12> Do other parents really care about seeing someone elses kids artwork. I can understand the keep/cataloging but the share?

I have a daughter and would love find an easy way to catalogue and keep her stuff, but other than to show her grandparents I have no need to share this with others nor do I care about what artwork other peoples kids are producing. Just my 2 cents.

</comment><comment><USER13> I would just save the email that the invite was sent to and save the invite against it. When the user signs up with that email I would know they have an invite waiting for them. There's a chance they might not use the same email address to sign up but this makes a much cleaner flow for the user.</comment>


Toshiba picks Bain Capital as preferred memory unit buyer - <AUTHOR> https://asia.nikkei.com/Business/Companies/Toshiba-picks-Bain-Capital-as-preferred-memory-unit-buyer <comment><USER2> I don't understand how the LBO companies like Bain still get away with it. I would have thought that the lenders would have gotten wise to it and stopped lending. After all they lose their principal in the almost inevitable bankruptcy.

<comment><USER3> Normally I would agree but in this case Dell and Apple appear to be the ultimate backers. I assume Bain was brought in to lead the financing aspects.

(Disclosure: I have zero inside knowledge of this deal)

<comment><USER4> Bain has been in the bidding process pretty much from the very start, while Apple and Dell only started getting mentioned as part of the consortium recently.

</comment></comment></comment><comment><USER5> This seemed in the pocket for Western Digital and Foxconn, I sure didn't expect them to choose Apple and Dell.

</comment><comment><USER6> Strip & Flip Bain loads their acquisitions up with debt to pay themselves off, and then runs for the hills. Like with Toys-R-Us now going bankrupt. Recall Mitt Romney was CEO of Bain. This is the GOP business modus operandi.

</comment><comment><USER7> Great news for all the other chip makers.

</comment><comment><USER8> "Think of it like The Toys-R-Us of DRAM"

I would have loved to be in that board meeting

<comment><USER9> Considering Toys-R-Us has gone bankrupt, perhaps not the most prosperous analogy either!

<comment><USER10> Pretty sure Bain Capital owns a controlling stake in Toys-R-Us

<comment><USER11> Loading down one of their companies with debt and then having it file for bankruptcy is a strategy they've used in the past. I wonder if that's what happened here.

<comment><USER12> > _Loading down one of their companies with debt and then having it file for > bankruptcy is a strategy they 've used in the past_

Bain will lose almost all its money in Toys 'R' Us. It has written its equity down to zero, didn't really take any dividends along the way, and itself holds the most junior tranches of debt.

<comment><USER13> Then other holdings of Bain sold "Toys R Us" goods and services and were perhaps sold after a good quarter?

</comment></comment></comment></comment></comment></comment><comment><USER14> I don't yet understand.

</comment><comment><USER15> Their MO: Buy it with debt. Charge the company for the debt and huge management fees which will be paid with more debt. Take it public after milking it to the max, so you can make even more money in the IPO.

Chapter 11 is next [http://www.businessinsider.com/brick-and-mortar-retail- priva...](http://www.businessinsider.com/brick-and-mortar-retail-private- equity-debt-financing-lbo-2017-8)

<comment><USER16> Out of all the businesses Bain Capital's private equity arm has listed in the link below, how many of them follow the template you've described?

[http://www.baincapitalprivateequity.com/investments](http://www.baincapitalprivateequity.com/investments)

<comment><USER17> To be fair, I think there would be some survivor bias. They aren't going to list all their failures

<comment><USER16> The original poster seems to be able to forecast how these companies are going to do. It's arguably harder to do that when a deal is just announced so I'd imagine it's easier with this list of businesses that they've already closed on.</comment></comment></comment></comment>


Interesante.com: Demo Day at Google And What The Slides Don't Tell You. - <AUTHOR> http://www.altamirano.org/startups-2/interesante-com-demo-day-at-google-and-what-the-slides-dont-tell-you/

<comment><AUTHOR> My presentation at Google for demo day. What do you think?</comment>


Amazon Is Coaching Cops on How to Obtain Surveillance Footage Without a Warrant - <AUTHOR> https://www.vice.com/en_us/article/43kga3/amazon-is-coaching-cops-on-how-to-obtain-surveillance-footage-without-a-warrant <comment><USER2> Well, to be clear: by asking people for permission.

I do agree that the way they seem to play both angles puts them in an awkward position, but I am unsure how to read this. Is it worse if people voluntarily share video versus being ordered to? Is it just a matter of ensuring there is good reason to obtain the footage or is voluntarily obtained footage worse from the perspective of personal rights?

Curious to hear the HN reactions since I frankly do not know enough about the implications to understand what's _really_ going on even after having read the article.

It kind of reads as "social media bad" near the end which is a seriously uncompelling point even if true in some senses.

<comment><USER3> In the last few years there has been a social undercurrent of "don't help the police under any circumstances" that often comes from the "give up all of your guns to the police" crowd. I don't really understand it honestly. I'm willing to bet the vast majority of these requests have to do with people breaking into houses, stealing from cars, stealing packages and causing other nuisances that it would be beneficial to prevent near your home.

<comment><USER4> Ask any lawyer and they will tell you not to talk to the police. This has been universal advice since long before the internet. Social media has made people more aware of their rights and potential pitfalls by making it easy to share videos like this one:

[https://www.youtube.com/watch?v=d-7o9xYp7eE&app=desktop](https://www.youtube.com/watch?v=d-7o9xYp7eE&app=desktop)</comment></comment></comment>


Ask HN: What are your favorite PG essays? - <AUTHOR>

When I first got introduced to the world of start ups somebody suggested that I read all of PG's essays. Curious to know which ones have influenced the hacker news community the most... <comment><USER2> Not exactly to answer your question, but here is a graph I came across a while ago of the mentions made of one PG essay by another:

<http://www.solipsys.co.uk/new/PaulGrahamEssays.html?HN>

Not sure exactly how valuable it is.

<comment><AUTHOR> Very interesting...thanks!

</comment></comment><comment><USER3> <http://www.paulgraham.com/love.html>

<http://www.paulgraham.com/start.html>

<http://www.paulgraham.com/wealth.html>

<http://www.paulgraham.com/hs.html></comment>


iOS App Life Cycle - <AUTHOR> http://juliageist.com/blog/ios-development-swift-3/app-life-cycle/ <comment><USER2> Is it just a copy/paste of the Apple documentation?

[https://developer.apple.com/library/content/documentation/iP...](https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/TheAppLifeCycle/TheAppLifeCycle.html)</comment>


Ask HN: Whats the most interesting and exciting field in computer science? - <AUTHOR> <comment><USER2> Pentesting and security fields that surround it can be pretty interesting. Also working in startups can be exciting with the right company culture and team.

However for the most part, the most 'interesting and exciting field' is very subjective and varies from person to person. I think you won't be able to get a definate answer on this because everyone thinks their field is the most interesting (and for good reason too - otherwise they shouldn't be in it!).

</comment><comment><USER3> I think, the most interesting field now is dependent types. Researches have achieved substantial progress in the last 10 years:

* Large mathematical theorems were proved in Coq (Feit Thompson Theorem)

* An optimizing C compiler with correctness proof was created ([http://compcert.inria.fr/](http://compcert.inria.fr/))

If this stuff gets to mainstream and I think, it will get there in 5-10 years, we will have unprecedently reliable and secure systems.

</comment><comment><USER4> Artificial intelligence, currently popular by machine learning. Lots of potential and undiscovered applications. Everyone will have their own opinion on this, however.

<comment><USER5> It certainly seems to be the case, though the interests seem to be too skewed towards it.

</comment></comment><comment><USER6> Deep Learning.

</comment><comment><USER7> There's a _lot_ of work to do in parallelism, especially figuring out methods to automatically optimized problems for parallel architectures.

<comment><USER8> I agree, but very little of this work seems exciting. While advances like hardware support for transactional memory and, hopefully, some unified memory support for CPU/GPU operations will have a tremendous impact on the ease with which programmers compute in parallel, I tend to hear fewer new ideas about what can be done with parallel computing.

<comment><USER7> Exciting is subjective. :-)

I don't disagree that there are fewer ideas, but that's because we need new ideas, including new architectures. Having spent quality time on a number of novel supercomputer architectures that seem to have been forgotten in the rush to turn GPUs into short vector SIMD-ish successors to Cray XMP/YMPs, I don't think we've looked at all the viable alternatives, at least not in a long time. For example, I'm clear on why memory-based vectors like the Cyber-205 faded at the time, but it's not clear the same limitations fundamentally still exist (especially with L2/L3 caches bigger than the 205 main store now). I think that's interesting...YMMV.</comment></comment></comment>


When you marry a geek, expect birthday presents like these - <AUTHOR> http://wowsig.com/2013/12/11/happy-birthday-aakanksha/

<comment><USER2> Really wierd but somewhat nice background.

</comment><comment><USER3> very cute :)</comment>


First Look at Scrivener for Linux - <AUTHOR> http://www.linux.com/learn/tutorials/416135-writers-rejoice-first-look-at-scrivener-for-linux <comment><USER2> I love this app. I've been using Scrivener since Keith was giving it away free when it was in early stages.

There's no other writing tool like it - I was originally using it for my Great American Novel, but it's become an invaluable tool for researching and preparing presentations lately.

What an unexpected pleasant surprise to see it on Linux!

</comment><comment><USER3> Oh wow, great news indeed. About a year ago I was looking for book-writing software, and Scrivener was far and away the best reviewed and regarded among writers. But alas, Mac-only, and I never really found anything great for Linux. This is terrific news!</comment>


Are People Getting Dumber? - <AUTHOR> http://www.nytimes.com/roomfordebate/2012/02/26/are-people-getting-dumber

<comment><USER2> My personal view on the topic isn't whether we're getting smarter or dumber overall its the mediums we're capable of expressing these traits through.

Throughout history the only people who were given face time on radio/tv (internet wasn't a thing) were people that had gone through various levels of screening. If an idiot interviewed on the news and said irrelevant or hateful things they were simply not aired. The radio was run by professionals with invited guests. Other examples exist too.

However, today we provide the means for anyone to create videos of themselves or write articles and be put on the same stage as anyone else. Often times we see the dumb antics of various people as "entertaining" and it becomes encouraged.

Without diving too much deeper I believe it is simply a case not of smarter/dumber but instead an argument of how visible they are. We've always had "dumb" people but only within the last two decades have we created a medium they are capable of expressing themselves through.

*Obviously just my $0.02. I'm an engineer, not a researcher of the social sciences.

<comment><USER3> Big Brother, Survivor, and other similar crap (e.g. The Jersey Shore) seem to contradict your idea, I think. I have not had a TV for some years now, and every time I actually get to watch some, I notice that it keeps getting dumber. Of course, you can still find interesting, thoughtful stuff, but it is becoming rarer and rarer.

I think that part of the problem is that being stupid is no longer seen (by society at large) as a bad thing. We're headed for the Idiocracy future...

<comment><USER2> I don't think they contradict my assumptions so much as hit it from a different angle.

Reality TV is sort of a more professional way of users creating their own content. The cameras/production and the like are still controlled operations but they're seeking out non-actor types who are willing to expose themselves for a chance at riches and fame. This leads more towards people who are inclined to take that sort of route instead of "earning" it through work. (Earn might be poor word choice here)

The other side of the coin to look at too is the type of people on those shows. It isn't a secret that they finely tune who is invited to participate and the show producers will obviously elect to cast people that are more "drama prone" or capable of providing that level of entertainment value.

Maybe if we take a step back and look at it from the meta level we could say that an indication of the general population "becoming more dumb" is the idea that we are willing to suck up this form of entertainment more and more. Is it a sign of being dumber when we more inclined to watching people generate meaningless drama, fight or expose themselves instead of intellectual stimulating programs?

<comment><USER3> > we could say that an indication of the general population "becoming more > dumb" is the idea that we are willing to suck up this form of entertainment > more and more.

That's precisely my point. The fact that the shows are dumb in and of themselves, is not the problem. The willingness to watch them, and by doing so celebrate their stupidity is.

</comment></comment></comment></comment><comment><USER4> I'd like to read about the topic, but various op-eds just lose my interest. I would like to read something that is more conclusive, evaluates what intelligence is, uses facts and real information, and explains perceptions.

<comment><USER5> Of course the problem is that people are too dumb nowadays to come up with all that :)

</comment></comment><comment><USER6> Psychologists actually have to recalibrate the scoring of IQ tests every few decades in order to keep the average at 100 -- and they need to do this because the scores are going up. I tried to get a psych friend of mine to explain this, because if you follow the implications it means that someone who scored an average IQ in the '20s would now be classified as mentally retarded, which strikes me as insane. But for whatever weight you want to give to this particular measure of intelligence, we're actually getting smarter.

</comment><comment><USER7> Is it possible to have a smart discussion about whether people are getting dumber in casual, 300-word increments? Perhaps the worst offender is the essay by Erin Jackson, a stand-up comedian, which is neither smart nor funny and relies on phoned-in anecdote and hand-wavy syllogism to prop up her conclusion that people are getting dumber. But even in the essays that extol a more methodical approach to the question, like Steven Pinker's piece, we're left with appeals to evidence that must be taken on faith because there's no room to include them.</comment>


And So You Code - <AUTHOR> http://www.youtube.com/watch?v=Eq3CuMDXaPs

<comment><USER2> Where can I get the original? I would DJ this out.</comment>


Why I signed ACTA - <AUTHOR> http://metinalista.si/why-i-signed-acta/ <comment><USER2> Important background detail: the author is the Slovenian ambassador to Japan. _not_ an (indirectly) elected politician. I think it is very courageous of her to write this, since traditionally ambassadors never publically reject their home country's domestic policy making.

I also like it because it debunks my image of ambassadors as conservative seniors who prefer signed letters, LPs, and fax machines.

<comment><USER3> Agreed, very courageous -- and very powerful.

</comment></comment><comment><USER4> It seems that actually no one is reading the original text. I did, and I did not find any censor, ISP reponsibility or surveillance points. I asked the German Pirate Party for clarification and citation, with no luck. Everything in there is already law in Europa. I therefore do not understand what the point of the protests is.

Please help me (with text citation from the official text):

[http://register.consilium.europa.eu/pdf/en/11/st12/st12196.e...](http://register.consilium.europa.eu/pdf/en/11/st12/st12196.en11.pdf)

<comment><USER5> I'll make it simpler for you. Even if that is correct, even if ACTA doesn't change the existing laws: _we want those laws reversed_.

They are not our laws. They were forced upon us by a combination of US government pressure and outright bribery. And they are now sending our people to prison and censoring our internet access for things we do not consider to be crimes.

The protest against ACTA is not so much a matter of "ACTA is evil", it's more a matter of "this corruption stops now".

We want our freedom an sovereignty back, not to have it signed away in some treaty, even if that treaty has been watered down to something merely symbolical with no immediate effect. It is patently obvious that they won't stop at ACTA in it's current form.

Sometimes that mere fact that you finally draw a line is more important than where exactly you draw it.

<comment><USER6> Also, if people are misinformed over ACTA, it's because the whole freaking negotiation was done in secret.

<comment><USER7> That's nonsense. First of all, even during the "secret" negotiations, the current drafts were routinely leaked and widely discussed.

Second, there was an official release of the draft text on April 21, 2010. An updated "near-final" draft (which was quite close to the April 21 draft) was released on October 6, 2010. The final draft was released on November 15, 2010.

All of those drafts are readily available on the Office of the United States Trade Representative site: [http://www.ustr.gov/trade-topics/intellectual- property/anti-...](http://www.ustr.gov/trade-topics/intellectual- property/anti-counterfeiting-trade-agreement-acta/previous-acta-texts)

The idea that people are misinformed because a document that has been officially and readily available for nearly two years (and unofficially available long before that) was at one time years ago secret is ridiculous.

<comment><USER8> Right, so we have to rely on leaks in the future to get visibility on how our rights are being stripped away, this is the democratic process our predecessors shed blood for?

Am reminded of this passage from HHGTTG.

 _"But Mr Dent, the plans have been available in the local planning office for the last nine months."_

 _"Oh yes, well as soon as I heard I went straight round to see them, yesterday afternoon. You hadn't exactly gone out of your way to call attention to them, had you? I mean, like actually telling anybody or anything."_

 _"But the plans were on display ..."_

 _"On display? I eventually had to go down to the cellar to find them."_

 _"That's the display department."_

 _"With a flashlight."_

 _"Ah, well the lights had probably gone."_

 _"So had the stairs."_

 _"But look, you found the notice didn't you?"_

 _"Yes," said Arthur, "yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'."_

<comment><USER9> heh that exact reference was done in discussions in a danish newspaper too :)

</comment></comment></comment></comment></comment></comment><comment><USER10> Can anyone who is more familiar with European politics give their impression of how successful these country-specific anti-ACTA protests are likely to be? I don't dare to hope that we'd actually manage to totally derail yet another of these bills, but my spirits would be bolstered if at least one leading European country failed to ratify it.

<comment><USER11> The protests in Poland are actually creating more of a storm than I ever expected them to. We will see what will come out of it, but at least the government is now _very_ aware that this is a controversial treaty that can't be signed just "because everyone else did".

Also, it seems that at least the prime minister and his aides simply did not realize how far-reaching and controversial ACTA is. They certainly do realize that now.

</comment></comment><comment><USER12> Just read it. Here's why I don't like it:

>> _"NOTING further that the proliferation of counterfeit and pirated goods, as well as of services that distribute infringing material, undermines legitimate trade and sustainable development of the world economy, causes significant financial losses for right holders and for legitimate businesses, and, in some cases, provides a source of revenue for organized crime and otherwise poses risks to the public;"_

It's based on a false premise backed at best by contentious statistics. Also, ironically, it's prohibition that provides organized crime the largest source of revenue.

>> _"In determining the amount of damages for infringement of intellectual property rights, a Party's judicial authorities shall have the authority to consider, inter alia, any legitimate measure of value the right holder submits,"_

The rights holders get to tell the judicial system what they think you should be charged. Thats like, if you stole a venti-mocha-latte, and starbucks got to decide what your punishment was.

>> _"at least for copyright, additional damages."_

And in the case of copyright, there will be 'additional damages'

>> _"Each Party shall further provide that its judicial authorities have the authority to order that materials and implements, the predominant use of which has been in the manufacture or creation of such infringing goods, be, without undue delay and without compensation of any sort, destroyed or disposed of outside the channels of commerce in such a manner as to minimize the risks of further infringements."_

They can destroy your computer.

>> _"A Party may provide for the remedies described in this Article to be carried out at the infringer's expense."_

You have to pay for everything.

>> _"its judicial authorities have the authority, upon a justified request of the right holder, to order the infringer or, in the alternative, the alleged infringer, to provide to the right holder or to the judicial authorities, at least for the purpose of collecting evidence, relevant information as provided for in its applicable laws and regulations that the infringer or alleged infringer possesses or controls"_

They're trying to take away your right to remain silent. (Which I realize isn't available in every country)

>> _"to prevent an infringement of any intellectual property right from occurring"_

They can stop you from entering or confiscate your computer if they think you might download a movie.

>> _"A Party may exclude from the application of this Section small quantities of goods of a non-commercial nature contained in travellers' personal luggage."_

This section should read "must exclude" theres no reason they should be searching small quantities of goods of a non-commercial nature.

>> _"where appropriate, a right holder may request its competent authorities to suspend the release of suspect goods."_

The movie studio can determine weather you get your computer back or not.

>> _"each Party shall provide penalties that include imprisonment as well as monetary fines sufficiently high to provide a deterrent to future acts of infringement"_

You are to be punished severely. This is not a fine like a ticket. This is jail time and/or severe fines. For downloading a song.

>> _"the authority to order an online service provider to disclose expeditiously to a right holder information sufficient to identify a subscriber whose account was allegedly used for infringement"_

They can order your ISP to give up your identifying information. Which may or may not even be relevant.

>> _"Each Party shall provide adequate legal protection and effective legal remedies against the circumvention of effective technological measures that are used by authors, performers or producers of phonograms in connection with the exercise of their rights in, and that restrict acts in respect of, their works, performances, and phonograms, which are not authorized by the authors"_

You can be punished for circumventing DRM, jail-breaking your iphone, or using a region free dvd player.

>> _"the offering to the public by marketing of a device or product, including computer programs, or a service, as a means of circumventing an effective technological measure"_

Jailbreaking software, dvd decryptors, video game backups.

>> _"to remove or alter any electronic rights management information;"_

You are not allowed to remove identifying information even from media you purchased. Itunes wants to put your full name in a song you downloaded's meta- data? You have to leave it there.

>> _"Each Party shall endeavour to promote, where appropriate, the establishment and maintenance of formal or informal mechanisms, such as advisory groups, whereby its competent authorities may receive the views of right holders and other relevant stakeholders."_

Makes provisions for hearing from the IP rights holders, but nothing about hearing from citizens or public rights groups.

>> _"share information with the competent authorities of other Parties on border enforcement of intellectual property rights, including relevant information to better identify and target for inspection shipments suspected of containing infringing goods."_

They can start a world wide list of suspected infringers and keep permanent information about you available internationally.

>> _"The Parties hereby establish the ACTA Committee. Each Party shall be represented on the Committee."_

Doesn't say how the representatives will be chosen. Could easily be copyright lobbyists.

>> _"The consultations, including particular positions taken by consulting Parties, shall be kept confidential"_

They can keep their consultations between representatives out of the public record.

___________________________________

This bill's clear intent is to put copyright in front of human right. It's to get signing nations to agree that the wealth of IP holders is more important than the comfort and privacy of their own citizens.

It won't stop piracy, it won't create national wealth, it'll give organized crime more money, it will waste SHIT LOADS of public money and time in the process, and we'll all be a little more worse off.

</comment><comment><USER13> Putting aside the actual excuse given (I wasn't paying attention), the letter is extremely well written and worth reading. Makes me sympathize with some of the politicians who got hoodwinked into passing this "treaty" without understanding its implications.

Which is still no excuse for signing something you don't understand, but nonetheless, we're all human and imperfect sometimes.

</comment><comment><USER14> This seems to be a common tactic of the shady backers of the global censorship. They gain support for their dark laws by obscuring real intentions and fooling politicians into blindly supporting them. True, there are those who understand the real picture, and support nevertheless. But there are also those who are simply not responsible enough to understand clearly what they support. And they are exploited by the real culprits who fight against freedom. That's why they are so scared of publicity and push hard to pass this laws in secret. They know that public review will quickly reveal their evil intentions.

</comment><comment><USER15> So all I have to do is admit that I'm incompetent and everything will be OK?

<comment> guard-of-terra On the other hand, a massive chunk of world problems are rooted in people screwing up and then failing to acknowledge that fact and try to fix it, instead sticking to the faulty course and doing much more harm. Here we see a person eagerly accepting their failure, which is a good thing.

</comment></comment><comment><USER16> This was written by Slovenian ambassador to Japan. There's quite strong opposition in Slovenia against ACTA - even the Musicians's guild is against it.

There are going to be street protests in Slovenia against ACTA on Saturday.

This can still be reversed - by EU Parliament not ratifying it and in turn giving other European countries an excuse not to ratify it.</comment>