Why is Python slow - <AUTHOR> http://blog.kevmod.com/2016/07/why-is-python-slow/ <comment><USER2> Database died. Google cache: [http://webcache.googleusercontent.com/search?q=cache:5V0TMa0...](http://webcache.googleusercontent.com/search?q=cache:5V0TMa0cMecJ:blog.kevmod.com/2016/07/why- is-python-slow/+&cd=1&hl=en&ct=clnk&gl=uk)

The gist of it is:

* Python spends almost all of its time in the C runtime

This means that it doesn't really matter how quickly you execute the "Python" part of Python. Another way of saying this is that Python opcodes are very complex, and the cost of executing them dwarfs the cost of dispatching them. Another analogy I give is that executing Python is more similar to rendering HTML than it is to executing JS -- it's more of a description of what the runtime should do rather than an explicit step-by-step account of how to do it.

Pyston's performance improvements come from speeding up the C code, not the Python code. When people say "why doesn't Pyston use [insert favorite JIT technique here]", my question is whether that technique would help speed up C code. I think this is the most fundamental misconception about Python performance: we spend our energy trying to JIT C code, not Python code. This is also why I am not very interested in running Python on pre-existing VMs, since that will only exacerbate the problem in order to fix something that isn't really broken.

<comment><USER3> > This means that it doesn't really matter how quickly you execute the > "Python" part of Python. Another way of saying this is that Python opcodes > are very complex, and the cost of executing them dwarfs the cost of > dispatching them.

That doesn't really explain why Python is slow. Your just explaining how Python works. Why should C code be slow? Usually it is fast. Just saying the opcodes are complex doesn't really help, because if a complex opcode takes a long time, it is usually because it is doing a great deal.

Java used to have the opposite problem. It was doing too much at the "Java bytecode" level, such as string manipulation - so they added more "complex" opcodes written in C/C++ to speed things up, significantly.

What you really need to explain is why Python is _inefficient_. Bloated data structures and pointer hopping for simple things like adding two numbers may be a big reason. I know Perl had many efficiencies built in, and was considered quite fast at some point (90s?).

<comment><USER4> >>I know Perl had many efficiencies built in, and was considered quite fast at some point (90s?).

There are a lot of threads in Perlmonks that talk in detail about speeding up Perl, related project et al.

To be summarizing it. Languages like Perl and Python are slow because they do a lot of work out of the box that languages like C don't. There fore when you talk of talk of translating Python to C, or Perl to C. Essentially what you are talking of is translating all that extra action back into C, which will run as fast as Perl or Python itself.

The more you make it easy for the compiler to interpret the faster it can run and vice versa.

Python is slow for the very reason its famous, its easy for the programmer.

<comment><USER5> Lisp and Smalltalk like languages run circles around Python and Perl performance.

Enjoy the same powerful features, have JIT and AOT compilers to native code.

It all boils down to how much the language designers care about performance.

<comment><USER6> And also how much the language designers care about proper language design.

</comment></comment></comment></comment></comment><comment><USER7> I think it's true that language implementations such as Ruby and Python spend most of their time running the C parts of the code. I did a talk saying the same thing about Ruby a couple of weeks ago, but referring to the Java code in JRuby, [https://ia601503.us.archive.org/32/items/vmss16/seaton.pdf](https://ia601503.us.archive.org/32/items/vmss16/seaton.pdf).

But this doesn't mean that a JIT is not going to help you. It means that you need a more powerful JIT which can optimise through this C code. That may mean that you need you to rewrite the C in a managed language such as Java or RPython which you can optimise through (which we know works), or maybe we could include the LLVM IR of the C runtime and make that accessible to the JIT at runtime (which is a good idea, but we don't know if it's practical).

I work on an implementation of Ruby, and we make available the IR of all our runtime routines (in our case implemented in Java) to a powerful JIT, so that we can inline from the interpreter into the runtime and back again.

In the case of Python, PyPy does the same thing, allowing the JIT to optimise between the interpreter and runtime, as they're both written in RPython.

So I think the problem the Pyston project needs to solve is how to allow the JIT to see the runtime routines and optimise through them like it does with Python code.

<comment><USER8> Pypy makes your app take many times the memory for like 20% perf. Which is good but seems maybe often not worth the effort.

<comment><USER9> Eh...

      cat<<eof > float.py
      import itertools
      s = sum(itertools.repeat(1.0, 100000000))
      print(s)

      $ time python float.py
      100000000.0

      real    0m0.602s
      user    0m0.596s
      sys     0m0.004s

      time python3 float.py
      100000000.0

      real    0m0.603s
      user    0m0.600s
      sys     0m0.000s

      $ time pypy float.py
      100000000.0

      real    0m0.211s
      user    0m0.088s
      sys     0m0.004s

That's with _no warmup_ for the pypy variant (or indeed the other python variants). Or, slightly more "robust":

       $ python -m timeit -s "import itertools as i" \
                     "sum(i.repeat(1.0, 100000000))"
      10 loops, best of 3: 594 msec per loop

      $ python3 -m timeit -s "import itertools as i" \
                     "sum(i.repeat(1.0, 100000000))"
      10 loops, best of 3: 592 msec per loop

      $ pypy -m timeit -s "import itertools as i" \
                  "sum(i.repeat(1.0, 100000000))"
      10 loops, best of 3: 68.2 msec per loop

Pypy actually does pretty good here:

      $ cat float.cpp
      #include<iostream>

      int main() {
        double s = 0;
        for (int i = 0; i < 100000000; ++i) {
            s++;
        }

        std::cout << s << std::endl;
        return 0;
      }

      $ g++ --std=c++14 -O3 float.cpp
      $ time ./float
      1e+08

      real    0m0.237s
      user    0m0.236s
      sys     0m0.000s

Note that the C++ code use a loop, not a lazy generator. Apparently they may be coming in c++17 as proposal N4286.

<comment><USER10> Summing a list of numbers is easy mode for a JIT. You've got a tight loop with one type that can be statically shown will never be violated in real-time. Unfortunately, unless that's actually your workload, the speed with with a JIT-based system can add numbers is not relevant to how fast it runs in practice. Any JIT that can't tie C on that workload is broken somehow.

Personally, I think people often go quite overboard with the "benchmarks are useless" idea, but this benchmark really is useless, because it will never produce any differences betweens JITs and thus can't show whether one is good or bad.

<comment><USER7> > it will never produce any differences betweens JITs and thus can't show > whether one is good or bad

It can tell you which JITs can't even manage to remove the loop, which is useful to know.

<comment><USER9> Apparently neither cpython, pypy or gcc manage to remove the loop in this case. I actually think it is interesting that this "slow" code in cpython is within [ed: ~10x] of pypy/jit/machine code (c++ probably should do better, I'm not all that familiar with gcc - maybe -O3 isn't enough to try to unroll loops and/or try to vectorize).

Actually code like this arguably should be a win for a high-level language with an optimization pass; ideally the whole thing should be translated to a constant at compile-time.

<comment><USER7> Ah right I think that's because the accumulator is a double. I missed that. I think it should still be possible but compilers probably don't bother.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I never quite grasped the actual machinations of Python until I watched Philip Guo's lectures on Python internals.

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

It's a bit long, and definitely over several sittings, but I feel like I really understand Python better and relevant to the post, the complexities and tracking (frames, exceptions, objects, types, stacks, references) that occur behind the curtain which drive Python's slow native performance.

<comment><USER12> Is the slowness due to the structure of the language, or is it because of the implementation?

I guess the latter, because PyPy performs a lot better I hear.

<comment><USER10> PyPy performs better, but when you perform 2-3x times better than something ~40x slower than C, you still don't end up with a "fast implementation". Just, "not as slow". If you've got Python code in hand and you want it to go faster, PyPy can have a great bang-for-the-buck, but if you want it to be legitimately approaching the limits of the capabilities of the hardware, you'll need a different approach.

But let me once again underline that if you have Python code in hand, and you want it to be faster, PyPy is a great option. I'm not being critical of PyPy.

A common mantra I've heard dozens of times in the last ~20 years is that there's no such thing as a slow language, only slow implementations. But after witnessing the effort to create "fast" implementations for a lot of slow languages over the past 10 years, and seeing so many of them plateau out at about 10x slower than C, I no longer believe this. Or at least, I no longer believe it is practically true. If there is an implementation of Python somewhere in theoretical program space that is as fast as C, it does not appear to me that it will be possible for humans to produce it.

<comment><USER13> I agree. Though speed of the JVM for instance is not quite as bad. C comes at a development cost, Rust makes this better, but the memory management is still something that you have to get comfortable with.

The question that really nags at me is why do people want interpreted languages in all of these cases? When you're deploying code, you inevitably go through a series of steps in deployment where throwing in a compile wouldn't destroy the workflow.

I think for many of these cases, the GIL is a great example of this, the language has over-optimized for development at the cost of its runtime.

<comment><USER14> I'm guessing that people don't usually really want an interpreted language; usually what they want is a language they like, and the one they like happens to be interpreted.

I can imagine reasons to want an interpreted language. As a matter of fact, I've written several implementations over the past 20 years of a hobby language, some of them compiled, some of them interpreted, and in some of the later cases I consciously chose interpretation because dynamic runtime introspection and the ability to see (expanded) source code directly in the runtime during a breakloop was something I wanted, because I was experimenting with runtime semantics and I wanted to be able to see it directly at runtime with the minimum possible change from the source code as-written.

I've also written interpreters sometimes because I'm actually interested in interpreters per se.

But most people probably don't want interpreters for those kinds of reasons. As I said, I think it's more likely that most of the time when someone wants "an interpreted language", what they really wanted is some particular language whose most prominent implementation happens to be interpreted.

That raises the question of why implementations are interpreted, of course. The answers, I think, are some combination of the answers I gave above and the fact that interpreters are really easy to write, especially if you choose the right source language. Simple compilers are not much harder, but easier is easier. I'm generally inclined to start with an easy interpreter, myself, (unless what I'm interested in is compilation strategies) because I get from zero to experimenting with semantics that much quicker, and experimenting with semantics is usually where the fun is.

