Copying data is wasteful, mutating data is dangerous - <AUTHOR> https://pythonspeed.com/articles/minimizing-copying/ <comment><USER5> I'm not super familiar with interior mutablility, but I don't think this is the same "interior mutablility" as used in Rust.

Interior mutablility:

A, immutable, points to B.

B, immutable, points to C.

C, mutable, points to D.

D, immutable, points to E.

Even though A and B are immutable -- B points to C mutably, so you can modify its contents. Some "interior" part of A (and of B) is mutable. You can't change which C is pointed to by B (because B is immutable, or rather we only have an immutable reference to it), but it's open season on the contents of C.

What this article describes:

We have 2 operations.

We are passed in Array A.

We can either:

\- Apply both operations to A, modifying it even though the "owner" may not want this.

\- Copy before each operation (or as part of them), which leaves A untouched, but requires triple the memory usage.

\- Cooy before (or as part of) the first operation only. The second operation can be applied in-place on the copy. This leaves A untouched and only requires double the memory.

They're totally different concepts. I don't know what you'd call the second concept -- I think the important part is that A remains untouched, so... "Avoiding side effects while reducing memory usage", or "How to make performant pure functions" ?

<comment><USER5> I also see this as a bit of a premature optimization. The triple memory usage one may be significantly faster than the in-place one -- and the memory usage is temporary so unless you're in a constrained environment that's not a concern.

Avoiding unintentional or unexpected side effects is a good thing. Pure functions are great. Do whatever you can do keep your visualization helper thing pure and avoid bugs.

Then, once it works, if you have performance issues, do some profiling.

If the profiling shows this helper method as a hotspot, then it's worth optimizing.

At that point, you'd want to follow standard Python, numpy, and pandas optimization strategies -- which I'm not familiar with.

Aimless optimization like this is a waste of time. Good program structure (data is available when you need it without tonnes of calls), the right choice of data structures and algorithms (hashmap vs list), the right choice of underlying tools (Julia vs Python) and targeted optimization (profiling) are the ways to go.

<comment><USER6> The slowest thing CPUs do by far is access memory. I don't see any possibly way that, for the given example, using more memory would _ever_ be faster. At best 3*N all fits in cache and it's not as bad, but even then it's still at least one more cache miss which means it will still be slower even if it's not by much. Temporary memory is the worst type of memory. It's cache misses & pipeline stalls for no point.

"Premature optimization" is not an excuse to write obviously bad code. Fixing this simple thing now is much faster, and simpler, than digging a big hole, jumping in it, and then hoping you can find something to pull yourself back out later.

In the same way it's important to scatter about asserts and verify parameter arguments do in fact conform to the documented contract, it's also important to always keep an eye out for openly wasteful code.

<comment><USER7> > it's also important to always keep an eye out for openly wasteful code.

No, that's the point. It's really _not_. If your "openly wasteful code" does its job well and is readable and maintainable, it DOES NOT MATTER that it is "wasteful".

If, on the other hand, the wasteful code causes your program to execute in 60 minutes instead of 10 seconds every time you run it, then it does matter and you should optimize it.

Why is this such a difficult concept?

<comment><USER6> If you're trying to use Knuth's quote from 1974 as your justification for that concept then you've misunderstood his argument and should read the full thing, not the single phrase.

This article is not advocating premature optimization as Knuth was discussing nor does the article's advice result in the evil that Knuth was warning against.

If you have some other evidence or paper justifying why we can ignore obvious inefficiencies please provide a source. That's a rather radical claim to make, though, which may be why you find people struggle with the concept.