</comment></comment></comment></comment></comment><comment><USER15> Poor article. This subject has been covered many times, and others have put in the key references.

Python's dynamism is part of the problem, of course. Too much time is spent looking up objects in dictionaries. That's well known, and there are optimizations for that.

Python's concurrency approach is worse. Any thread can modify any object in any other thread at any time. That prevents a wide range of optimizations. This is a design flaw of Python. Few programs actually go mucking with stuff in other threads; in programs that work, inter-thread communication is quite limited. But the language neither knows that nor provides tools to help with it.

This is a legacy from the old C approach to concurrency - concurrency is an OS issue, not a language issue. C++ finally dealt with that a little, but it took decades. Go deals with it a little more, but didn't quite get it right; Go still has race conditions. Rust takes it seriously and finally seems to be getting it right. Python is still at the C level of concurrency understanding.

Except, of course, that Python has the Global Interpreter Lock. Attempts to eliminate it result in lots of smaller locks, but not much performance increase. Since the language doesn't know what's shared, lots of locking is needed to prevent the primitives from breaking.

It's the combination of those two problems that's the killer. Javascript has almost as much dynamism, but without extreme concurrency, the compiler can look at a block of code and often decide "the type of this can never change".

<comment><USER16> Note that threading is not the only place this can happen: this can happen as the result of signal handlers as well. cpython has can trigger signal handlers between any python opcodes.

</comment></comment><comment><USER17> (based on discussion, can't get to website)

Any discussion that does not compare to LuaJIT2 is suspect in its conclusions. On the surface, Lua is almost as dynamic as Python, and LuaJIT2 is able to do wonders with it.

Part of the problem with Python is (that Lua doesn't share) is that things you use all the time can potentially shift between two loop iterations, e.g.

        for x in os.listdir(PATH):
           y = os.path.join(PATH, x)
               process_file(y)

There is no guarantee that "os.path" (and thus "os.path.join") called by one iteration is the same one called by the next iteration - process_file() might have modified it.

It used to be common practice to cache useful routines (e.g. start with "os_path_join = os.path.join" before the loop and call "os_path_join" instead of "os.path.join"), thus avoiding the iterative lookup on each iteration. I'm not sure why it isn't anymore - it would also likely help PyPy and Pyston produce better code.

This is by no means the only thing that makes Python slower - my point is that if one looks for inherently slow issues that cannot be solved by an implementation, comparison with Lua/LuaJIT2 is a good way to go.

<comment><USER18> There isn't even any guarantee that "os.path" is the vanilla iterative lookup it's presented as. For all we know, it could be a @property-decorated method thousands of lines long.

<comment><USER17> But as long as you know it is the same thing, you could move ("hoist") it outside the loop. In Lua, you generally can (and LuaJIT2 does). In Python, rarely if ever.

</comment></comment></comment><comment><USER19> Python is high level glue between efficient C functions. It's blindingly fast _if_ you are allowing those efficient C functions to do the heavy lifting. That's why you can do image processing in python, right up until the point where something you need to do doesn't have a ready made primitive and then your program will slow down tremendously if you don't take the time to write the thing you're missing in C.

<comment><USER20> As glue, it isn't particularly efficient, both in runtime or in programmer affordances. Ctypes and cffi are both fairly new and not very friendly. The number of programmers who "drop to native" is ridiculously small. A better glue language would make this almost transparent.

<comment><USER21> every python programmer who has every used Numpy or Pandas, and in my opinion this is where Python shines and why it's so huge in scientific programming, is "dropping into native". So actually a large amount of people are doing so. And I find Python to be an excellent glue language with almost anything I can think of being possible, and much of my heavy lifting being extremely efficient, especially if you use a modern AVX-enabled Numpy.

Arguably anybody who ever accessed a database in Python is also "dropping into native". That's why no sane database is written in Python, but plenty of database-using applications are.

The only language I have discovered that approaches the efficiency of Python as "glue" is R, but it's about 20x slower, and doesn't even try to be threaded (which can be a big problem for IO sensitive glue tasks).

<comment><USER20> Because extensions that use native code exist doesn't mean that low friction affordances exist for the median programmer to use native code in their applications. I think we will start to see some interesting projects in this space after Python 3.6 ships.

</comment></comment></comment></comment><comment><USER22> The following may also be of interest:

\- Why Python is Slow: Looking Under the Hood [0]

\- Fast Python, Slow Python by Alex Gaynor [1]

[0] [https://jakevdp.github.io/blog/2014/05/09/why-python-is- slow...](https://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/)

[1] [https://www.youtube.com/watch?v=7eeEf_rAJds](https://www.youtube.com/watch?v=7eeEf_rAJds)

</comment><comment><USER23> Actually I never found Python "slow". I found it "slow" in some things, but not "all things are slow with python". What was problematic was pulling big lists from a database and doing some stuff with the list.

Also it was really akward that "threading" is not really great on python. Especially not when you are using 16 core servers. I mean you could create vm's for that or dockerize that. but that means deployment complexity increases which wasn't our goal. But I've seen a lot of successful python deployments and if you have enough manpower you pretty sure can run with CPython just fine.

<comment><USER8> On a 16 core server you can run 32 copies of your program Ala Celery. It will peg the CPUs just dandy..

<comment><USER24> My experience is that it is not "dandy". We have had a lot of trouble pegging the CPUs on our celery worker boxes (doing CPU bound jobs). You get more than one CPU utilised, sure, but we never can seem to get all cores fully utilised. We rewrote some of the tasks into a single multi-threaded JVM process pulling off the rabbit queue and they instantly and consistently pegged every CPU at 100%. I wish I knew how to get our celery worker farm to full utilisation because it would save us a fair bit of money.

<comment><USER25> He's saying run 32 individual processes, not 32 threads within one process. Python's global interpreter lock will knobble you if you're using threads.

<comment><USER26> Celery has a worker pool of separate Python processes that jobs can be offloaded to. It side steps the GIL because it doesn't use threading.

<comment><USER8> Well two ways. Either launch 32 or 64 copies of the process using multiprocessing, or 1000 threads with geventlet.

I have never found a box I couldn't peg :)

I guess if you had 1 gb ram and 16 cores it would be challenging in python.. but a few gb of ram and we are on.

</comment></comment></comment></comment></comment></comment><comment><USER27> Can someone ELI5 why Python is more like rendering HTML than executing JS? This is confusing to me since much of node.js/V8 is C, yet AFAIK (from the title and my experience) it's faster, and I don't recall anything intrinsically more declarative (i.e. HTML) when writing python compared to JS. They both feel very similar as scripting languages to me.

IOW, from my limited ignorant perspective, this feels more like the WHAT than the underlying differentiating WHY.

It's possible it's in there and I missed it.

EDIT: FWICT from the linked slides[1], it's the result of 2 issues: 1. Expensive dynamic language features and 2. python is like node.js, but as if you only called V8 bindings and so VM performance was irrelevant. This is strange to me; while I feel I can conceptualize the difference, I still don't know enough to understand why it is so compared with node.js.

[1] [https://docs.google.com/presentation/d/10j9T4odf67mBSIJ7IDFA...](https://docs.google.com/presentation/d/10j9T4odf67mBSIJ7IDFAtBMKP- DpxPCKWppzoIfmbfQ/mobilepresent?slide=id.g142ccf5e49_0_453)

<comment><USER28> The HTML comparison was referring to the python bytecode rather than the language. A more apt comparison would be CISC vs RISC processors, where the V8 IR is more like a RISC processor.

</comment></comment><comment><USER29> The argument is that Python spend most time in the C runtime, but that is really only a property of the current implementation. If I use Jython or even implement Python on top of bare metal, making Python the OS, that will not be spending any time in the C runtime because there wouldn't be one, but that's besides the point.

The question is whether an implementation could be made significantly faster than the current Python interpreter is, or whether there are properties of the Python semantics that makes that hard. One such thing is the amount of dynamic behavior that is allowed in Python. That require most variables to be boxed, even for basic types like numbers. There are dynamic languages (LuaJIT was mentioned, but Javascript, Julia and several Lisp implementation could be mentioned as well) that are considerably faster than Python, so why isn't Python fast?

Personally I think that Python could be made quite a bit faster than it is, but such a new Python system would almost certainly be incompatible with a large number of the Python libraries that interface with native code. For most Python users, this availability of libraries is a major motivation for using Python in the first place, and a new fast implementation without such compatibility would be worthless for most users.

</comment><comment><USER30> The notion that Python spends most of its time in its C code isn't particularly insightful. That's how interpreters traditionally work. It just raises the question of _why_ that C code is slower than other interpreters.

Personally, I don't mind Python's speed. I don't use it for runtime speed, I use it for development speed. If I need runtime speed I use C++. Lately, though, I'm getting to the point where I write Common Lisp about as quickly as Python _and_ it typically runs 4-5x faster than Python, so I've just been using that.

</comment><comment><USER9> From the linked [lwn] article:

"Another example he gave demonstrates the slowness of the C runtime:

        import itertools
        sum(itertools.repeat(1.0, 100000000))

That will calculate the sum of 100 million 1.0s. But it is six times slower than the equivalent JavaScript loop. Float addition is fast, as is sum(), but the result is not.

Larry Hastings asked what it was that was slowing everything down. Modzelewski replied that it is the boxing of the numbers, which requires allocations for creating objects. Though an audience member did point out with a chuckle that you can increase the number of iterations and Python will still give the right answer, while JavaScript will not."

Reminded me about the excellent talk about Julia: "Julia: to Lisp or not to Lisp?" [https://www.youtube.com/watch?v=dK3zRXhrFZY](https://www.youtube.com/watch?v=dK3zRXhrFZY)

One things he points out early is that both the C99 and the R6RS Scheme spec is 20% numerical. Because correct and (reasonably) fast numbers and arithmetic is actually pretty hard to get right on a computer - if you want to abstract away hardware "short-cuts" and allow for precise arithmetic by default.

It will be interesting to see how much type hints (eliminating some of the boxing/unboxing) will help python. And if it turns out to really be a good fit for the language -- everyone wants "free" performance, but transitioning to a (even partially) typed language is certainly not "free".

Another point with the above loop, is that ideally, even if it can't be optimized/memoized down to a constant - it really shouldn't have to be much slower than its C counterpart. Except for handling bignums in some way or other (perhaps on overflow only).

[lwn] [https://lwn.net/Articles/691243/](https://lwn.net/Articles/691243/)

<comment><USER31> > Another point with the above loop, is that ideally, even if it can't be > optimized/memoized down to a constant - it really shouldn't have to be much > slower than its C counterpart. Except for handling bignums in some way or > other (perhaps on overflow only).

Sadly, bignum handling is very expensive even with type hinting. Essentially, every time two numbers is added or subtracted you have to check for overflow:

        int z = hw_add(x, y);
        if (over/under-flowed?()) {
          bignum* bn = new bignum();
          bignum_add(to_bignum(x), to_bignum(y), &bn);
          return bn;
        }
        return z;

So most modern statically typed languages (none named, none forgotten!) actually cheat and use modular arithmetic instead. For example, the straightforward way of computing 9223372036854775807 + 1 on a 64bit system in one of those languages is likely to yield an incorrect result.

Which imho is complete bullshit because there is no reason to sacrifice correctness for performance other than to win benchmarking contests.

<comment><USER32> This overflow check is extremely cheap. Just check the overflow flag on the cpu. jo +4; jmp bignum; 6 byte. C compilers didn't support it until last year, so everyone just used inline assembly. Now we have it in gcc 5 and clang 3.4

One good trick started by lua is to use double for everything and check the mantissa of the normalized result for overflows. A double can represent the whole int32 range. With double and nan-tagging you have a unique fast representation of all primitives and can use a double word stack. Which is the biggest win. Look at how python, perl and ruby are doing this. Horrible. And then look how a fast dynamic language is doing it.

<comment><USER31> Everything is relative. :) Compared to the add instruction itself, the overflow check is very expensive. But the big problem is that your types widen. E.g:

        // x and y are hardware integers >= 0
        var z = x + y
        for (var i = 0; i < z; i++) {
            ...
        }

If your language used modular arithmetic, 'z' would also be a hardware integer and the induction variable 'i' could be kept in a cpu register. But with real arithmetic using bignums you can't assume that anymore and each iteration of the loop must do a relatively expensive comparison of 'i' against 'z'. In pseudo code:

        var z = x + y
        var i = 0
        if (!hw_int(z)) i = new_bignum(0)
        while (true) {
          // i < z
          if (hw_ints?(i, z)) {
            if (i >= z) break
          } else {
            if (bignum_gte(i, z)) break
          }
          ... body ...
          // i++
          if (hw_int?(i)) {
            i++;
          } else {
            i = bignum_add(i, 1)
          }
        }

<comment><USER32> No, it's super cheap. overflows happen <1%, so you mark it as UNLIKELY, and the branch prediction units just don't care about all those bignum branches.

If you know to use bigints or bignums, just type it and use their variants from the beginning.

Most better dynamic languages already use tagged ints, so they have only say ~30bits for an int and do a lot of those overflow checks and still beat the hell out of the poorly designed dynamic languages with full boxed ints or nums.

</comment></comment></comment></comment></comment><comment><USER33> Python has had some surprising costs but some well-known cases have straightforward work-arounds.

For example, at one point, the _way_ you called a multi-dot function actually mattered (not sure if this persists in the latest Python releases). If your function is like "os.path.join", the interpreter would seem to incur a cost for each dot: once to look up "os.path" and once to look up "path.join". This meant that there was a noticeable difference between calling it directly several times, and calling it only through a fully resolved value (e.g. say "path_join = os.path.join" and call it only as "path_join" each time).

Another good option is to use the standard library's pure-C alternatives for common purposes (containers, etc.) if they fit your needs.

</comment><comment><USER34> Yet we got a ~5% speed advantage when I refactored bytecode to wordcode [https://bugs.python.org/issue26647](https://bugs.python.org/issue26647)

</comment><comment><USER35> Just because you're in the C runtime, doesn't mean you're doing productive work. If it isn't the bytecode VM that is slow, then why is PyPy able to be much faster in many cases.

In my experience, Python is easily 10-20x slower than a compiled language when doing computational work where you can't just call into a big C function, just like you would expect to see from any interpreter. I won't generally use it for anything data intensive.

</comment><comment><USER36> What's expensive about the runtime is the redundant type/method-dispatch not the opcode dispatch. The runtime is constantly checking types and looking up methods in hash tables.

Gains can be made by "inter-bytecode" optimization in the same vein as inter- procedural optimization.

If you can prove more assumptions about types between the execution of sequential opcodes, you can remove more type checks and reduce the amount of code that must be run and make it faster.

E.g.:

        01: x = a + b
        02: y = x + c

If we have already computed that a and b are Python ints, then we can assume that x is a Python int. To execute line 2, we just then need to compute the type of c, thus saving time.

The larger the sequence of opcodes you are optimizing over, the better gains you can make.

Right now I think Pyston uses a traditional inline-cache method. This only works for repeated executions. The code must eagerly fill the inline cache of each opcode to get the speed I'm talking about.

Another reason Python's runtime is slow is because there is no such thing as undefined behavior and programming errors are always checked against. E.g. The sqrt() function always checks if its argument is >= 0, even though it's programming error to use it incorrectly and should never happen. This can't be fixed by a compiler project, it's a problem at the language level.

Being LLVM based, I think Pyston has its greatest potential for success as an ahead-of-time mypy compiler (with type information statically available). IMO leave the JITing to PyPy.

</comment><comment><USER37> Why can't someone just write another compiled language with 100% Python syntax? e.g Julia. only more general purpose.

<comment><USER38> I think Nim ([http://nim-lang.org/](http://nim-lang.org/)) is what you are looking for.

<comment><USER37> Is that a joke? cause I find it really funny..

<comment><USER39> why?

<comment><USER37> Nim's syntax is far away from that of Python its more like "clean" JavaScript.

I wasnt intending to be sarcastic. I apologize if so.

<comment><USER39> I think it's very pythonic.

Can you give examples?

Also, "clean" JavaScript can look like CoffeeScript which look very much like Python/Ruby, you can almost say that "clean" versions of languages tend to converge to something like that for some ppl

<comment><USER40> CoffeeScript is terrible. Full of implicit rules and magic. Python generally seems to be the opposite.

<comment><USER39> I don't think it's magical syntactically. Semantically, maybe?

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> The arguments presented here are extremely dumb. Of course everyone knows already that the ops itself are slow. What not many people know is that all this could be easily optimized. javascript had the very same problems, but had good engineers to overcome the dynamic overhead. php7 just restructured their data, lua and luajit are extreme examples of small data and ops winning the cache race. look at v8, which was based on strongtalk. look at guile. look at any lisp. All these problems were already solved in the 80ies, and then again in the 90ies, and then again in the 2000ies.

python is similar to perl and ruby plagued with dumb engineering. python is arguably the worst. They should just look at lua or v8. How to slim down the ops to one word, how to unbox primitives (int, bool), how to represent numbers and strings. How to speed up method dispatch, how to inline functions, how to optimize internals, how to call functions and represent lexicals. How to win with optional types. Basically almost everything done in python, perl and ruby is extremely dumb. And it will not change. I'm still wondering how php7 could overcame the very same problems, and I believe it was the external threat from hhvm and some kind of inner revolution, which could convince them to rewrite it. I blame google who had the chance to improve it, after they hired Guido, and went nowhere. You still have the old guys around resisting any improvements. They didn't have an idea how to write a fast vm's in the old days, and they still don't know.

<comment><USER41> > javascript had the very same problems, but had good engineers to overcome > the dynamic overhead

Sure, it also had Google to funnel an insane amount of money and engineering time/skill into it. If it's so simple to do then put all your ideas into a PEP and submit it.

<comment><USER32> A PEP? python needs to be rewritten completely. cython, pypy or mypy are good starts, but their op and data layout is still suboptimal and not best practice.

And I have no interest in python as language, only in fast dynamic VMs. e.g. potion could just add a python parser and get a 200x function call speedup, just as done for ruby or perl. The problem is the library.

</comment></comment></comment><comment><USER42> Python is made faster by optimizing the C implementation of it's opcodes, not by doing any optimization at a higher level?

Really?

Sounds more like; It's _more convenient for us_ to try to optimize cpython at the opcode level because its _technically difficult_ to apply JIT techniques at a higher level because of _the way cpython is implemented_.

        Pyston's performance improvements come from speeding up the C code, not the Python code.

        When people say "why doesn't Pyston use [insert favorite JIT technique here]", my question
        is whether that technique would help speed up C code.  I think this is the most fundamental
        misconception about Python performance: we spend our energy trying to JIT C code, not Python
        code.

        This is also why I am not very interested in running Python on pre-existing VMs, since that
        will only exacerbate the problem in order to fix something that isn't really broken.

...really?

All I can fathom is that this project is about trying to take the existing cpython implementation and make it faster by applying various magical hacks at a very low level, rather than trying to address any of the more difficult problems about why the cpython runtime is slow.

This is exactly the opposite approach from pypy (ie. reimplement cpython in a way which is fundamentally better); and it certainly seems to be yielding some interesting results.

...but I think I'm a little skeptical that its the only solution.

It just happens to be the solution they've decided to pursue.

</comment><comment><USER43> Who cares? You're not using it because it's performant. You use it because it's fast to code in and to ship. If you only care about performance, write C or Java or an assembler and extend your ship date.

<comment><USER40> Obviously being down voted for being too pragmatic.

</comment></comment><comment><USER44> Important clarification: when the author says "C runtime", what he means is "Python runtime written in C". The C runtime is, of course, libc, libm, etc. I'm not sure why the author thinks Python's high-level IR (please don't call it a VM) is a good thing, or unoptimizable (to a better IR or native code). Perhaps he's never read about Smalltalk/Self optimization (which is eye- opening!)

</comment><comment><USER45> For me this post isn't an argument against Mozilla implementing a similar dialogue; it's an argument for implementing one and improving it.

To really have meaningful improvements would require totally reworking how extensions deal with the DOM and requiring them to ask for different levels of permission. That would break most plugins as written and probably require significant work to implement.

</comment><comment><USER46> imho it's about references (pointers) and the inability of the memory prefetcher to optimize memory accesses. to fix this languages need true value types.

</comment><comment><USER47> Why is website down

<comment><USER48> Something in my server's configuration eats more and more memory, until the OOM killer decides that killing the MySQL database looks like a dandy way to reclaim memory.

<comment><USER49> Try Varnish, for stuff like this it's pretty perfect.

</comment></comment></comment><comment><USER50> Very nice to see some circular reasoning here. Because python is slow everyone dispatches to C code. Because everyone dispatches to C code, optimising the python interpreter is not worth it.

</comment><comment><USER51> Error establishing a database connection

<comment><USER22> At least it doesn't emit the entire stack trace along with the message!

Question: are static websites so hard to do?

<comment><USER52> Static websites take away one of the crucial pieces of blogging: Comments.

<comment><USER53> Its trivial in Jekyll to add support for a 3rd party comment service, e.g. Disqus.

<comment><USER9> Only if you are comfortable using a 3rd party comment service (or injecting 3rd party javascript in your site in the first place). I know it's common, but even with the advances in CORS and whatnot, it still (IMNHO) defeats a lot of the benefits of a static web site.

That said, I would probably prefer embedding disqus or [https://muut.com/](https://muut.com/) comments to running a complex php application _just for comments_.

</comment></comment></comment></comment></comment><comment><USER54> Any script language is slow

<comment><USER32> Only the old dumb ones (python, perl, ruby, formerly also php). Normal dynamic script languages are written by engineers and are therefore very fast.

<comment><USER55> Are you implying that people like Larry Wall, Yukihiro Matsumoto and Guido van Rossum, all of who have advanced degrees in computer science are not (good?) engineers?

<comment><USER32> They might be good hackers, but have no idea how a VM should be implemented. That's why you got this mess.

Just look how they designed the ops, the primitives, the calling convention, the stack, the hash tables. This is not engineering, this was amateurish compared to existing practice.

<comment><USER55> Can you give some examples of more professional VMs which support dynamic languages without an extra compilation step apart from the JVM?

<comment><USER32> I gave already and I didn't call them more professional. I called them engineered, in opposite to those simple adhoc implementations. The only part why worse is better in this regard was because of getting business attraction.

lua, v8, guile (but just last year), smalltalk and family (esp. strongtalk and the other pre-v8 projects), ml and family (MLton and ocaml), haskell (after many years of being too slow), any better scheme (>20), any better lisp (>5), php7 (just last year), and then the tiny lua based ones, like potion, wren, tinyrb, tinypy or tvmjit (with simple method ast->jit), or partially io, lily, or the other post-smalltalk languages, like maru (simpliest ast->jit) or the soda family around alan key and ian piumarta.

when you design a 20-100x slower calling convention without proper support for lexical variables, slow data, no unboxing, no tagging, slow ops, no inlining, no fast memory reclamation you are in the pre-SICP days and should be treated like that.

not even talking about the modern static languages and type systems which are now catching up, via llvm. not go or rust, but stuff like pony or julia.

</comment></comment></comment></comment></comment></comment><comment><USER56> Well, C/Fortran/C++/ASM are a PITA when it comes to dynamic structures like the one for handling configurations.

Plus authors missed that boxing in python has a tendency to fragment data in a non controlable way in the memory thus making the use of L1/L2/L3/mem (on x86) or other memory architecture with similar layout very hard to use.

If you code often you know the 80/20 rule: 80% of your code is the setup preparing for the 20% of heavy lifting.

Numpy (which relies on Fortran) is a nice Proof that when done correctly python is really useful.

A computing a Moving average in pure python is 10 000 times slower than using numpy (especially if you use FFT).

So ... I am saying since python (like Tcl or Perl) is a good language for doing FFI (foreign function integration) it should be used this way.

And thanks to the often unfairly hated GIL it enables to use un-thread safe foreign language library in a thread safe way.

All being said and done, if python used this way is slow, I dare say it is because some coders do not understand how to build there data/execution flow. And this is not language dependent, but a question of coder.

I thought they were 10x coders in the past.

I recently realized there are /10 coders in fact.

The one that are pissed at coding when «it does not work the way it should» and expect language to be magically doing most of the job without learning.

The 1x coders on the other hands are boring, slow coders and accept that when the «stuff» is not behaving the right way, it may not be the stuff that is not working, but him/her that have a misconception.

1x coder is not a state, it is a trajectory that can degrade or improve with new challenge and poor/good state of mind, hence the misconception on 10x.

<comment><USER57> It is possible to make a dynamic language natively compiled and very fast. Common Lisp is arguably even more dynamic than Python, and SBCL manages to generate code that rivals C in performance.

<comment><USER58> I don't consider Common Lisp "more dynamic" than Python; at least in that you modify code at runtime and such. Frequently Common Lisp code is not particularly dynamic, because you can get the same level of expressiveness without relying on mucking around with magic at runtime.

Also SBCL only generates really fast code if you use a lot of type hints and (optimize (speed 3) (safety 0)). That said, when you do, it's _really_ fast.

<comment><USER59> Typically Common Lisp and its implementations provides a wide range of performance options. It's not limited to the model of some more primitive language runtimes, which provide only two modes (simplified): slow if implemented in the language, fast if it runs mostly in its runtime and library functions written in C. There are Common Lisp implementations which follow this model, too. But there are also many which have sophisticated runtimes with optimizing native code compilers.

To get to really fast code in Common Lisp one needs to write relatively low- level code with type declarations, optimization hints, low-level operators etc.

There is a part of Common Lisp which is as dynamic (more?) as Python: everything written in CLOS (multi-dispatch, multi-methods, method- combinations, ...) and expecially when using the CLOS MOP. Is it slower or faster than comparable Python code? I have no idea and I haven't seen any interesting benchmarks. The amount of CLOS use depends on the implementations. Some implementations have a lot of their library code and also much of the language itself (everything IO, error handling, ...) written using CLOS.

<comment><USER57> I have written plenty of heavily CLOS-based code that is still very fast. I doubt that Python could come close in performance.

I think it would be an interesting exercise to do some benchmarks to get some actual data behind both of our guesses.

As I am not a very experienced Python developer, would you be interested in writing some test code that is representative of typical Python code, and I'd be happy to port it over to CLOS and so that we can run some benchmarks?

I think such results would be of interest to the HN audience.</comment></comment></comment></comment></comment>


CouchDB on Android - <AUTHOR> http://www.couch.io/android

<comment><USER2> This is great, a 1.0 releas and android support.

Keep up the great work this is awesome!

</comment><comment><USER3> How does this work? Did they port Erlang to Android?

<comment><USER4> Yes, Erlang has been ported to Android and Nokia Maemo, others on roadmap.

</comment></comment><comment><USER5> is it on iphone?

<comment><USER6> Of course not. It is not possible to put it on iPhone (without jailbreak at least).

<comment><USER7> The recent rewording of the interpreted languages clause of the App Store agreement ought to allow CouchDB to run embedded in an application.

I hacked on it a bit at Open-Source Bridge last month; didn't even finish getting Erlang compiled. It's all gravy until you get to the bootstrapping step, which may in fact require a jailbreak, or much more Erlang-fu than I have.

And unless every app uses its own couch, you could argue that it's of marginal utility to run CouchDB on the iPhone because of its limited support for "real" multitasking. (You can't use your phone as the couch in your pocket for all your desktop apps, or something like that.) However, CouchDB's focus on replication and the offline use case make it useful as a dead-easy cloud cache and service.</comment></comment></comment>


Ways to Save Barnes & Noble - <AUTHOR> http://www.theamericanconservative.com/10-ways-to-save-barnes-noble/ <comment><USER2> Is it only me that finds it deeply ironic that the company credited with closing a gazillion independent booksellers and round-the-corner bookshops, is currently at the receiving end of exactly the same market forces that it espoused during their demise?

Perhaps the real question is not how to save Barnes and Noble, but rather _why_ anyone wants to save them at all. I find it hard to see them cast as Meg Ryan opposite Amazonian Tom Hanks in the re-re-make of You've Got Mail.

B&N were once fans of market forces, and the public's insatiable hunger for lower prices at any cost. Unfortunately, their discovering that economies Of scale are only on your side until someone else comes along who does it better.

B&N are fundamentally Unsaveable. They contain neither the charm of the shop around the corner, nor the value of Amazon. I for one will shed no tears at the demise of this corporate monster.

<comment><USER3> I agree with the sentiment, but since BN has crushed independent booksellers the problem now is that if BN closes, lots of more isolated places like suburbs and exurbs will have no good place to browse and buy books. I'm currently staying in a suburb of a major American city and BN is quite literally the only place to buy physical books for a 50 mile radius, if not more.

It's kind of a crappy situation, but it's one that we've put ourselves in. I'm not confident that we'd see a renaissance of indie booksellers should BN close.

Personally I think that with Nook, BN for various reasons bungled what could easily have been a very successful product. They might still have been able to turn it around by pressuring publishers to sell ebooks for cheaper, removing DRM, and focusing on a true ereading experience and owning a niche instead of competing with full-blown tablets.

Since they've thrown in the towel with Nook, their only hope seems to be dropping prices to give people a reason to walk in instead of going to Amazon, or to make money on ancillary physical experiences, like drinking coffee while browsing. But they already made a possibly fatal mistake in that strategy by renting out space to Starbucks instead of doing their own coffee thing.

BN closing would be a pretty big blow to books in general, regardless of Amazon's sales. While I can't pity the corporation for being affected by market forces, nor can I pity it considering what it's done to indie sellers, neither do I want to see books completely disappearing from the average American's sight.

<comment><USER4> > I'm not confident that we'd see a renaissance of indie booksellers should BN > close.

Why not?

Here's a pretty standard progression:

1\. there used to be a bakery a few blocks away--medium-scale, medium- convenience. Six or seven of them in your district.

2\. Then a supermarket came. It was just a bit further away than the nearest bakery, but it included a bakery and a bunch of other things. The bakeries went out of business. One supermarket per district was all you needed.

3\. But supermarkets aren't something you pop into for an "experience"\--you don't visit one on a date. So, someone trimmed down the bakery idea to the most consumer-focused essentials, giving people only what they wanted and none of what they needed (the supermarket covers what they need, after all), and launched... a cupcake shop. Maybe just one to start. But then, suddenly, they're on every street corner.

I could see the "cupcake shop" equivalent to a bookstore: not a big pile of unsorted old tomes, but rather an exquisite presentation for a small, heavily- curated collection of books. A showroom for books, if you will. The clerk would have read everything on sale, and be able to talk at length about all of them. You'd be matched to a book in the same way an Apple Store employee guides you to a piece of consumer electronics. Etc.

<comment><USER5> I think the important difference in customer experience is fresh edibles require a local real estate presence. I've already switched from the local bookstore, which was pure mass market and had no scifi or technical books, to B+N, to amazon, now if B+N closes why would I ever switch back from amazon prime to brick and mortar?

The other killer is amazon prime. I'm paying $70 or whatever it is, to get free shipping and no sales tax. Anytime I pay spend a penny at B+M even long after I saved my $70 from amazon, I'm still thinking... I fronted amazon $70 and I need to make it back on free shipping, and its cheaper online anyway, and I won't have time to read it until after two-day shipping anyway... so why go brick and mortar?

The other problem is, I'm pretty well read, interested in certain specialties, and 50% of salespeople are below the median anyway, so a local store is useless to me. I have special ordered books at local bookstores in the distant past; I believe they used USPS media mail and it took about three weeks plus two trips to the store. I already have amazon prime and it takes two days not three weeks. So I'll probably never buy a new book at a B+M book store again, at least not for myself. I don't know if they can survive off gift sales.

There are five interesting options going forward for bookstores:

1) Gift store that happens to sell books.

2) I donno what to call it, but the sales pitch would be "Don't pay for amazon shipping when we can get it next day air no extra charge". Of course the base price would be MSRP not amazon discount, to pay for the logistics.

3) "We print your book on demand in less than 15 minutes while you drink a complimentary coffee and its still hot when we put it in your hands"

4) "We only stock the (insert authority name)'s top 100 titles... but we know all about those 100 titles, and we never run out of copies". AKA the midnight harry potter store, more or less. Also hosts wild midnight release parties.

5) Dead street in a dead town with no customers but the rent is cheap and the owner sees it as a lifestyle business or bragging rights. Also a front for money laundering, seeing as its a cash business. Being a front and a laundry for regional weed distribution is how our local candle store kept in operation a couple years back.

<comment><USER4> How about the radio-station model?

6) "We don't sell books, or make money from customers. Instead, your eyeballs are the product, and we sell chain-wide coverage of recently-released titles (including a guarantee our clerks will read+familiarize themselves with your book) to publishing houses. We _want_ people to come in and read the book for 30 minutes and be itching to buy it on Amazon by the time they leave; that's what the publisher is paying us for."

Sort of neatens up the incentive structure, doesn't it?

(This also means they don't have to have any storage; they only need two or three pristine copies of each book to put on display. And it can even work for books that are otherwise digital-only: the only physical copies are one-offs created solely for display purposes, printed by the author's marketing agency using a service like Lulu and delivered directly to each participating book- gallery. In other words, the "books" become part of the _PR kit_ for a book launch, rather than the goods being sold.)

</comment></comment></comment></comment></comment><comment><USER6> I think they just need to be a better bookstore. Think of Powell's in Portland OR. It's my favorite thing to do in that city and I barely ever buy/read paper books. They also have a building nearby the main one that sells only technical books.

The reason I like shopping and buying books there is the sheer selection. Of course, their footprint is much larger than BN. But BN could raise funds to expand their stores slowly and see if it works. Powell's has several floors of books and are probably larger than many large libraries in big cities. Next to each new book they also stock used books of similar or the same titles.

I just really enjoy the act of flipping through an entire book and then buying it on the spot. I don't think paging through the ToC in PDF form a la Amazon is that nice and I hate waiting for shipping. Plus, if on a technical book I'm going to spend $100 then I need to make sure for myself it's a decent reference.

It's been painful to see BN push the Nook. And to see them try to be a coffee shop. And CD store. etc etc. For the size of their store, they have a remarkably small selection of books, and they're all high-priced... and they complain they can't sell many books. Sorry, when I walk in to the store and see 4 crappy books on CSS, 10 on HTML, 5 on Windows, and a smattering of others, I'm not that inspired. But in Powell's technical bookstore, when there's a whole aisle on Javascript, I get excited.

<comment><USER7> Barnes and Noble is an inconsistent experience. For example, at the Roseville, MN store, the technical book section is usually on par with, or sometimes even better than Powell's. However, almost everywhere else, even at other locations in MN, the stores mostly suck. There used to be a couple of great Barnes and Noble stores in Manhattan, but they have closed.

<comment><USER8> I imagine that's greatly influenced by the purchasing habits of the local customers: in Gettysburg? Beef up the Historical section.

</comment></comment></comment><comment><USER9> One that's not quite on their list is boardgames. B&N is pushing more of those for the higher margin, but they do little to nothing to get gamers into the store. They should be the ones partnering with Tabletop, not Target. Sponsor BoardGameGeek somehow. Host gaming meetup groups. Provide store copies of games for trial.

</comment><comment><USER10> These are awful tips and don't prevent the retail problem of showrooming. Even if BN is cheaper than Amazon, you can't beat the convenience of buying stuff from your laptop in bed.

They need to draw people into their stores AND make them spend money. A lot of these tips are just about getting freeloader traffic.

<comment><USER11> I think there is future in the showroom model, and not just for bookstores. To make it work, showrooms should rotate stock aggressively, to the point of moving in and out a tractor trailer a day. And, there should be dates on the displays to indicate how long they will be in the showroom. The stock would have to be compelling enough that you would tell your friends about it and they would visit. The showroom itself would have to be a spectacle.

If anyone ever cracks same day delivery, it would align very well with this. Onsite fabrication would align well too.

</comment></comment><comment><USER12> How about: lower your prices. Seriously, have you been to a Barnes and Noble recently? If they have any hope of competing with Amazon, or even other local book stores, then the prices have to go down. Attempting to sell books at MSRP is a death sentence.

<comment><USER13> That's a nice idea, but in reality a B&H branch has more overhead than an online bookstore. Rent, electricity, local taxes, cleaning, and even transport costs (e.g. moving books in and out of stores).

So while I'm sure B&H could 1:1 match Amazon in prices, with Amazon's economies of scale, and the tax loopholes online retailers get, I highly doubt a B&H store could do it and still be profitable.

So, yes, lower prices. Just give the books away. It will get people through the doors, no doubt, but they'll still go bankrupt.

<comment><USER14> FYI, B&N is a bookstore - B&H is an electronics store run by Hasidic Jews: [http://en.wikipedia.org/wiki/B%26H_Photo_Video](http://en.wikipedia.org/wiki/B%26H_Photo_Video)

:)

</comment></comment></comment><comment><USER15> I think the best idea would be STOP refusing to sell! Yay!

You know, I am fan of a certain niche sci-fi series. Buying physical books is hell expensive (shipping get outrageous), so I buy e-books!

Except, this niche sci-fi series was only available at Fictionwise to me (it was in B&N, I tried to buy there, it made me fill lots of forms, and then install a local Nook software, and do some other annoying things, and THEN finally it told me they don't sell it outside the US... why the hell it allowed me to register as Brazillian then? fuck you B&N).

Fictionwise was great, it allowed me to get the book in multiple formats, make backups without DRM, and lots of other nifty stuff!

Then comes again B&N to ruin my party, they buy Fictionwise, and send a message stating that all Fictionwise books will only be available in Nook format, and you must download them from the US...

I even went into their FAQ site to be sure...

"Q: If I have a Fictionwise book and a Nook, and I want download it but I live outside the US, what can I do?

A: You can go to the US, then connect in a network there, download your book, and go back home."

OMG FUCK YOU AGAIN B&N!!!!!

By the way, if someone know someone that replaces Fictionwise I would be REALLY HAPPY to know (you know, I still want those books, and I won't visit US only to buy those books...)

<comment><USER16> Well, not that I endorse fictionwise or whatever that service is, but if you want that content you can likely just proxy your traffic into the usa with a VPN or similar.

<comment><USER15> I don't have a Nook anyway.

And you cannot buy from outside the US even with a proxy (you need proof that you have a house, or a bank account, or something like that in the US).

</comment></comment></comment><comment><USER17> At some point a decade or so ago, they could have been relevant to me by increasing the size of their science & engineering book selection. Instead, they increased the "holistic healing" and "better dieting through fantasy" sections while shrinking science & engineering books to a few tiny feet of shelf space. They made their bed.

<comment><USER18> I've noticed that to correlate with local population. E.g., University towns having plenty of great Dover prints on Algebraic Topology versus my mid- Michigan industrial boomtown mostly having a huge Spiritual/Christianity section.

</comment></comment><comment><USER19> I frequently shop at Barnes & Noble, and I have a membership. (There's one just down the street.) I like the experience of going to bookstores, so I consider whatever premium I pay a donation toward keeping that experience a few blocks away. In reality it is the equivalent of a small monthly fee.

<comment><USER20> Not to knock B&N but I figured they were on their last legs in my area when my public library started allowing coffee drinking. I have to pay the small monthly tax regardless, after all. I've had a good success rate finding current books I want at the library. When they don't have it I'll usually check the nearby B&N and pay the premium over Amazon.

</comment></comment><comment><USER21> Physical markets absolutely do have a great quality of discovery and discoverability that online markets simply don't have.

Further, I'm one of the (rare?) techies who prefers paper books.

If there are enough people who like discovering books (like me), then brick & mortar bookstores have a future.

<comment><USER22> This is only true to the extent that they can monetize that discoverability. The problem is that Amazon can freeload by offering a lower price without facing the high costs of retail real estate, etc. and people will discover books at B&N but buy them on Amazon.

</comment></comment><comment><USER23> The best response to this is probably Larry the Liquidator's speech to shareholders of New England Wire & Cable, Inc., a fictional company in the movie "Other People's Money"[1]:

 _Amen, and amen, and amen. You 'll have to forgive me, I'm not familiar with the local custom. Where I come from, you always say 'Amen' after you hear a prayer. Because that's what you just heard - a prayer. Where I come from, that particular prayer is called 'The Prayer for the Dead.' You just heard The Prayer for the Dead, my fellow stockholders, and you didn't say, 'Amen.' This company is dead. I didn't kill it. Don't blame me. It was dead when I got here. It's too late for prayers. For even if the prayers were answered, and a miracle occurred, and the yen did this, and the dollar did that, and the infrastructure did the other thing, we would still be dead! You know why? Fiber optics. New technologies. Obsolescence. We're dead, alright. We're just not broke. And do you know the surest way to go broke? Keep getting an increasing share of a shrinking market. Down the tubes. Slow, but sure.

You know, at one time, there must've been dozens of companies making buggy whips. And I'll bet the last company around was the one that made the best god-damn buggy whip you ever saw. Now how would you have liked to have been a stockholder in that company? You invested in a business and this business is dead. Let's have the intelligence, let's have the decency to sign the death certificate, collect the insurance, and invest in something with a future. 'Ah, but we can't,' goes the prayer. 'We can't because we have responsibility, a responsibility to our employees, to our community. What will happen to them?' I got two words for that - 'Who cares?' Care about them? Why? They didn't care about you. They sucked you dry. You have no responsibility to them. For the last ten years, this company bled your money. Did this community ever say, 'We know times are tough. We'll lower taxes, reduce water and sewer.' Check it out: You're paying twice what you did ten years ago. And our devoted employees, who have taken no increases for the past three years, are still making twice what they made ten years ago. And our stock - one-sixth of what it was ten years ago. 'Who cares?' I'll tell ya -- Me.

I'm not your best friend. I'm your only friend. I don't make anything. I'm makin' you money. And lest we forget, that's the only reason any of you became stockholders in the first place. You wanna make money! You don't care if they manufacture wire and cable, fried chicken, or grow tangerines! You wanna make money! I'm the only friend you've got. I'm makin' you money. Take the money. Invest it somewhere else. Maybe, maybe you'll get lucky and it'll be used productively. And if it is, you'll create new jobs and provide a service for the economy and, God forbid, even make a few bucks for yourselves. And if anybody asks, tell 'em ya gave at the plant. And by the way, it pleases me that I'm called 'Larry the Liquidator.' You know why, fellow stockholders? Because at my funeral, you'll leave with a smile on your face and a few bucks in your pocket. Now that's a funeral worth having!_

\--

[1] [http://www.imdb.com/title/tt0102609/](http://www.imdb.com/title/tt0102609/) \-- a clip of the speech is currently available at [http://www.youtube.com/watch?v=62kxPyNZF3Q](http://www.youtube.com/watch?v=62kxPyNZF3Q)

<comment><USER5> B+N is an even worse scenario, in that a buggy whip company can pivot into the lucrative adult toy market with little change other than inside the marketing dept.

"Expensive used paper retail" aka bookstore has no pivot options not already supersaturated. Coffee shop? Music/Video physical media store? Toy store? "Educational kids stuff" store? Generic department stores? Gift shop? Used book stores? All full marketplaces, or in decline, or both. B+N has been pretty good at picking trendy overdone and declining sectors to expand into. I think they need a in-house residential real estate office and a cupcake shop.

Their only hope seems to be outlandish. So they've got big mall stores... I know, give up on all this "book" stuff and become Tesla Automotive Dealers. Keep the coffee bar, I guess. My local B+N is architecturally beautiful compared to local car dealerships; it could work out well.

Larry's speech is pretty much the opposite of modern crony capitalism's "too big to fail". Its possible the only move left for B+N would be into govt bailout/jobs programs.

<comment><USER24> I disagree. Some of the ideas in TFA are fairly novel. Hiring people who are actually knowledgable? What a concept! Imagine walking into a Barnes and Noble and getting suggestions on a boom to read? Or there being a real actual community of readers congregating in B&Ns? These are huge holes in the market, where people are willing to pay more for an "experience".

<comment><USER5> I would respectfully point out, being somewhat older, that we had local bookstores (and we had more of them...) before B+N arrived, and long after B+N closes we'll still have local bookstores. They're not doing that great financially, and the suggestions for B+N vaguely correspond to what local bookstores have already tried. I think I've pretty much seen it all WRT bookstores.

The problem with "experience" is it takes up space where books used to be sold. So you end up with a coffee shop, and wifi, with live music, and D+D/Pathfinder RPG get togethers, and author signing visits, an internet cafe, wedding receptions, and dvd sales, and ... where's the books? Had to take them out to make space for the candle shop and onsite child care center... Not much of a bookstore anymore if walmart has a better quantity and selection.

One good rule of thumb is to look up and down small town main street. If you're going to try 50/50 pirate shop and bookstore, you're not going to do better than the actual pirate shop store, and you already know 50% of the model (bookstore) doesn't work. Ditto candles, antique stores, herbal soaps, or chocolate candies... simply listing an inventory of small town shops is mostly going to result in lack of focus on multiple business models. None of which are doing all that well anyway.

On a macro level, since I was a kid, total retail CRE square footage per citizen has roughly doubled, but median consumption patterns haven't kept up making aggregate brick and mortar retail per citizen drop, and the long term trend isn't looking good for retail. There's a lot of stores to close before we get back to long term trend for retail store CRE. It may very well be that nationwide big box booksellers simply don't "work" in a real economy. In a contracting market, aiming at shrinking holes is like picking up pennies in front of a steamroller.

</comment></comment></comment></comment><comment><USER25> I have a family member who has worked at B&N for 16 years, and is continually worried about the health of the company. Some of the big issues are:

1\. Employee pay and retention. Retail always pays shit, but if you want good employees, you have to pay them.

2\. Re-zoning continually. B&N spends an inordinate amount of labor re- organizing and shuffling books from one area to the other. This make work makes it hard for customers to find books, makes it hard for associates to know where a book is, and is just shuffling deck chairs.

3\. Pricing. BN.com is cheaper than B&N stores. Customers don't understand this, causing huge amounts of irritation. Plus, B&N is just charging too much.

4\. Delivery/inventory. Order a book from Amazon, you can have it tomorrow. Order it from B&N or bn.com, and it might take a week. All deliveries are made from central warehouses, instead of leveraging the store's own inventory.

A smart fix for this would be to have the delivery manager able to deliver books from his inventory overnight to the customer. If you're in San Jose, a San Jose B&N would fulfill your order, (assuming the book is in stock), otherwise the closest warehouse or store would. Naturally, Amazon is the exemplar when it comes to order fulfillment, but at least try and close the gap.

Cut some of the deadweight management. A district manager who only shows up in your store once or twice a quarter is of no use to the company. Fire them or make them perform.

</comment><comment><USER26> The only bookstores I want to save are the ones that closed 15 years ago.

</comment><comment><USER27> All retail faces this problem. B&N got their first, despite having diagnosed the problem early and made a try at a solution. They didn't execute that solution very well, which is why they still face the problem.

The problem is: It's better to get almost anything delivered to you than to spend time and gas going to the store. On top of that the selection is better online.

The pity is that bookstores have obvious attractions other than being a place to buy the fat end of the the very long tail of books. Nobodying is going to go to Sears to meet the washing machine designer, but they will go to B&N to meet an author. Nobody wants live music at the Home depot but at B&N, maybe. Nobody would go to a LAN party or board game night at the hardware store, but B&N?

These might all fail, but B&N could have put up more of a fight: Kindle LAN party? Did they even try?

</comment><comment><USER28> These ideas are all contradictory. What a pointless article. Throw a bunch of random ideas in the air and see what sticks. If B&N fails, you can point to all the ideas they didn't follow and blame the failure on that. If B&N succeeds, you can point to the ideas they did follow (for these ideas cover the entire universe of possible action, so they will end up following some of them just by chance) and claim credit.

Dumb.

<comment><USER29> > _These ideas are all contradictory._

Yes.

> _What a pointless article._

No, you missed the point.

<comment><USER28> I don't suppose you'd care to tell me what point I supposedly missed? Because just telling me I missed the point without explaining is, well, pointless.

<comment><USER30> > Over the past several days, commentators have burst forth with a cacophony > of competing ideas for your revival. The following list contains some > potentially promising options for you to consider:

<comment><USER28> Which doesn't suddenly give it a point, that just shows they're aware of what they're doing. Spamming suggestions some of which they will fall into by chance is silly.

</comment></comment></comment></comment></comment><comment><USER31> Having worked as a consultant about 3 years ago in the NYC B&N.com office across from Chelsea Market I can attest to the following:

Most of the developers are at best mediocre. The IT managers are clueless. They reside in the same building as Google and are unable to attract NYC talent.

Every time I see the stock climb above 17 or 18 I have a strong urge to sell it short.

<comment><USER32> Interesting. I did a bit of work in that office too. I was treated quite well, but did not interact with enough of the organization to say much beyond that.

</comment></comment><comment><USER33> There was not much of a fuss made when large national chain book stores killed off numerous local, community offerings. Why should I care about the death of another invasive species?

All kidding aside I really do miss the local shops that did not survive. I just don't feel the same about big national bookstores.

</comment><comment><USER5> The only reason I currently go to B+N instead of paying much less for a better reviewed and larger selection of books on Amazon is I have no idea what to get someone as a gift. Other than gift shopping I have no idea why I'd sit in a car for 30 minutes when I can just open another webbrowser tab and get a better product, cheaper.

The current organization by generic area of study does nothing for gift shopping. I need store categorization by stereotypical demographic group. "wife" or "tween boys" gift section. Maybe broken down by hobby, maybe not. Holiday and "event" selection. So... this is THE place to buy gifts made out of old fashioned ink and paper.

Their biggest problem is lack of selection. Amazon is so much bigger, and about a half of the store floor space is already non-book (toys, board games, videos, CDs, coffee shop...) They may as well give it up and become a gift store for the small segment of the population which is not functionally illiterate. Coincidentally people who are literate tend to hang out with other people who are literate, and are usually in an economic class well above functional illiterates, so its probably a good demographic to market to. They can keep their chocolate bar selection, those are good gifts. Obviously the gift card and wrapping paper racks stay. Maybe old fashioned optical disks should be kept for awhile. The rest of the addon non-book stuff can be junked. Why would I want a coffee bar when I'm shopping for a kids b-day party gift? If you've ever been inside a "hallmark store" imagine that toned down a bit with a selection of "gift books". Bland generic popular inoffensive stuff for gifts; pretty much what they've already got.

Another interesting idea is segmentation. So the general masses of the population have given up on physical trinkets and now go virtual. Selling physical CDs? In 2013? I haven't bought a physical CD at a retail store since the 90s. Well, that's OK. There's always going to be a small segment of the population who want physical stuff (aside from gifts, see above). They might increase profitability by intentionally shrinking, which is stereotypically unthinkable by the "drive it into the ground" types, but might be their best bet. As long as they don't make the big mistake of assuming 1:1 mapping between old people and luddites. The Venn diagram probably looks more like 100% of hoarders are physical buyers. Also probably lots of aspirational buyers; lots of travel guides sold, and "kids summer workbooks" and the like.

</comment><comment><USER34> Why do I go to a B&N? Two reasons: I'm buying a gift and I want to browse the coffee-table books. Or I need something immediately for work or a project.

So for me, #2 (tables, not shelves) and #7 (community franchising) would make the most sense.</comment>


Ask HN: Legality of freelancing on the side? - <AUTHOR>

I'm considering doing some freelance work on the side for the last company I worked for, in addition to my full time job as a software engineer. The companies are in different fields and, as I am in CA, I don't think it would violate my main employer's IP agreement to do some limited work on the side not using any company computers or equipment.  However, I'm not totally sure what to watch legally.  In particular:<p>1. Are there any particular legal issues I should look out for? (e.g., contract provisions or something) 2. Should I ask permission from my current company? 3. Any examples of contracts that do not require full assignment of IP? (i.e., I want to limit assignment of inventions to just the code / ideas I deliver to the company directly) <comment><USER2> Read the documents you agreed to before starting work. There have been some really nice jobs that I have had to pass on due to clauses like this which would limit my learning and earning potential when not working for them which would be unacceptable. If you see some verbiage that starts to look very confusing about what is their time and your time that is probably the clause that says they own everything you do while employed by them, especially if there is a section to list your current creations and if they are not listed or new ones are created they are the sole property of the company on or off the clock.

</comment><comment><USER3> _" Should I ask permission from my current company?"_

If you ask them for permission, you run the risk of their saying "no" and threatening to fire you if they find out you did. Better not to tell them anything unless there's actually a legal requirement to do so. And to find out what the legal requirements are, you should probably talk to a lawyer who practices employment/IP law in CA. They may be able to tell you some interesting things, like which clauses in your employment contract are not enforceable under state law (e.g., like clauses claiming that IP you create on your own time is owned by the company).

</comment><comment><USER4> If there's nothing in the contract or IP agreement with your current employer saying you can't work for other companies on your own time, and that the work you do on your own time isn't owned by them, then I don't see any legal grounds they'd have to say no to you doing this.

However, that's different from the company's general attitude they might have with you doing this. Do you find the founders or managers of the company are laid back enough that you can just casually let them know you'll be doing some contract work in your own time? If not, from personal experience, they may be the type of company to reprimand you if they find out.

I also recommend talking to a lawyer about this as they will cut right through the thorny issues and tell you what's what with your contracts.

</comment><comment><USER5> Never do side work on company time or on their equipment. I've seen someone walked out of the office for this.

Never do work that could be in the slightest view competitive.

This puts you in a fairly good ethical position. Outside this legal seems to be iffy, related to your contract specifically and where you live. I'd have a chat with HR if your willing to take a no, or not ask if your going to ignore if you get a no.</comment>


Ask HN: Are you in the Albuquerque tech scene? - <AUTHOR> Finding peers in major cities is as easy as going to a bar, but it's much harder here in Albuquerque. I know we exist here on HN, so I wanted to see if you'd share what you do here in the comments. This could be useful so any of us could collaborate or to make it easier to hire locally.
I'll start!
Skills: UI design (ex-apple), Swift, Objective-C Website: http://olliewagner.com <comment><USER2> You might be interested in Andrew Stone's CocoaCon mailing list, whose members have regular in-person gatherings to get help, show off projects, or talk shop.

[http://lists.cocoaconspiracy.com/mailman/listinfo/updates](http://lists.cocoaconspiracy.com/mailman/listinfo/updates)

</comment><comment><USER3> I live in Albuquerque and work remotely as a SRE. I know a few devs that work at RSI (a consulting firm) and do contract work for the labs.

I know RSI has occasional meetups and try to get involved with the community. I haven't been, but I know they're involved with a ABQ "tech crawl" every year. It might be worth looking in to.

</comment><comment><USER4> Is there still a hackerspace or two out there? Always liked the idea of working remote out in New Mexico

</comment><comment><USER5> My partner and I were just talking the other day about what it might be like to live in abq, what the major industries might be for tech, what Intel's got going on, etc.</comment>


Ask HN: Firefox Quantum for Android? - <AUTHOR> Why is Firefox Quantum not available for Android till now? <comment><USER2> It is intact available: [https://play.google.com/store/apps/details?id=org.mozilla.fi...](https://play.google.com/store/apps/details?id=org.mozilla.firefox_beta)</comment>


Yahoo CEO Marissa Mayer Has an Insane Severance Package - <AUTHOR> http://fortune.com/2015/12/04/yahoo-marissa-mayer-severance/ <comment><USER2> Saving Yahoo was/is a nearly impossible task. You have to do something to attract a good CEO, and this fits that bill.

</comment><comment><USER3> she has a new born and twins in the oven. and a company that didn't meet any goal.

i bet 100% of her time is now devoted to manipulating the board into firing her so she can get that obscene recision money. explaining all the articles about exactly that popping up everywhere in the media this week, when the twins are almost due.

... Hope I'm wrong, but would be clever.</comment>


Thank You, Yakkers - <AUTHOR> https://blog.yikyak.com/blog/thank-you-yakkers <comment><USER2> I mean to me this is a totally wild story from the money side.

\- Raised $73 M from notable, no bullshit VC's including Sequoia, DCM, Draper

\- Valued around $400M (results may vary)

\- Sold for <$3M

Either we don't know the whole story (>50% chance), someone fucked up royally with IP or something or everyone was pissed off about this entire situation. It's really surprising to me that the Series B folks couldn't engineer or claw back more than that, especially given the brand recognition etc...

[1][https://www.crunchbase.com/organization/yik- yak#/entity](https://www.crunchbase.com/organization/yik-yak#/entity)

[2][http://www.businessinsider.com/yik-yak-sells-to-square- for-3...](http://www.businessinsider.com/yik-yak-sells-to-square- for-3-million-bloomberg-2017-4)

<comment><USER3> Yik Yak destroyed their product the moment they introduced handles/names. That move, combined with bowing to pressure from community groups to block & de- anonymize, ruined any trust in the service.

The complete lack of understanding of their own product that they demonstrated was absolutely astounding. $3M almost sounds like too much; there's no reasonable way you can recover anything of value besides the employees in this situation.

<comment><USER4> Destroyed, to the tune of 70M?

Surely they could just issue a 'mea culpa' at that point and recommit to their previous direction? In spite of how the web acts, users can be incredibly forgiving as far as 'voting with their wallets' go - at the end of the day they'll just use whatever works, and a 'mea culpa' post would be sufficient for most to 'begrudgingly' resume using the old/familiar service? (I mean, maybe not all of them, but enough to not take such a massive hit...)

Hot damn, adding this to my 'further reading' list.

<comment><USER5> >Surely they could just issue a 'mea culpa'

They did [1], but that was 3 month later and by then it seems most of their users had moved on and forgotten about them. Plus, being an anonymous app they didn't have emails for their users, so there wasn't really any way for them to get the word out that they were reverting back.

[1] [https://blog.yikyak.com/blog/optional-handles-and-hot- feed-a...](https://blog.yikyak.com/blog/optional-handles-and-hot-feed-are- back)

<comment><USER6> I'm pretty sure everyone at my University was aware that they reverted those changes within a month, just by word of mouth. But the people who reinstalled it were greeted with a ghost town and didn't fully re-engage, so it never achieved critical mass.

<comment><USER5> I don't disagree. But I wonder if the reason it was a ghost town when people reinstalled the app was precisely because it took a month for all the users to hear about it via word of mouth. If they had been able to send an email blast out to all of their users at once, perhaps there would have been enough people reinstalling the app that day to kick start it back into popularity.

Overall I find it a fascinating case study, just because they fell so quickly. If the founders wrote a memoir I would be very interested in reading it.

</comment></comment></comment></comment></comment></comment><comment><USER7> For a good while, Yik Yak was very popular on my campus. Then when handles became mandatory, basically everyone stopped using it. Even after they back- pedaled, though, our feed was merged with several in the surrounding area, so we lost the sense of community we had with it on campus, and it never took off again.

I don't know about overall, but in my social microcosm yik yak was never able to recover its lost users.

<comment><USER8> Never used the app, never heard of it... but I'm confused by "when handles became mandatory"? Prior to that it was just anonymous chat (with optional user id)? Why would requiring handles (user id's... right?) have made such a difference?

<comment><USER9> Imagine you suddenly applied HN's posting etiquette to 4Chan. That's basically how it felt.

</comment></comment></comment><comment><USER10> As a college student, the old Yik Yak will be missed. I wish they would just change it back to what it originally was; it was very entertaining and useful that way. It's a testament to the dark side of VC's influence that this company was forced to kill their app in an ill-advised pivot just because the current model wasn't monetizing quickly enough.

<comment><USER11> Are there new apps in the space Yik Yak used to occupy? I would have imagined that void would have been quickly filled by a newcomer.

<comment><USER12> I built this: [https://dropanon.com](https://dropanon.com). Not the same but similar

<comment><USER13> How do you plan on curbing harassment? I think, after Twitter, it's just plain irresponsible to not have some kind of plan for that.

<comment><USER12> Honestly, I never thought that far ahead. The whole thing started as an experiment: "can I get something on the AppStore". I had/have no plans beyond that.

<comment><USER14> Not an insurmountable issue. The community resolves the problem by tagging the offending items much like you stick a lollipop stick in dog turd at the park. Sometimes your kid still gets shit on her shoe but then you scan the items before they are dropped, keywords, whatevs. You could reduce the problem to vanishingly small.

</comment></comment></comment></comment></comment></comment><comment><USER15> For investors, Yik Yak was a travesty. The fact that is raised nearly 9 figures along the way is yet another terrible indictment of the herd behavior found in private equity.

One thing I find interesting about this turn of events is that the person shutting the app down is Jack Dorsey. If I was an ecommerce player like Shopify or Square, disrupting social would be at the top of my list of strategic things to do. But Jack Dorsey can't really do that, can he?

<comment><USER16> > The fact that is raised nearly 9 figures along the way is yet another > terrible indictment of the herd behavior found in private equity.

How so?

An app that targets college students, shows high user acquisition, DAU, has serious potential.

<comment><USER17> Serious potential to do what? Even darling companies like snap can't figure out how to come anywhere near meeting expectations with the supposedly high value audiences they have.

<comment><USER18> They had a critical mass of users and the geofenced posting concept had a lot of potential- had they reached maturity they had a lot of monetization potential, likely in the billions over the life of the company.

In hindsight of course they should have anticipated the challenges of anonymity which are almost cliche at this point.

But Facebook and twitter have yet to introduce a geofencing option for user posts as far as I know. Maybe they will eventually.

<comment><USER3> Teens and college students hate advertising.

Sometimes targeted advertising can work. How anonymous do you feel when apps pop up ads for that thing you were searching for two nights ago on Amazon?

How many advertisers want to have their content featured next to the absolute worst thoughts people have? I regularly saw racist, sexist, homophobic, and inconsiderate content. Not to mention the sex, drugs, and underage drinking. A true advertiser's delight.

<comment><USER4> Honestly, if there were a way for their ads to be displayed there without that being seen as a faux pas (e.g. some fundamental shift in the ad network model that just makes it seem like a consequence of the browsing user's interactions with companies - it wouldn't be 'shockingly viral' news to see that racists/sexists/etc use products too) they probably would not care.

Perception is advertisers' only enemy. Once that's taken care of, they really don't care what kind of person you are as long as your money's green.

</comment></comment></comment></comment></comment></comment><comment><USER19> My favorite part of this post was how they tried to loosely tie Yik Yak to Square's mission. But they didn't beat around the bush that this was an acquihire.

I used YikYak throughout its rise, peak, and as it started tapering off. It ended up being a comibation of meme/joke reposting from Reddit combined with a lot of really vulgar low-brow content. It was entertaining for a while but only due to the shock value.

</comment><comment><USER20> It took over my campus. It replaced several twitter accounts that were specific to my school where people would DM the twitter account and then they'd post it. It used to be the first thing I checked when something happened on campus (accident, event going on, wifi goes out, etc). People went crazy for YikYak and then they added required handles and removed being able to post on/read your university's feed when you left campus. It took them way too long to change it back and people moved on.

</comment><comment><USER21> YikYak baffled me for its entire existence, their product was incredibly simple from an engineering standpoint, they had no clear route to monetization and followed in the footsteps of several apps that shut down due to bad press. (Juicy Campus, College ACB) Yet they were able to raise an insane amount of capital from several respectable VCs. If there isn't a clear answer to how does this company make a million dollars they shouldn't be able to raise multiples of that amount.

<comment><USER14> Don't know anything about it really but it seems like greed killed this yikyak thing. Why did it have to be a unicorn when it could have just been a really nice pony? It could have made money selling anonymous polling data, sentiment, zeitgeist for marketing purposes. Everybody wants to know what the young folks are getting into next.

</comment></comment><comment><USER22> Wouldn't it be nice if something like the old Yik Yak (anon one) be used for local news. Or is there anything already present in this anonymous local news space.

</comment><comment><USER23> Looks like the good old-fashioned Facebook confessions pages will be around for quite a while longer...

</comment><comment><USER24> In Germany/Europe there's basically a clone called Jodel and it's filled with shitty, reposted jokes and I'd say usage is declining too. They also do not have a monetization model, there aren't even any ads in the app.

<comment><USER25> I'm studying in Germany and Jodel is in my experience astonishingly popular among students. At a University with about 40.000 students there is an active community of 1000-4000 users and definitely more group communication than on Facebook or another place online. I'm curious how the will be monetizing as well but I do not see the decline you are speaking of.

</comment></comment><comment><USER26> I think the potential for this app was very high, but their awful, downright stupid product decisions played a large hand in their downfall (or at least expedited it) - removing anonymity (the main selling point of the app), constantly fucking around with "The Herd" feature, the list goes on.

I remember seeing these things roll out and being so frustrated at whoever thought they were a good idea and the downfall of a solid app / community in the process.

</comment><comment><USER27> Recalling the history of YikYak and it's problem in dealing with anonymity reminded me of this video: [http://www.gdcvault.com/play/1024060/Still-Logged- In-What-AR](http://www.gdcvault.com/play/1024060/Still-Logged-In-What-AR)

YikYak's struggle reflects a decade's worth internet troll evolution between Facebook and YikYak. At Harvard there was no iPhone, no precedents from Twitter, no standard arsenal trouble-making tools in the hands of college students.

</comment><comment><USER28> So... what's going on? are they shutting it down? if so, why don't they just say, "we're shutting it down". Why make me read 6 shitty paragraphs and in the end I don't know what the fuck I'm reading?

good fucking riddance

<comment><USER29> Why not show some understanding for the people who worked tirelessly to pursue a common goal that's now come to an end, and their most loyal users who are going to be sad to see it go. As someone else said, nobody forced you to read the "6 shitty paragraphs". It's almost like you're throwing a tantrum at a parent who posted a longwinded obituary in the newspaper for their kid.

<comment><USER30> Yes, what a selfless act of charity those people undertook in exchange for mere hundreds of thousands of dollars a year. Let us have a moment of silence for the millions of man-hours selflessly donated to this organization, which was founded by Mother Theresa herself.

This unassailable high ground certainly warrants six paragraphs of pointless our-incredible-journeying, especially as they go on to describe the future of the organization as 'tinkering around.'

<comment><USER29> I never alluded to their journey being selfless or charitable...

Just because the team partially did this for profit, doesn't mean they didn't work their asses off and are now sad to shut it down. Nor does it discredit the claim that some of their users are going to be very sad to see it go. That was my point.

</comment></comment></comment></comment><comment><USER31> I wish they had just immediately shut it down. The feed is nothing but racism right now since presumably all the moderators have stopped caring.

</comment><comment><USER32> Yik Yak is still very popular on my campus and it's one of the five apps that I use everyday. Very sad to see them go.

<comment><USER33> Which university is that? It died at ours already a few months ago :(

</comment></comment><comment><USER34> Swiflie seems like an up and coming alternative. They're kind of like yak meets twitter meets reddit.

<comment><USER35> peacheszero aka "swiflie" you're not fooling anyone. (Making multiple new HN accounts to advertise your app.)

</comment></comment><comment><USER36> What an Incredible Journey!

<comment><USER37> Of course, there is the mandatory tumblr: [https://ourincrediblejourney.tumblr.com/](https://ourincrediblejourney.tumblr.com/)

Even if it is sincere (most of the time, it is), there are words or expressions that "tags" an end-of-company-life corporate post very quickly.

<comment><USER38> One thing I've concluded is that it can be sincere while at the same time not accounting for their employees blood pressure during the decline.</comment></comment></comment>


Cracking the Guess Who? Board Game - <AUTHOR> https://chalkdustmagazine.com/blog/cracking-guess-board-game/ <comment><AUTHOR> As we played this old favourite a lot over Christmas, I was wondering about optimal strategies, and found this link.</comment>


Show HN: Twitch Plays Pokemon ASCII Edition - <AUTHOR> http://pokemon.boner.io/

<comment><USER2> This is fantastic! How long did it take to put together? (also... ya, might want to move to a different domain).

<comment><AUTHOR> about 2 days of hacking and lots of irc chatting

</comment></comment><comment><USER3> Cool project, unfortunate domain name.

<comment><AUTHOR> its pronounced like the last name of the famous drummer of led zeppelin, not the male body part. its my dogs name :)

<comment><USER4> Considering we're all still arguing the 'jiff' vs 'gif' battle, I'm not so sure pronunciation is the internet's strong suit.

<comment><USER5> There's no argument. 'jiff' is simply incorrect. Regardless of what the person who invented the format says.

<comment><USER4> My point exactly.</comment></comment></comment></comment></comment>


Give me some iPad app ideas - <AUTHOR>

title says it all <comment><USER2> The cynical part of me says "woopie cushion". It'd serve the dual purpose of being a wildly successful fart app, and would alert you if you were to ever accidentally sit on your iPad, and wouldn't actually require much in the way of effort.

</comment><comment><USER3> x10 and home automation.</comment>