</comment></comment></comment></comment></comment><comment><USER8> As a game developer working in managed languages (aka Unity/C#) this problem is one of my biggest headaches. I was hoping the article would provide divine insight, unfortunately the recommend solution doesn't really solve the problem (as I see it).

Whilst 2n array alloc is better than 3n, both are creating short lived memory objects. Do that in a hot code path and suddenly you've got tremendous garbage pressure your garbage collector is going to choke on.

One can optimise this by calculating results into a cached array, but that creates opportunities for bugs (results of previous caches persisting). I would dearly love to see a solution that allows me to code in a functional style without sacrificing performance.

<comment><USER9> Arena style allocation helps. You still get the allocations, but GC is cheap. IMO both Java and the CLR are in desperate need of multiple heaps with separate GCs to solve these problems. One big heap simply doesn't scale well. Erlang is the only example I know of that does this right. I know that the golang GC is low-latency, but I'm not familiar with if it can sustain high allocation rates.

<comment><USER10> Nope.

Golang still uses one global heap; it just allows for stack based allocation in situations it can do it (avoiding putting stuff on the global heap), so copies _can_ be cheap re: GC.

<comment><USER11> The CLR also allows stack allocation, and many of the newer .NET Core libraries have been built with a focus on eliminating unnecessary allocations.

<comment><USER12> Some of the biggest of .NET Core's advances in stack allocation (and resulting performance boosts) likely won't make it into Unity until around the release of .NET 5, though. It should be interesting to see how Unity adapts when the tools show up.

</comment></comment></comment></comment></comment><comment><USER13> > But mutation is a cognitive burden: you need to think much harder about what > your code is doing.

One way to alleviate the problem is to use naming convention.

      normalize(a)       # mutates in place. note: no return value.
      b = normalized(a)  # no mutation. returns a new instance. note the adjective.

Python does this in the standard library

      a.sort()
      b = sorted(a)

<comment><USER14> I like how ruby way of declaration if a method does mutate object or not but a exclamation mark at end to tell it modifies the object

a = a.sort or a.sort!

<comment><USER15> I like the idea of adding an exclamation or some other mark to the individual parameters in the method declaration since a method might mutate some but not all parameters.

</comment></comment></comment><comment><USER16> I'm surprised no-one has mentioned Haskell's ST library yet. It hits this exact use-case, and comes with some pretty sweet safeguards from the type system.

[https://wiki.haskell.org/Monad/ST](https://wiki.haskell.org/Monad/ST)

It allows you mutate arrays and other stuff "on the inside" like this article suggests, but it's also able to wrap up the operation so it appears pure from the outside, so the caller doesn't have to guess or rely on naming conventions to figure out the mutability.

It's your choice on whether you want to do the copy on the way in ('thawing'), on the way out ('freezing'), or both, by using the 'in-place' variants of thaw and freeze.

<comment><USER17> Exactly. The only problem is that you need a language with a sufficiently powerful type system that can express both phantom and existential types.

<comment><USER18> > The only problem is that you need a language with a sufficiently powerful > type system

why is that a problem?

<comment><USER19> Because everyone and their grandma can whip up a quick Python script after a few days of practice, whereas learning Haskell is a much bigger investment?

</comment></comment></comment></comment><comment><USER20> This seems like a problem that would be suited for an optimizing compiler.

You could imagine some hypothetical language in which _all_ objects are immutable, as far as the programmer is concerned - however the compiler is allowed to reuse objects behind the scenes if there is provably no way that a side-effect could be introduced.

E.g., in such a language, the first variant would be the only legal form to write the normalizing function:

      low = array1.min()
      high = array1.max()
      array2 = array1 - <USER4>
      array3 = array2 / (high - low)
      return array3

However, this could be safely turned into the following during compilation:

      low = array1.min()
      high = array1.max()
      array2 = array1 - <USER4>
      array2 /= (high - low)
      return array2

... because array2 is not visible outside the function and therefore could not cause side-effects.

<comment><USER21> it is theoretically possible that a library like numpy or pandas could do this directly. That is, if you take each of these transformation operations and store them, but not actually run them until needed, that is, when someone accesses the individual array values, you only need to make one copy and there is no impact on the programmer to have to worry about this.

I was doing something similar for SQLAlchemy recently. SQLAlchemy is all about capturing Python operators and operands into data structures that represent intent which can be invoked later.

edit: here is a demonstration: [https://gist.github.com/zzzeek/caa4a7ed94f326fbbc031acecb9d7...](https://gist.github.com/zzzeek/caa4a7ed94f326fbbc031acecb9d7a44)

edit edit: it is actually possible with numpy by using the Dask library: [https://dask.org/](https://dask.org/)

<comment><USER22> The problem with the library doing this is you end up with the same issue as in Haskell: you accumulate thunks and both memory use and location of CPU hotspots becomes much harder to predict and troubleshoot.

<comment><USER21> so...turn off the "thunking" feature while you are debugging.

<comment><USER23> That won't help when you're debugging the performance implications of thunking.

<comment><USER21> compare memory / callcounts / time spent with thunking turned on vs. off would give a good idea of it.

i can say for my side of things thunking is a _super_ huge performance gain as it allows for quick gathering of expression intent and then the computation side on the other side of a cache.

</comment></comment></comment></comment></comment></comment><comment><USER24> This is rather dumb. The only reason there is an intermediate array in the original copy-based code is because the normalization is badly written. After you obtain max and min, normalization is a single map() function, not two.

As for the overall problem: always choose immutability and then make it faster by first taking advantage of optimization patterns that immutability allows you to use safely. In a case like this, doing the normalization lazily is what springs to mind.

If memory allocation and de-allocation is an issue, use more explicit memory management. Though by experience it is rarely the actual problem. There's basically no chance that it is an issue here, Python interpreters aren't stupid enough to give back memory to the OS immediately after a variable falls out of scope.

<comment><USER25> Do you have any links to some examples or help on how to do this exactly?

Reason being that in our group we have a ton of normalization code that looks _exactly_ like the 'bad' example from this post. As we use relatively large datasets (4D MRI images), memory is a bit scarce...

<comment><USER26> Pytorch has a built in normalize function: [https://pytorch.org/docs/master/_modules/torchvision/transfo...](https://pytorch.org/docs/master/_modules/torchvision/transforms/functional.html#normalize) It just subtracts the mean and divides by standard deviation, both in place.

</comment></comment></comment><comment><USER27> How I would summarize the article is that mutation should be confined to internal objects that have not been published yet or are temporaries that are thrown away.

Theoretically, you can make every API mutate data. If the user didn't want to mutate data, they can explicitly make a copy first. Whereas if there only exists an immutable API to return new objects, then it's hard or impossible to get the benefits of mutating in place.

As far as I know, only Rust, C++, and C give support at the type-checking level to denote which functions will modify the interior of their arguments. This way, you can distinguish behaviors easily - for example in Rust:

      impl Vector {
          // The method reads this current vector and returns a new one.
          pub fn normalize(&self) -> Vector { ... }

          // The method reads and modifies this current vector in place.
          pub fn normalize(&mut self) { ... }
      }

The article gave this subtly flawed example in Python:

      def normalize_in_place(array: numpy.ndarray):
          low = array.min()
          high = array.max()
          array -= low
          array /= high - <USER4>

      def visualize(array: numpy.ndarray):
          normalize_in_place(array)
          plot_graph(array)

      data = generate_data()
      if DEBUG_MODE:
          visualize(data)
      do_something(data)

In Rust, it would be a type error because visualize() takes a reference but normalize_in_place() takes a mutable reference:

      fn normalize_in_place(array: &mut numpy::ndarray) {
          let low = array.min();
          let high = array.max();
          array -= low;
          array /= high - low;
      }

      fn visualize(array: &numpy::ndarray) {
          normalize_in_place(array);  // ERROR
          plot_graph(array);
      }

      let data: numpy::ndarray = generate_data();
      if DEBUG_MODE {
        visualize(&data);
      }
      do_something(&data);

<comment><USER22> > As far as I know, only Rust, C++, and C give support at the type-checking > level to denote which functions will modify the interior of their arguments.

1\. C and C++ allow casting away constness, which may or may not be UB depending how the parameter is defined

2\. Swift also provides this ability to an extent: _struct_ parameters have to be flagged `inout` to be mutable

I'm sure there are others.

<comment><USER28> Rust can throw away constness in unsafe blocks, which carries the same caveat emptor that const_cast carries.

<comment><USER29> Only in certain circumstances, though.

</comment></comment></comment></comment><comment><USER30> That is how strings work in Delphi/Pascal.

All strings have a reference count. When you change a string, and the ref count is not one, it is copied before the change. If the ref count is one, it is not copied

</comment><comment><USER31> Seems like "both libraries make copies of the data, which means you're using even more RAM." is a assumption (that copy data leads to more RAM usage) and I'm guessing the libraries (haven't used them myself, nor python, so not sure how feasible this is) can be implemented like a persistent data structure ([https://en.wikipedia.org/wiki/Persistent_data_structure](https://en.wikipedia.org/wiki/Persistent_data_structure)) and therefore get both immutability (which leads to less bugs, no mutability) and not that high RAM usage. Clojure is a famous example of something that implements persistent data structures.

<comment><USER13> > can be implemented like a persistent data structure

you don't get much benefit from persistent structures if every element of an array is modified, like in the examples in the post.

<comment><USER32> If the data structure has a reference count of one, you can safely mutate the data structure instead. Many persistent immutable data structure libraries use this as an additional optimization.

</comment></comment></comment><comment><USER33> There are also data structures such as zippers which are immutable but minimize the amount of data you need to copy, at the cost of potentially using more space overall. Zippers are cool because they can be generalized to many different types of data structures as long as they can be expressed as algebraic data types.

</comment><comment><USER34> If your language allows mutation:

1\. Immutable first. 2\. Data structures should use partial copying [1]. 3\. Data structures should be lazy by default. 4\. When you've profiled a bottleneck, and identified memory allocation and copying as the bottleneck culprit, then use a mutable data structure internal to the operation (copy your lazy immutable data structure once into the mutable one, taking only the portion of your lazy structure that you need, operate on the mutable structure in place, then return an immutable, lazy copy of that structure out of your operation.

This will isolate the need for mutation reasoning to performance critical parts of your application/library, and let you still reason about the rest of your program with referential integrity, while avoiding performance bottlenecks.

Never use a mutable structure in a mutable reference at the same time. You don't need both.

1\. [https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...](https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.amazon.com/Purely- Functional-Structures-Chris-Okasaki- ebook/dp/B00AKE1V04&ved=2ahUKEwjb9YfGk_nmAhXULc0KHYaRAw0QFjAXegQIBBAH&usg=AOvVaw2G1ZviAl6c7fVGecHERvwq)

</comment><comment><USER35> In other languages this is less of an issue, because function signatures can include information about whether the argument can be modified or not. For example, in C++:

        // Definitely doesn't modify 'array', because 'array' is copied.
        vector<int> Normalize(vector<int> array);
        // Almost certainly doesn't modify 'array'.
        vector<int> Normalize(const vector<int>& array);
        // Probably *does* modify 'array' (otherwise author would have used
        // const reference instead of pointer.)
        void Normalize(vector<int>* array);

In Python every function uses the 3rd approach, so you have to signal to the user in some other way whether the argument will be modified or not. In Ruby and some other languages the convention is to append "!" to the function name, but in Python most people seem to just mention it in the docstring.

<comment><USER36> There is some convention in Python - for example `reverse` and `sort` are mutating, whereas `reversed` and `sorted` are not.

However, I don't know if there is a good reason why the mutating versions are methods and the non-mutating ones are standalone functions.

</comment></comment><comment><USER37> Why does this blog post have a recaptcha?

In addition, I just finished reading the Rust book last night, and I don't believe this is what interior mutability is (at least as used in Rust).

<comment><USER38> I see no recaptcha.

<comment><USER37> Here's a screenshot: [https://i.imgur.com/a/84Hb9Jq.png](https://i.imgur.com/a/84Hb9Jq.png)

</comment></comment></comment><comment><USER13> > To reduce memory usage, you can use in-place operations like +=

btw, I think it's a design flaw in python that `a += b` is not always equivalent to `a = a + b`.

<comment><USER39> As someone who has never used Python seriously I have to ask... why not?

<comment><USER13> Because I once learned that `a += b` is just a shortcut for `a = a + b`, just a syntax sugar. Now I have to constantly remind myself that it's not the case in python.

edit: I might have misunderstood your question. If you meant "why it's not equivalent" please see the falkaer's answer.

<comment><USER40> They aren't equivalent in C++ either.

<comment><USER13> My C++ is a bit rusty. Does it manifest itself in the standard library as well? The problem with python (in my view) is that this behaviour is implemented in the standard library and therefor propagates to the 3rd-party libraries by convention.

<comment><USER41> > Does it manifest itself in the standard library as well?

Yes. For example for std::string `a = a + b;` will (at least notionally) create a temporary string and then use the assignment operator. `a += b;` will not do this.

</comment></comment></comment></comment></comment></comment><comment><USER42> The problem and solution are broadly fine, but having done a bit of performance critical work, I usually dislike when a function allocates without a) me asking, b) me having the option to tell it not to.

I like passing in pre-allocated containers to house the results of my computation. That way I have not only predictable memory consumption, but I can also avoid costly allocation (and de-allocation) in tight loops. Having worked with Go a bit, there were times when I used this (like passing in byte slices to readers), but oftentimes you couldn't just tell a function not to allocate (which it did for safety), because you and only you knew it'd be safe to modify the structure in place.

The bottom line is that people should not be "always copy/always use pure functions" or "always use mutable structures, because performance!!!", but be aware of what the upsides and downsides of each are.

</comment><comment><USER43> Better pattern is to follow the style of Numpy or Pandas and other libs (that OP also mentioned, but then failed to apply it in his own examples), _letting the caller /user of your functions choose, if/when they want better performance, to opt-in for in-place modification_, like have either:

        def normalize(data, inplace=False):
            if not inplace:
                data = data.copy()
            ...

or:

        def normalize(data, out=None):
            if out is None:
                out = data.copy()
            ...

_Please, do follow this pattern for any libraries you release, having value- semantics-by-default to prevent shooting yourself in the foot + opt-in in- place mutation option for better memory performance is the right thing, and it 's quite easy too with Python, Numpy and Pandas!_

<comment><USER44> Julia has this as well, functions with a '!' at the end mutate the data, functions without make a copy.

So you have the functions 'filter' and 'filter!', 'sort' and 'sort!' etc.

</comment></comment><comment><USER45> Scala's collections API also uses some mutable internal data structures locally (and temporarily) within some functions that present a pure API.

List[T] is one of the classic immutable data structures, and a List[T] cannot have its contents modified. But within the prependAll method, it can create a mutable List factory (ListBuffer) to do its work building the new list that it will return.

So, if you follow this (contrived) example in your IDE, calling this:

      val f = List(4, 5, 6).prependedAll[Int](Array(1, 2, 3))

will take you inside StrictOptimizedSeqOps, which does this:

      override def prependedAll[B >: A](prefix: IterableOnce[B]): CC[B] = {
        val b = iterableFactory.newBuilder[B]
        b ++= prefix
        b ++= this
        b.result()
      }

The mutable data structure doesn't escape the function, so to the caller it remains referentially transparent.

</comment><comment><USER46> There's a 3rd option - keeping a modifications' log and applying them all destructively on just 1 temporary copy only when the result is needed.

        A = normalized(X*b - M*N*k); //creates a pipeline
        A.calculate(); //calculates all the stages destructively on the new copy

</comment><comment><USER47> I think one way numerical computation APIs can offer optimizations of this sort is to expose a chaining API.

For eg:

chain(my_large_array).op1().op2().op3().result()

Using this, the chain() start could copy the input data once, but thereafter do a series of in place mutations in op1, op2 and op3 to improve performance.

Do numpy APIs provide such facilities?

<comment><USER48> Rust iterators combine like that if the operations are per-element (iter + map + collect).

For optimizing complex access patterns you'd need a language like Halide.

</comment></comment><comment><USER49> Or just use an immutable language or library and you'll have the best of both worlds. Unless you're writing an operating system. But the example was given in Python so I guess it's perfectly fine.

The idea of immutable data structure is just like strings in Java or other modern languages: it seems like a reference type but works like a value/primitive type. It maintains a constant pool that all "foo"s in the same virtual machine points to the same reference. For immutable data structures, they work in the same way.

On top of that, there's more underlying sharing mechanism. For List(1,2,3), it's actually might sharing the same List(1,2) with List(1,2,4) to minimize the waste.

</comment><comment><USER50> This seems more like "defensive copying" than "interior mutability" to me.

Ideally you'd have a compiler that could perform optimizing magic to detect when the copy isn't needed, but that's not going to happen in CPython.

</comment><comment><USER51> This is why you want a two-tiered API: High level and low level. The high level API chooses a static trade-off in performance, size, etc for the 80% case, and the low level API gives more explicit control over what's going on.

In this case, you could create the function normalized() for the 80% case, and normalize_in_place() for users who need to optimize this path (choosing to take on the extra responsibilities that come with it).

</comment><comment><USER52> I think Futhark approaches this with uniqueness types. A bit strange (maybe that's just me?) but it works well with arrays.

Also it compiles to Python nicely.

</comment><comment><USER53> What about lazy evaluation though? That could get the functions 2*A memory down to just A while still keeping the time O(n)¹

Of course, maybe the author just chose to limit this blog post to this one solution, but it wouldn't have hurt to at least mention some further optimizations :)

¹ And some O(1) data like the min and max values of the Array

</comment><comment><USER54> Specifically on the point about Pandas, last time I checked the inplace flag did not save any memory. Under the hood, it creates a temporary copy which is copied back to the original dataframe, and then the temporary gets removed next garbage collection cycle. If that is no longer the case I would love to know about it though!

</comment><comment><USER55> Matlab gives you these semantics by default. IMO, it's a big reason why it has been so successful with non-CS programmers. Mutation is often more intuitive, but as long as you break your code into functions, you automatically limit the scope of mutability bugs that can occur.

</comment><comment><USER56> Isn't this solved perfectly with an affine or linear type-aware optimizing compiler? Where all data is immutable unless the types prove to the compiler that there are no mutation conflicts. I believe Rust implements this and Idris 2 does so as well with quantitative type theory.

<comment><USER22> Rust would be very different and the problem wouldn't exist in the first place, because the function would signal its behaviour and intent through taking the parameter by reference, mutable reference or value.

<comment><USER56> That's what I meant

</comment></comment></comment><comment><USER57> This is just a straightforward memory optimisation; nothing to do with interior mutability.

</comment><comment><USER58> Another option is to have a data structure that you have frozen and then you unfroze it for the hot path and then freeze it again when you exit it.

</comment><comment><USER59> Does the Numba JIT do this? This definitely seems like a compiler optimization that I want to mechanically run on my code

</comment><comment><USER60> Don't functional data structures basically "diff" data, which is a reasonable compromise?

</comment><comment><USER61> I have been mutating data for decades without any unexpected behavior gremlins.

</comment><comment><USER62> Another option is for the language's runtime to use copy-on-write (COW):

[https://en.wikipedia.org/wiki/Copy-on- write](https://en.wikipedia.org/wiki/Copy-on-write)

So basically every buffer can be made immutable and then only copied when written to, using something like refcounts and diff trees to internally track mutations from an immutable parent buffer. Languages like Clojure due this to manage state. I believe the Redux also does this internally, although I've only studied it and haven't had a chance to use it professionally.

In practice, this looks like a language where everything is value-based instead of reference-based.

So like, in C# where you pass objects by reference, a COW language passes everything by const value. Then an imperative language statically analyzes the code to detect mutation (my own theory is that this can never be accomplished with 100% certainty, at least not with a simple implementation). So basically buffers act like Git instead of byte arrays, creating a new snapshot with every mutation.

Or functional languages can disallow mutation altogether, or reduce the code into its most minimal representation and handle mutation at special breaks in execution (like monads). I'm grossly oversimplifying all of this and probably using the wrong terminology, but am more than 50% confident that I can derive what I'm talking about, so will just go with it hah.

I think that the complex imperative implementation I'm talking about is probably Rust. The simple functional implementation would look like a pure immutable Lisp running within the Actor model, handling state only through IO, and dropping monads altogether. The catch being that complex functional code might have so many breaks in execution that it would practically be happening on every single line and begin to look like an imperative language with all its flaws. This is the primary reason why I shy away from impure functional languages like Haskell, because I don't think they have solved this core issue of mutation clearly enough (not to mention, I think functional language syntax is generally write-only and not readable by others or yourself in 6 months hahah). As far as I'm concerned, this is still an open problem.

In another life, I want to make an imperative language that's primarily immutable, that uses higher order functions (or better yet, statically analyzes code for side effects and converts foreach loops into higher order functions automagically), and transpiles to a purely immutable Lisp. It would be associative array-based and look like Javascript. The idea being that we could write code in the human-readable imperative style and let the computer distill it down to its pure functional equivalent.

<comment><USER63> > not to mention, I think functional language syntax is generally write-only > and not readable by others or yourself in 6 months

This is rather tangential, and sorry to hijack your message to get on my soapbox, but I and many others who program in Haskell and a dynamic language (Python in my case) find that Haskell code we've written is _far_ easier to come back to than code we've written in the dynamic language.

<comment><USER62> Ya I tend to agree actually, but in the real world I keep getting scolded for being too "functional". I think that it might come down to the easy != simple argument, which the whole CS industry is still grappling with in other areas as well.

</comment></comment></comment><comment><USER64> Copy on write?</comment>


A new, more user-friendly language for programming supercomputers - <AUTHOR> https://engineering.stanford.edu/magazine/article/new-more-user-friendly-language-programming-supercomputers <comment><USER2> '"We wanted to create a programming environment that doesn't require every researcher to be a computer scientist,"'

For the more than 60 years it has existed, most Fortran programmers have not been computer scientists. I wish the article had explained why the designers of the language are starting from scratch rather than building on Fortran, in particular Fortran 2008+, which introduced coarrays for parallel programming.

</comment><comment><USER3> If anyone is interested in these (Regent and Legion) check out: [https://legion.stanford.edu/](https://legion.stanford.edu/)

Overview is at: [https://legion.stanford.edu/overview/](https://legion.stanford.edu/overview/)</comment>


IPad Applications brainstorming - <AUTHOR>

You've decided to develop a cool new iPad application that will make your fortune. What is it? <comment><AUTHOR> Off the top of my head:

Something for writers along <http://www.hogbaysoftware.com/products/writeroom> lines.

Portable blogging.

Trip planning - going on a family holiday? Store your tickets, where you're going, what's good to see there, the photos you've taken (once apple add a camera), get recommendations on things to do, alerts about like minded holidaymakers to spend time with, reminders to get appropriate jabs...

</comment><comment><AUTHOR> Posted seeing as the other RFS discussion seems to be more about the meaning of the iPad and whether it's a good idea. Hoping we can get a more focused discussion on how to extract cash.

</comment><comment><USER2> Add an RFID scanning peripheral, and this baby is ready for warehouse inventory management.

<comment><USER3> Except it's not, because the iPad is a consumer device. It's not built to withstand a warehouse / factory environment.

Take a look at this ... <http://www.youtube.com/watch?v=W_xBLxJyQsM>

Think an iPad could withstand that? Symbol scanners already have this solved - rugged hardware + RFID module if you want it.

(And not many are doing RFID at the moment due to the insane cost)</comment></comment>


Ionit: Render configuration files from Jinja templates at boot time - <AUTHOR> https://github.com/bdrung/ionit <comment><AUTHOR> It is already available as debian package: [https://packages.debian.org/buster/ionit](https://packages.debian.org/buster/ionit)</comment>


Big Think Interview With Tony Hsieh - <AUTHOR> http://bigthink.com/ideas/20671?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+bigthink/expert_ideas+(Big+Think+Expert+Ideas)

<comment><USER2> I find it troubling that even a company like Zappos doesn't consider alternatives to laying people off. Maybe everyone could have taken an 8% pay cut instead.</comment>


Gödel Without (Too Many) Tears – new version, posting a short chapter a day - <AUTHOR> https://www.logicmatters.net/2020/09/01/godel-without-tears-slowly-1/ <comment><USER2> This is a good presentation of the traditional take on the work of [Gödel 1931].

References can be found here: [https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3603021](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3603021)

However, [Gödel 1931] _fails_ to prove inferential undecidability of foundations of computer science because it violates restrictions on orders of propositions that were introduced in [Russell 1908] to block inconsistencies in foundations. The crucial issue with the proof in [Gödel 1931] is that the Gödel number of a proposition does not capture its order. In strongly-typed theories, the Diagonal Lemma [Gödel 1931] fails to construct the proposition _I'mUnprovable_ such that _I'mUnprovable_ ⇔⊬ _I'mUnprovable_.

If the proposition _I'mUnprovable_ existed, it would be a monster in the sense of [Lakatos 1976] because adding it results in inconsistency in foundations of computer science that have the following fundamental principle: ByTheoremUse {⊢∀[Proposition Ψ] (⊢Ψ)⇒Ψ} [Euclid approximately 300 BC]

        Proof of a contradiction in foundations of computer science: First prove *I'mUnprovable* using proof by contradictions as follows:
            In order to obtain a contradiction, hypothesize ¬*I'mUnprovable*.
            Therefore, ⊢*I'mUnprovable* (using *I'mUnprovable*⇔⊬*I'mUnprovable*).
            Consequently, *I'mUnprovable* using ByTheoremUse, which is a contradiction.
        Using proof by contradiction, ⊢*I'mUnprovable* meaning *I'mUnprovable* by ByTheoremUse.
        However, ¬*I'mUnprovable* using  *I'mUnprovable*⇔⊬I'mUnprovable, which is a contradiction in foundations.

Also, adding _I'mUnprovable_ results in inconsistency in foundations of computer science that have the following fundamental principle: ByAdequacy {⊢∀[Proposition Ψ] (⊢Ψ)⇒⊢⊢Ψ}:

        Proof of a contradiction in foundations of computer science: First prove *I'mUnprovable* using proof by contradictions as follows:
            In order to obtain a contradiction, hypothesize ¬*I'mUnprovable*.
            Therefore ⊢*I'mUnprovable* (using *I'mUnprovable*⇔⊬*I'mUnprovable*).
            Consequently, ⊢⊢*I'mUnprovable*using ByAdequacy.
            However, ⊢¬*I'mUnprovable*(using I'mUnprovable ⇔⊬I'mUnprovable), which is a contradiction.
        Using proof by contradiction, ⊢*I'mUnprovable* meaning ⊢⊢*I'mUnprovable*using ByAdequacy.
        However, ⊢¬*I'mUnprovable* (using *I'mUnprovable*⇔⊬*I'mUnprovable*), which is a contradiction in foundations.

Existence of relevant fixed points is extremely important because they enable recursive definitions. Without restrictions, fixed points can be used to construct monsters. For example, without orders on propositions, the "self- referential" proposition _I'mFalse_ (such that _I'mFalse_ ⇔¬ _I'mFalse_ ) could be constructed as the fixed point of the mapping Ψ↦¬Ψ (↦ notation from [Bourbaki 1939–2016]). Since Ψ is a propositional variable in the mapping, ¬Ψ has order one greater than the order of Ψ. Thus because of orders on propositions, there is no paradoxical fixed point _I'mFalse_ for the mapping Ψ↦¬Ψ.

Gottlob Frege made major advances in notations in foundations [Frege 1884]. In Frege's system, Russell developed a paradox using the mapping NotSelfApplicable[x]⇔¬x[x], which when applied with NotSelfApplicable for x has the following self-contradictory consequence: NotSelfApplicable[NotSelfApplicable]⇔¬NotSelfApplicable[NotSelfApplicable]. With orders on predicates, construction of the monster NotSelfApplicable is blocked because NotSelfApplicable[NotSelfApplicable] is not a well-formed proposition because if NotSelfApplicable is a predicate of order α substituted for x then ¬x[x] has order α+1 since x is a predicate variable of order α meaning that NotSelfApplicable is not a predicate of order α. In this way, Russell continued the logicism programme [Frege 1884] to base the foundations solely on the untyped predicate calculus writing that abstractions "are merely symbolic or linguistic conveniences, not genuine objects" [Russell and Whitehead 1927].

Attaching orders to abstractions enabled blocking the construction of monster such a NotSelfApplicable. However, attaching orders to all abstractions made Russell's system unsuitable for standard mathematical practice, such as analysis [Russell in Appendix B of Principia Mathematica 2nd Edition, Church 1976, Quine 1966] because every abstraction is an abbreviation for a proposition with an order. Making types (where only propositional types have orders) explicit is a better solution for Computer Science.</comment>


The iPad is not a car - <AUTHOR> http://blog.benward.me/post/497645689 <comment><USER2> Why does his discussion of automatic transmissions sound like he hasn't actually driven a car with an automatic in twenty years or so? His comments, compared to my actual experience of driving various automatics over the past decade, feel like someone who says cars must not be so great because of how you have to turn the hand crank on the front to start the engine, not realizing that this is a solved problem now.

<comment><USER3> I think the comparison between automatic transmissions from 20 years ago and modern ones is a good way to see why the iPad will work well for most people. Old automatic transmissions did have problems when you wanted to accelerate quickly and at certain speeds they couldn't decide what gear to be in so they'd keep shifting. Modern transmissions are so good that only a few people notice that things aren't quite how they would like them to be and there are a lot of people who can't drive a car with a manual transmission. The iPad takes away a lot of control, but it makes choices that most people will like. Not everyone wants or needs to have more control.

<comment><USER2> _did have problems when you wanted to accelerate quickly and at certain speeds they couldn't decide what gear to be in_

I've noticed the first one on pretty much every automatic I've ever driven, but mostly that's a "doctor, it hurts when I do this" sort of thing. If I turn from a residential side street (20mph) onto a larger four-lane road (45-50mph) and pound the gas pedal into the floor to speed up, then yeah, it's going to be jerky. If instead I just gently give it more gas and let it speed up a bit more gradually, it's nice and smooth. So the solution to that appears to be simply "don't drive like you're on a racetrack".

Indecisive gears are a problem I haven't seen on at least the last couple cars I've owned (both Ford); they've been just fine at picking a good gear for the speed and sticking with it.

</comment></comment></comment><comment><USER4> This is a good article, but clearly written by someone who is a manual transmission fanboy. I drive a manual, too, but I recently switched from an automatic and I know why automatics are more popular - they're easier to use, and you don't have to learn or think as much as with a manual, to get where you're going. I would say his conclusion is wrong - that the iPad/PC distinction is actually very similar to the automatic/manual distinction.

<comment><USER5> What in the world is a manual transmission fanboy? Are you just trying to rattle the cage, here?

<comment><USER6> It made more sense when the furor over automatics was new. Now no one cares, which is kinda the point.

</comment></comment></comment><comment><AUTHOR> Disappointing but unsurprising that people are focusing on the car details in an article about the irrelevancy of car analogies.

The meat is at the end:

 _I'm not going to say that Apple are right to lock others out of defining how touch computing is going to work, but they can, and I think their belief is that they can do it better if they don't have fight off contradictory ideas in the meantime._

<comment><USER7> "The meat is at the end."

Preceded by a lot of car talk, which you focus on. Put the meat up front. Besides, the meat of the article is about the irrelevancy of car analogies, but if people don't agree, they will discuss that portion. You can't discuss it and not expect people to respond.

</comment></comment><comment><USER8> You drive cars with a manual transmission. You AIM cars with an automatic transmission.

Think about it this way, there are some people out there who have no good reason to really drive a car. They'd rather just aim. Perhaps it's the same with the IPad. Some people don't want to know how everything works, or how it's done. So long as it works and they can accomplish their goals, they'll be happy.

</comment><comment><USER9> Computers and cars have different usages in different situations. The iPad is clearly not developed for development work or tinkering, it is a step above a smart phone and intended to be used in a similar way. Just like the Toyota Camry is clearly not built for racing, it is made for transportation and intended to be used for people that will never open the hood.

Both have a target audience that really doesn't need to be confused with extra bells and whistles that are going to add complexity for the average person that does not want to use the device for more than the intended purpose.

I really don't understand why everyone is angry that the iPad takes another step away from tradition of computing to help make computers more accessible to a broader audience, and requires less knowledge of how the computer works (which many people would be happy about, maybe not you or I, but people that do not have careers or hobbies tinkering with computers)

<comment><USER10> >I really don't understand why everyone is angry that the iPad takes another step away from tradition of computing to help make computers more accessible to a broader audience,...

Because we think it means that an even _larger_ _%_ of users of our software will understand even _less_ about "how computers work"™ and their expectations will be based on even _shittier_ "apps" => will be even more unrealistic & difficult to "work around".

</comment></comment><comment><USER11> Sure the iPad is a car.

But it only travels to Apple-approved destinations.

<comment><USER12> Wrong!

No, only Apple approved OEMs are allowed to make spare parts and provider service.

You can make your parts or use "unapproved" parts by jail breaking, doing which you break your warranty.

</comment></comment><comment><USER13> The car analogy is cute, but the "afterward" at the end of the article is the most relevant part. I think he's dead on with his analysis of what Apple is doing in that regard. I give Apple points for taking a bold step, although in my opinion it's in the wrong direction. But we do need more boldness in the realm of computer user interfaces, the standard mac/win/*nix interface (and let's face it they're really all the same), is a relic of the last millennium and needs a reboot.

</comment><comment><USER14> That was a fun rant about cars, but did the author have anything to say about the iPad?

</comment><comment><USER15> I knew the car analogy would make some folks defensive because it's so apt.</comment>


Why Being an Australian Startup Sucks - <AUTHOR> http://blog.gleam.io/australia/ <comment><USER4> This is the second article in a week where I've read the complaint that banks don't loan money to Aussie startups. However I think you'll find banks don't lend money to startups pretty much anywhere in the world. Banks aren't the place to secure funding for high risk ventures - VCs, Angels and crowdsourcing are.

I think the bigger issue in Australia is that the VCs here have a terrible investment track record, so banks and other investors are less likely to given _them_ funds to invest.

There are a couple of things that could change here to improve things. The first is that it's currently easier to bet $15K on Melbourne FC to win the AFL Grand Final than to invest the same amount of money in an Aussie startup. That's completely crazy - it makes becoming an Angel in Australia a burden.

The second potential is Australia's vast pool of super funds (401Ks in US terminology). They can't invest in either startups or VCs because it's "too risky". However they should be allowed to invest a portion of the fund - <USER2> 10%. That would make a huge difference to the funding available to startups here.

<comment><USER5> Given that Australians have the highest per capita gambling losses _in the world_ ([http://www.economist.com/blogs/graphicdetail/2014/02/daily-c...](http://www.economist.com/blogs/graphicdetail/2014/02/daily- chart-0)), I'm surprised that the regulations around funding startups are so risk averse. Also ironic that angel investing from super funds is deemed "too risky" but using your super to get an _interest only_ mortgage to buy an "investment" property with negative cash flow is just fine. Clearly there are powerful established interests at work...

EDIT: Given that Melbourne are currently 15th on the AFL ladder anyone would be crazy to bet on them winning on the Grand Final. Port Adelaide, on the other hand... ;)

</comment></comment><comment><USER6> A huge benefit in Australia (at least, for now), is the healthcare and education system. You can come out of university with no overheads and free healthcare. All you need is rent, pizza and hosting costs and you can build a startup. I honestly think a lot of the barriers in the article are overstated. The biggest problem is the lack of economy of scale here, there is just not much of a market to test your ideas in locally and a lot of regulation and legal barriers (eg: asinine copyright laws, no fair use, etc.) that make it much harder.

<comment><USER7> > _All you need is rent, pizza_

Not even that, you can go on the Dole [1] and get over $1k a month to spend however you want.

[1] Australia has benefits if you don't have a job. They never expire. [http://www.humanservices.gov.au/customer/services/centrelink...](http://www.humanservices.gov.au/customer/services/centrelink/newstart- allowance)

And you get paid to go to University too.

<comment><USER8> Well, that's about to change with the new budget it seems.

<comment><USER7> If Abbott isn't kicked out soon, Australia is going to become a much, much worse place. (for many reasons, not just the above) I had tears in my eyes when my parents told me of his plans to charge University and healthcare fees.

I used to be proud to be Australian, I hope I can be in the future.

<comment><USER9> The change of healthcare fees was a $7 co-payment on going to the doctor and less of a tax benefit for higher income earners.

Australia still has universal health cover.

<comment><USER6> Almost. There are in fact people in the world who do not have $7 and who once could walk into a clinic but will have to essentially beg their doctor to give them service for free. It's a tiny crack but if you want to apply the word "universal" a tiny crack is as good as a chasm.

</comment></comment></comment></comment></comment></comment><comment><USER10> This won't be a popular comment amongst my fellow Australians, but some of these points in the post don't ring true to me.

Being a startup in Australia is hard, but being a startup is hard anywhere. I think there is a certain mentality amongst Australian startups that the US is the land of milk and honey for startups and Australia sucks. There is a certain element of truth in that, but its not as bad as some of the posts to HN make it out to be.

First Tax Breaks: The R&D tax incentive is amazing ([http://www.ausindustry.gov.au/programs/innovation-rd/RD- TaxI...](http://www.ausindustry.gov.au/programs/innovation-rd/RD- TaxIncentive/Pages/default.aspx)). We have recovered around 40% of our seed funding as a tax refund from the ATO. If you do something slightly innovative and can prove that you do some testing, you qualify. This tax incentive has directly allowed us to put on another developer.

GST: Yup GST is a pain but at least its uniformly applied to the whole country. The US you have to apply it on a state by state basis (depending on where you are located etc and the nature of the good/service you provide). Other countries have a consumption tax. Seriously meeting your tax obligations is a requirement of doing business anywhere, its not that hard to do: if(countryCode == "AU") {//apply GST... }.

Venture Capital: Nothing can compare to Silicon Valley in terms of money available for the tech space, but at the same time Australian VCs are often happy with a 10x exit as opposed to pushing you to be either a $1 billion company or go bust. The choice of where you raise will be a personal choice more likely influenced about who you know. Remember the higher the valuation you get, the bigger the exit you need to make.

Australia being expensive: Sure you pay a little bit more for your mac book pro, but the guy using it will be seriously cheaper than someone in the valley. You think Australia is competitive for developers who could get a cushy contracting rate. Try competing with facebook, google etc for the top talent.

Internet: Ok the current government hates in the NBN, it sucks, I love fast broadband as much as the next person, but unless your startup is about delivering high bandwidth content to Australians who cares? Your servers are going to be sitting on AWS in US_EAST anyway.

Mind you having said that I do agree with some points. Employee Share Schemes are a pain in the arse and getting a good payment provider is tough. Seriously spend the cash to get a Delaware C-Corp and open a US bank account... this will make your life so much easier. Even Braintree Australia is a shadow of using Braintree from the US.

<comment><USER7> I'm an Australian that left 8 years ago, and have been living and working in the US and Canada ever since.

I agree with you 100%.

Australia being expensive: Anyone that says that needs to wake up to how lucky they are to live in "the lucky country". After living a few years in America (and to a lesser extent Canada) I'm more than happy to pay extra for "stuff", given life is so, so much better. Heath Care, Education, decent infrastructure, paid vacation, sick and maternity leave, just to name a few. Also consider someone working minimum wage in the US ($7.25/hr) has to work ~206 hours to get that $1500USD MacBookPro. In Australia, someone on minimum wage ($16.37/hr) has to work ~113 hours for the same $1849AUD MacBookPro. Obviously minimum wage earners are not buying MacBookPros, but given that wages scale similarly, you see living/working Australia is actually better than living/working in the US.

Timezones: Wait, it's a complaint that the world has timezones now? Give me a break!

Foreign Investors want a global vision: The OP of the article is upset that _foreign_ investors want to get a boat-load of money back on their money by reaching as many customers as possible? Does this person not understand how investors think?

In short, cry me a river. I challenge any Australian who disagrees with me to go and live in the US for a few years, then see what you have to complain about.

<comment><USER11> The timezone issue is significant if you need to offer realtime support as part of your product, and the majority of your clients aren't near where you are.

<comment><USER12> West and East coast in the US are 3 hours apart (timezone - ta-da!). Same issue with timezones applies even in the USA. Realtime support is hard to do anywhere in the world. What happens when the operator is overloaded with too many requests. There are many ways to make this scale and work even across timezones and languages.

<comment><USER11> Come on guys, give me some credit. We're having problems with internal processes right now because our offices are split between Melbourne and San Francisco, and there's only 2 hours in the regular working day of overlap. Being a couple of hours out is nothing compared to being almost the entire working day out.

The more your support has to do shift work, the harder it is to get and vet support, train them properly, and the more expensive they are to pay. The more they're awake during normal sleeping hours, the lower the quality of support - and I say this having spent two years doing support for in-timezone sleep medicine equipment. The article also states other problems with response lag and low efficiency, which is what happens if you can't adjust your work day (and if you do, then you're out of sync with local services).

The kind of condescending 'get over it' comment from grecy is _utterly_ beside the point - regardless of whether you deal with it well or not, out-of- timezone sync support _is_ more difficult to do, and that is something worth mentioning in a list of hurdles an Australian startup might face.

<comment><USER7> > _The kind of condescending 'get over it' comment from grecy is utterly > beside the point - regardless of whether you deal with it well or not, out- > of-timezone sync support is more difficult to do, and that is something > worth mentioning in a list of hurdles an Australian startup might face._

You know, Australians are _very_ well known internationally being being complaining so-and-sos.

I can't believe a thinking person would actually complain that Australia is in vastly different time zone. Next you'll be complaining it's too hot, then that it's to sparsely populated (oh, you already are). It never ends with you, does it?

<comment><USER11> ?

You're doing some pretty massive projection there. I said that the timezone increases support costs if you're not where your market is, and it's worth putting on a list of hurdles for startups. I didn't _complain_ about the timezone, just mentioned that it's not the trivial issue you painted it as. It's also winter here in Melbourne, where it gets cold enough that I've heard both Scots and Canadians bitch about how stupidly cold it is here (because we don't insulate our buildings properly), and when summer rolls around, I love the heat and 40+ degree days. And when it comes to 'sparsely populated', I've argued several times here on HN that Australia is one of the most urbanised large countries in the world - despite the outback image we promote, far more of us live in the cities and we have a very centralised population.

So not only are your complaints wrong about me, they're the diametric opposite of who I am and what I say. It's fine if you don't like the country and want to live somewhere else, but don't just make shit up about your former fellow citizens in order to justify your movement to yourself.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> Not dismissing the rest of the article at all, but with specific regard to accepting online payments, why no mention of Pin [0]? Stripe/Braintree aren't the only options for Australian businesses to accept credit cards online easily, in-fact we have our own, home-grown alternative kicking arse in that arena.

Pin has been out of beta for over a year, accepts payments in multiple currencies [1], is Australian owned and operated, and works very similarly to Stripe with regard to integration and client libraries [2].

I get frustrated that an Aussie company solving the very issue lots of people complain about (easily accepting card payments online) doesn't get a mention, and is always playing second fiddle to Stripe.

[0]: [https://pin.net.au](https://pin.net.au) [1]: [https://pin.net.au/docs/currency-support](https://pin.net.au/docs/currency- support) [2]: [https://pin.net.au/docs/api](https://pin.net.au/docs/api)

</comment><comment><USER14> I'm an Australian working at a US software company. I've always planned to return home at some point. But the state of the industry in Australia makes this seem like a very poor move. I could move to Sydney, take a 50% pay cut for an uninspiring position, and still end up with a higher cost of living (yes, including house prices!) than here in the Bay Area.

<comment><USER15> You mention that you'd have to take a big paycut to work in Aus, yet the author of the article complains that it is expensive in Australia because of high wages.

Which is correct?

<comment><USER16> I am pretty sure you can hire most Aussies cheaper then you can compared to Silicon Valley or New York, but I consider both of those places the exception to the rule, and someone on a good wage there will tend to take a pay cut to go anywhere.

Look at www.seek.com.au which is pretty much the premiere jobs site for Australia for prices

Senior Dev Roles in Sydney and Melbourne will get ~ $120k AUD per year with Brisbane and other state capitals generally dropping from there. Mid Level in Brisbane (3rd largest city) is generally $65k AUD. Orgs tend to be smaller here, so there are less managers / director / CTO roles then I have seen in the US. As such you can find it more difficult to climb the ladder.

On top of salary though there are a few extra expenses. Employer super is ~ 9% (going up to 12% in the future) on top of salary. States may (or may not) have payroll tax, and you likely also have to pay for things like WorkCover (which is an insurance scheme for injuries sustained at work). On the other hand most companies don't offer health insurance, etc as perks.

<comment><USER5> > On the other hand most companies don't offer health insurance, etc as perks

IMHO as someone who's worked in the US and now lives in Australia, that's a good thing! I'd argue that one of the major causes of the current health insurance fiasco in the US is the history behind health insurance being offered as a perk for good jobs. My health insurance (medicare & private) in Australia is completely separate from my employer and my employment status, and I very much like it that way.

<comment><USER12> Exactly. That is one thing I hate in the US. You leave a company and they cut all your health benefits. Left on the street. And when you do find coverage you end up paying nearly 1K per month for mediocre coverage. In comparison in Australia I remember paying $100 per month (5 years ago) for private coverage on top of medicare (free).

In the US at my previous gig, I remember hearing older folks with health issues afraid to get made redundant because they would loose their health coverage. None of those fears exist in Australia.

</comment></comment></comment></comment></comment><comment><USER17> The Australian Government has a petrifying fear of anything that operates online. They see no value in country wide internet and present short sighted ideas whenever the concept is brought up.

It's kinda depressing

<comment><USER18> I'm sorry but just because the LNP isn't on board with the Monolithic NBN project while still committing billions to infrastructure doesn't equate to "They see no value in country wide internet".

Can we not just slander because they don't agree with you?

<comment><USER19> It's not that they are not on board - it's that they are spending just as much on a version that is objectively worse in almost every way...

They have said that there's no value in homes having faster than 25Mbps, but are still putting in the same amount ($29bn Government equity investment vs $30bn before) of money to deliver that as what the fibre network that would have been able to provide 1Gbps to 93% of the population would have cost (pricing permitting, of course. But that would have dropped fast as demand went up and 1Gb/s would have been as affordable as the 100Mb/s plans available today on the NBN are).

And decent options for small business are nowhere to be found. Have you tried getting decent internet outside a CBD? We would kill for the NBN - <USER3> providers wanted between $2000 and $4000 a month for 20/20Mbps fibre, and this is in the inner suburbs of a capital city!

<comment><USER20> I don't want to get too political here but the previous government massively understated the cost of FTTP broadband. The money saved is much more substantial than $1bn. Whether it's a more effective long term investment is another question altogether.

Also, prices were not scheduled to drop for the broadband service. The Labor governments $30bn costing was predicated on NBN users paying _more_ than they currently pay for ADSL services, and for those charges to increase annually.

<comment><USER21> Wrong. In fact, I posted about this just an hour ago over on reddit:

[http://www.reddit.com/r/australia/comments/290n9b/is_the_nbn...](http://www.reddit.com/r/australia/comments/290n9b/is_the_nbn_strategic_reviews_terminal_value/cigel11)

Furthermore, you're calling it a saving of money in one sentence and then imply that it's in investment right in the next. So what is it, a pure expenditure or an investment?

And in fact, with the NBN plan I'd likely switch to were it available in my area I would pay $10 less than my current connection, have 4 times the download speed, 40 times the upload speed and unlimited data. Or I'd stay with the same provider and pay $5 more and the same as above but not unlimited data. Either of the two are with a phone line included.

So I guess if that's what you meant by paying more than with ADSL, then that's one way of looking at it. Another way is this (mind you, with 40 Mbps upload vs. a maximum 2 with ADSL): [http://i.imgur.com/VKovuSO.png](http://i.imgur.com/VKovuSO.png)

Which blows this:

> The Labor governments $30bn costing was predicated on NBN users paying more > than they currently pay for ADSL services, and for those charges to increase > annually.

Pretty much right of the water, doesn't it? In fact, I'm curious. Where did you hear it and believe it to such an extent you were willing to parrot it without any further fact checking?

</comment></comment></comment></comment></comment><comment><USER22> It could suck more... try being a Kiwi startup!

Seriously, interesting article. I can relate to many of the points (online payments, for instance). I'd put premature taxing of stock options at the head of the list - it's something the government could change at the drop of a hat, and it would change the whole landscape.

<comment><USER23> It's not THAT bad here. I'm starting a new company and tossing up where to incorporate (Oz v. NZ) as one of the other partners is Australian and most of our sales will be in Australia. What's super annoying is how frustrating doing business between the two countries is, especially considering CER. Oh, and the payment thing straight sucks.

</comment></comment><comment><USER24> For the ambitious youngsters: do not wait until there's a Hacker News story about how easy startups are in <Scenario X>.

</comment><comment><USER25> As a founder of several Silicon Valley startups, now living in Tokyo and exploring the "startup scene" in Asia, allow me to comment.

TOP 5 REASONS STARTUPS IN COUNTRY ___ ARE SO DIFFICULT

1-4. Exits, exits, exits and exits. Exits are scarce in country ___ and valuation multiples are low [because strategic acquirers are far away].

5\. VC money. VC money is scarce in country ___ and on shitty terms, because EXITS ARE SCARCE AND ON SHITTY TERMS, and for no other reason.

Beyond that, this article reflects mostly bad decisions and wishful thinking.

> The Government Does Not Support Online Businesses

Neither does the US Government.

> Nor Does it Support Venture Capital

Nor does the US government. Also, see "VC Money" above.

> Foreign Investors Want You to Have a Global Vision

No they want you to sell into a big market. Australia has billionaires, ergo there are large markets in Australia. Go find one. Or go to a place that has a market you like better.

> start-up employees are liable for the tax charge on shares when they vest > (not when sold), even though the value can't be realised properly yet.

The one interesting point in the article! Thank you! Now you have one specific point that you can address. Set aside your blanket criticism of Australia, and people will be able to hear your one good point.

> Very Few Tax Breaks or Grants

What Silicon Valley successes can be attributed to tax breaks or grants? Actually it's just the opposite. Government programs that support startups are most common in countries where there are structural reasons that startups are hard.

> Australia is Getting Really Expensive

Neutral point, it affects your pricing and costs equally.

> We're both in our early 30′s, with a family & mortgages.

So you want to be a startup founder, AND own a house, AND have a family? How is this Australia's problem? Founding a startup requires tremendous focus. Seems like poor judgement with a touch of entitlement.

> Timezones Make Communication Hard

Locating yourself far away from your target market is foolish, not unfair (see "foreign investors" above).

> we've got more incubators than ever before, we got lots of amazing co- > working spaces & everyone is really just trying to find their product market > fit in the big bad world.

I recommend looking a little more intently at the /results/ side of the equation, and a little less on the /effort/ side of the equation.

<comment><USER26> _So you want to be a startup founder, AND own a house, AND have a family? ... Seems like poor judgement with a touch of entitlement._

Well, that makes me feel a whole lot better about being a salaried employee.

</comment></comment><comment><USER27> Missing from this article is that most places outside California don't have laws in place to prevent employers claiming all the IP you generate on the side while being a salaried employee.

Ditto for non-competes. This can make it even harder to raise money, because of the risk of litigation.

The tax burden of receiving stock options is also pretty terrible, it effectively reduces the spread of equity in the Australian startup scene. So there is no broad base of benefactors from this list of successful exits to seed the next round of founders.

</comment><comment><USER28> If you want to play the VC/Funding game, don't do it from Australia. I'm okay with that.

That doesn't mean being a Australian startup sucks, my experience is that it's awesome. I wouldn't have it anywhere else.

Just do that crazy thing of getting customers to pay you money and earn more than you spend.

</comment><comment><USER29> >Foreign Investors Want You to Have a Global Vision

a reasonable expectation given that it is a part of big space speaking the same language and close [relatively, like closer than Russia for example] culturally.

>In a nutshell start-up employees are liable for the tax charge on shares when they vest (not when sold)

the same for the shares - RSU - here, in the US. Or may be the author meant "options"? It is really 2 different things...

> I've witnessed a huge explosion of enthusiasm in Australia, we've got more > incubators than ever before, we got lots of amazing co-working spaces & > everyone is really just trying to find their product market fit in the big > bad world.

sounds like a gold rush, or at least sounds very similar to the one happening right now here in SV.

Anyway, startup is a tool, not the goal...

</comment><comment><USER30> The write-up misses postage as an issue for any startup moving a physical product or trading anything physical between customers. Postage prices within Australia are rough and even worse if you're trying to ship out of the country. People buy from Book Depository (free shipping, at least in the past, from the UK) and Deal Extreme (free shipping from Asia) often getting products more cheaply than they could even ship them here.

</comment><comment><USER31> I'm a French citizen living in Singapore after Sydney (in one of the companies you quote). I think you get a lot of things right there, and they apply to other countries as well.

Where I disagree:

\- Australia is a much bigger market than it looks because Australians are connected to the internet and have high disposable income. For example, only 10% of South East Asia's 618 million inhabitants are connected (and many, only on smartphones), and their basket value is as much as 5x lower for similar products, so you could almost argue that Australia is a bigger market than the whole of South East Asia! 70-90% of e-commerce depending on the products was coming from abroad in 2011 according to CBA crunching 1 million of their customers' accounts - that's heaps of local opportunities.

\- the government does not need to "support" young businesses, it just needs to get out of the way of entrepreneurs and investors. To be fair, compared to most of Europe, it does. Australia is a capitalist Anglo-Saxon country and if you are a citizen, it's pretty easy to start up. Singapore recently made it much harder to get government money, for example SPRING funding is only available to companies with investments from an approved list of VCs, and they have to be Singapore-based, but it still wins because it's the easiest country with the rule of law anywhere in the world to start a company in, especially when it comes to things like visas being granted in a few hours or days.

\- you forgot to talk about immigration law. It's better than the US' yearly H1-B lottery, but still pretty hard to import technical talent, which is scarce locally. Some of us get in for a year under the WHV scheme, which is a nice way to test foreign talent before you apply for sponsorship. From memory, of the 120 developers who applied to our last job posting, around 20% were from the US, 5% from Australia, 50% from Europe and the rest from countries where visas will be painful. If this is representative, Australian and US immigration policies hurt businesses. Australia's entrepreneur visa requires 1 million AUD capitalization, which is ridiculous - in Singapore you can theoretically capitalize your company with 50k SGD, and then apply for an Employment Pass for yourself; all you will need is someone else on an Employment Pass or better to act as director for the company in the meantime. Guess where all the Asian startups incorporate!

But you are correct that there is a hell of a lot of places (such as tax law, with equity as you state or even with income, capital gains and corporate tax) where the government could make Australia considerably more competitive, and the funding environment is really bad (although I've found Australian investors much smarter in aggregate than elsewhere in the region).

</comment><comment><USER32> Lack of mentoring is also a huge problem. I know of an Australian B2C SMS startup which had a killer value proposition and secured over a year's worth of runway funding.

Unfortunately they chose the wrong tech stack to deliver - Enterprise Java instead of something nimble - and didn't have the correct focus on building traction.

With a bit of mentoring and tough truth they could easily have hit a home run.

<comment><USER33> You can be very nimble with Enterprise Java. Plus you get the benefit of the biggest library bar none. The issue isn't the technology it's the mindset.

Look at technologies like Dropwizard or Vert.x.

<comment><USER32> Sure you can, especially with eg Groovy and Grails, but I wouldn't say it's Java's "sweet spot". Plus you tend to attract a lot of corporate enterprise Java devs who on average have a different mindset to quick-moving product devs.

I moved into a Perl shop straight after and the difference in productivity using off-the-shelf language features was staggering. Ironically I'm very interested in Clojure right now, I get the feeling it could deliver impressive productivity while leveraging underlying Java technologies.

</comment></comment></comment><comment><USER34> I would _much_ rather live in Melbourne than SF but I couldn't find _any_ positions that looked at all interesting there...

</comment><comment><USER35> not directly related, but the article mentions Singapore many times: can any non-Singaporean with experience in running (ramen) startup in Singapore give some information? maybe in a blog post like this?

EDIT: to clarify, esp. if you're not there (e.g. you're an Australian in Australia thinking of starting up in Singapore).

<comment><USER31> The gist of it is: if you have residency, it's a no brainer. Incredibly cheap and easy, the only issue (as anywhere not the Valley) is funding, which is still not at Valley levels or with Valley culture. This is changing as more entrepreneurs exit and become angels.

A lot of people have written long posts about it on Quora, so try a quick search there. The regulatory environment is changing somewhat this year, particularly regarding visas (apparently the EntrePass was abused by people buying themselves residency on the cheap and the government is cracking down).

<comment><USER36> In my experience the talent pool is quite small in Singapore compared to Australia. That being said there isn't a lot of good opportunities available to the top talent so you can probably employ a significant chunk of it.

Definitely not going to be a tech hub anytime soon though.

<comment><USER31> It is (out of 120+ applicants, we had 1 PR and 1 EP holder, rest foreign) but it's also incredibly easy to import talent. Pay them enough for an EP, and you get the EP approved in hours if not days.

In one case, the guy was in Colombia when we made him an offer and sent him his flights, his EP was rejected when he was transferring in New York (because he didn't have a degree, so the government thought we were "overpaying" and asked us to explain), his appeal was approved just before he landed in Hong Kong, where he downloaded the Letter and showed it to border control in Singapore. Total time from offer to walking into the office: 36 hours. Good luck doing that in the US.

</comment></comment></comment></comment><comment><USER12> Half of the comparisons in the article are irrelevant, nit picking on stuff that isn't important. However I do agree that Australia doesn't have enough post seed money.. but Blackbird Ventures (and others) are changing that.

So I am an Aussie living in Silicon Valley for the past 5 years. Done 2 tech startups in AU and now in USA. Here is my take on the article based on my experience in both markets.

You don't need an exit strategy. Stop focusing on exits overseas. Just build something people want!

It isn't difficult to scale products worldwide from Australia. Infrastructure wise you now have AWS in Sydney, the best worldwide infrastructure platform (see Gartner's Service Magic Quadrant). On the business front you only ever want to do an international strategy once you proved your product has a scalable business model. Same applies for US companies before they go global after Seed. While in the "Seed" phase use the local market to learn & iterate before scaling out.

5 years ago iTunes App store / Google Play did not exist. That sort of distribution is a door to the world! Not to mention the internet itself. Learn ASO, SEO and if you don't have a mobile product.. then build one asap. The future is mobile. Humans are mobile creatures and we engage now more via that computer (mobile phone) in our pocket.

Look at WhatsApp. Based in Silicon Valley built an empire out of sight. They focused on an international market. By the time local competition noticed what a monster of a business it became, Facebook snapped them up for $19B.

I often hear business people that run tech companies complain more than software engineers about how hard it is to build companies without funding. As Chris Dixon pointed out at Startup School 2013, "Business people vote with their dollars. Engineers vote with their time". Maybe it's time to learn to code? If you can code you can build product now, iterate now etc.. without sitting around day dreaming ideas while waiting for "funding" so you can pay someone else to code it for you.. and potentially mess up the foundations.

Tax Breaks or Grants don't matter. I have not heard any startup even consider those in the USA.

Australia is Expensive - have you seen the rentals in SF/bay area? Food and clothing - yeah dirt cheap in the USA compared to AU.

Timezones - West & East coast in the USA are 3 hours apart. If you need 24 hour support outsource it via oDesk.

Have you considered Health care? in the USA it is insanely expensive. If you don't have a job you will pay around $1.7K for good coverage per month for your family (you, spouse & kid). If you don't, you have no coverage. In Australia.. oh yeah it's free. And not tied to your job. Now say you have employees. You should consider this a massive expense because if you don't cover them, there are plenty of other companies that will with better benefits. You won't have these issues/expenses or competition for talent in Australia.

When I left Australia few years ago there was no Fishburners (Sydney coworking space) or Startmate (YC like mentorship and seed financing) or a swarm of similar entities now all over Australia supporting local startups & talent. Yet people still built business. When I did my 1st tech startup straight out of University there wasn't even enough free online content to tell me how to do stuff, no support networks and infrastructure cost an arm and a leg. If you ask me, I think it is far easier today to build a tech business in Australia then it was few years ago.

</comment><comment><USER37> "Basically, for startups it's super expensive to do business in Australia compared to other big cities—wages, compliance, tax and even software costs are high, and to make it even more tough, there's typically less funding available to meet these costs."

This is what happens when government gets too big and the labor unions are mandated by law.

<comment><USER33> What type of nonsense is this ? It's super expensive to do business in Australia because it's super expensive to do anything in Australia. It has a high cost of living, high salaries, high property prices, small population and it located far from everyone.

We've seen over the last few months what a smaller government looks like. Moving to a "user pays for everything" model means less take home wages with a flow on effect of less money for startups.

Labor unions are not mandated by law and for all intents and purposes irrelevant for 99.9% of startups. They do serve an incredibly valuable part of society being the only counterweight to large corporations who are easily able to buy their way into politics.

<comment><USER38> > We've seen over the last few months what a smaller government looks like. > Moving to a "user pays for everything" model means less take home wages with > a flow on effect of less money for startups.

I don't know much about Australian government, but how is a "user pays for everything" model different from taxation? In your state, doesn't a user still pay for a service through taxation, whether an income tax (less take home wages), sales tax (less money for startups) or some other tax?

<comment><USER39> Taxes didn't get reduced, they just got reallocated to fighter jets.

<comment><USER30> Reductions in public services/welfare supposedly matched by temporary levies on high earners. Those levies will be gone soon enough and the high earners will make back any shortfall through super changes anyway.</comment></comment></comment></comment></comment>


Swift and Dynamism - <AUTHOR> http://blog.wilshipley.com/2016/05/pimp-my-code-book-2-swift-and-dynamism.html <comment><USER2> People that don't use a feature (whether it's introspection, dynamic message passing, classes, FP, actors, GC, type systems, etc) saying they won't miss it, tells us something about the person but not necessarily anything about the feature.

<comment><USER3> Especially if, as was the thrust of many of the articles, they actually _are_ using those features, and quite heavily at that. They just don't see them directly.

Kind of reminds me of the old slogan from the anti-nuclear movement in Germany: "Atomkraft, Nein Danke! Strom kommt aus der Steckdose". (We don't need no stinkin' nuclear power, electricity comes out of the wall socket)

<comment><USER4> > _Kind of reminds me of the old slogan from the anti-nuclear movement in > Germany: "Atomkraft, Nein Danke! Strom kommt aus der Steckdose". (We don't > need no stinkin' nuclear power, electricity comes out of the wall socket)_

Sounds like a hoax slogan (possible from anti-anti-nuclearists). The one I remember was "Atomkraft, Nein Danke!" by itself.

</comment></comment></comment><comment><USER5> This is a very strong endorsement:

> I am better Swift programmer after a year and a half in Swift than I was in > Objective-C after 26 years.

</comment><comment><USER6> He skipped over KVO, KVC and related reflection capabilities of Objective-C that make it so flexible.

I like and use swift, but I haven't reached a point where a lightbulb went off and I proclaimed "Hey I needed this".

<comment><USER7> KVO is horrendous. KVC is occasionally nice but often greatly overused. I certainly wouldn't miss either one.

<comment><USER3> "The solution to bad metasystems is not to ban metasystems, it is to design better metasystems that allow these things in a more disciplined and more flexible way."

[http://blog.metaobject.com/2016/05/what-missing-in- discussio...](http://blog.metaobject.com/2016/05/what-missing-in-discussion- about.html)

See also: The Siren Call of KVO and Cocoa Bindings [http://blog.metaobject.com/2014/03/the-siren-call-of-kvo- and...](http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and-cocoa- bindings.html)

<comment><USER8> Yea, I think KVO could be done better. As I recall, Ember properties were pretty neat, and had a nice way of specifying dependencies. A lot less awkward than a bunch of + (NSSet _)keyPathsForValuesAffectingValueForKey:(NSString_ )key methods.

I'd also want more strongly typed keys, less strings everywhere. I do use NSStringFromSelector as much as I can, but strings are unavoidable in IB.

Also the handling of one-to-many dependencies could be made a lot more intuitive as well.

</comment></comment></comment></comment><comment><USER9> My heart skipped a beat today when refreshing my RSS-feeds. It was like a reunion with your first love. The best of new excitement & old familiarity: Wil Shipley is writing again!

</comment><comment><USER10> It's nice to hear from someone that's been using Objective-C even longer than me who feels the same about Swift. Only 19 years here.

</comment><comment><USER11> I must not be 100% up on my acronyms: what is ARC? it's not "Arc" as in "Lisp like language written by Paul Graham et al" of course.

<comment><USER12> Automatic Reference Counting: [https://en.wikipedia.org/wiki/Automatic_Reference_Counting](https://en.wikipedia.org/wiki/Automatic_Reference_Counting)

</comment></comment><comment><USER13> nevermind, I figured it out.

<comment><USER14> He's saying that the same team that developed LLVM, clang, and ARC (which most people think are good things for the Apple ecosystem) is also bringing you Swift. So you should feel good that the language is being developed by a team with a good track record that will probably find a solution for this particular issue.</comment></comment>


Worthless Stock Certificates - <AUTHOR> http://www.avc.com/a_vc/2011/05/worthless-stock-certificates.html <comment><USER2> I have a April 9th, 1990 Carolco bond certificate which paid for Rambo. It hangs on the wall. The basic idea was inspiration to write a screenplay. The bond was paid off, however, though Carolco eventually went under.</comment>


Sweet.js: hygienic macros for JavaScript - <AUTHOR> http://sweetjs.org/ <comment><USER2> Here is the original discussion <http://news.ycombinator.com/item?id=4560691></comment>