Why doesn't Microsoft out-innovate Apple? - <AUTHOR> http://techblog.dallasnews.com/archives/2008/04/why-doesnt-microsoft-outinnova.html <comment><USER2> Speaking from experience, innovation is VERY difficult to achieve from within the Microsoft organization. It's not impossible. It's just hard. Microsoft is a collection of loosely related fiefdoms linked at the VP level, which is easily 8 or more reporting levels above the normal joe level of software engineers and PM's. You need to have the ear of some very important people to get things done, which just probably won't happen for most.

Innovative organizations seem to be of two types: a) top down design leadership like Apple, or more likely b) bottom up environment that allows innovation to happen organically. SteveB and most of the VP's don't have the product design gifts Steve Jobs has, so A is out of the question. Unfortunately, Microsoft is so large and un-agile that B is impossible as well.

<comment><USER3> I wonder how did .NET thing worked out? Someone decided to bring Anders Hejlsberg on board and give him absolute freedom.

It was quite impressive for a company of Microsoft's size to create something like that from scratch.

</comment></comment><comment><USER4> I'd absolutely agree with rantfoil and damon, but here's another reason why (and I own and love a Mac, for the record):

 _Fanboys._

I'm not kidding. Microsoft can innovate well (and they have in the past) and they'll always have an _evil_ stigma around them. Apple, whatever they do, mostly has an "everything Apple does is awesome and good" while glossing over the things Apple has done wrong.

Granted, Apple's done some great stuff. But I'll say this: when Apple releases a Tablet PC, fanboys will praise it even though if it is with similar functionality to Microsoft's Tablet PC, and will cause the inertia to start and people start pointing out the obscure flaws in Microsoft's Tablet PC and talk about how amazing Apple's is.

I'm being absolutely serious here. It's something that's akin to the Google/Yahoo! competition also. Fanboys and the people that they influence have a great effect on a company's desire to innovate.

<comment><USER3> Good companies can create fanboys and not-so-good can lose them seemingly overnight. Believe it or not, there were quite a few Microsoft fanboys just 10 years ago, I was one of them: it was a great place to work in early 90s and they kicked everyone's ass on engineering battleground: Netscape, Borland and IBM can whine all they want, but the technology behind NN4, Borland compilers and OS/2 couldn't handle Microsoft's will to compete.

... while Apple was considered to be technically inferior (and it was) overpriced junk for seniors.

When you turn these tables around, that's called innovation: not just 100% technology, but design and marketing as well.

</comment></comment><comment><USER5> It isn't that Apple has better designers or programmers, but they have a culture that thrives on quality, innovation and just plain building better products than the competition. Here's a great post on that: [http://www.adaptivepath.com/blog/2007/07/05/how-many-of- your...](http://www.adaptivepath.com/blog/2007/07/05/how-many-of-your-teams- ideas-are-in-the-iphone-2/)

"... [Apple] is a company with leadership who has the fortitude to take the risk, find the budget, and push the technology for the single cause of designing compelling user experiences. Apple got it right."

</comment><comment><USER6> There are a lot of people in Microsoft with a wide range of skills. Give MS employees 1 day a week to work on there own special projects and create a "Microsoft labs" page and they would get some great stuff created. But I believe that MS likes to have ideas flow from the top instead of from the bottom/middle. People at the top (likely) want to protect there position, so they do not allow people to "stand out" in any way.

</comment><comment><USER7> A big part of Microsoft's R&D is paying people like Erik Meijer to not work for someone Microsoft is competing with.

</comment><comment><USER8> Innovation takes more than deep pockets...

<comment><USER9> Alan Kay (guy who invented the window and other GUI goodies while at PARC) once said that innovation really isn't that difficult to achieve -- you just need to rub smart people and money together.

</comment></comment><comment><USER10> they just need a steve jobs like person. I don't even like apple but you need to have a guy who can make large decisions and also have a vision of the ways things need to work. If the people in charge are not already like that they will not jump at the chance to give up their power to some one else.

</comment><comment><USER11> _Yet Apple seems to deliver far more innovative products to market_

Keyword: Seems.

Yes, if you're preaching to the converted, that's proof enough, but Apple has rebadged BSD and has gotten a large degree of success through a remake of a 1979 device, the Sony Walkman. But those aren't really innovations at all. Shiny object!=innovation. I don't know how else to put it.

Here's microsoft's research page,

<http://research.microsoft.com/research/default.aspx>

Here's, umm, Apple's

<http://www.apple.com/education/research/>

...or, at least, that's the 1st link for the search query, "Apple Research":

 _Hmm, the page you're looking for can't be found._

A 404.

<comment><USER12> Upon Steve Job's return one of the many decisions he did was to axe the Research group within Apple. His explanation was simply: no one does R in the valley anymore. The sole survivor of that group was QuickTime while over the years what Apple has always excelled at has been development and an eye for seeing innovation and bring that home.

iPod: contracted.

iTunes: bought.

Most of the pro tools: bought.

Computers: integration of OEM parts.

Displays: rebadged.

And they've been able to gain marketshare like crazy and release products that people lust for. On the consumer front what has Microsoft presented to the world even with their massive research division? Talking Barney dolls? A house full of quirky tech they keep showing off every chance they get? Surface? Zune? Xbox?

<comment><USER9> "iPod: contracted."

The physical manufacturing, yeah, but I'm pretty sure the hardware designers are Apple employees.

"iTunes: bought."

The basis for it was purchased, yes. It was nothing like it is now.

The thing with Apple is that they tend to take germs of ideas and see them through to full realization. Mac OS, you could say, was just a clone of the OS that ran the Xerox Star. But the Star's OS was crude compared to the Mac's (even in the earliest versions).

<comment><USER12> Tony Fadell started out as a contractor here at Apple. He brought him his designs for a media player and a team merged that with the small hard drives that Hitachi was peddling and from there on it grew into the original iPod prototype. Tony is now a VP.

iTunes was bought, sure the codebase (rebooted from 4.0 and onward) is different but it was bought in. Just like almost all the pro tools and that has now since been revamped.

My point still stands: after Steve Jobs came back what Apple has really done well is taking parts/ideas off the shelves and developing them into wonderful consumer products.

<comment><USER9> The innovation people are talking about is in taking germs of ideas and making them blossom into full potential -- that includes developing new ideas along the way. Just like Mac OS came from the Star.

</comment></comment></comment></comment></comment><comment><USER12> Speaking from experience, it's the ability Steve Jobs has to merge benevolence with good design. It's a mission and within the DNA of Apple to bring to the world good designs, intuition, and stuff that just works.

At the end of the day it's just computers but when imbued with the idea that through computers peoples' lives are easier, more efficient, and more fun, you just attract people willing to work harder and longer and wanting to change the world.

Sappy, yes, but it works.

</comment><comment><USER9> Steve Jobs summed up his opinion on why this is:

The only problem with Microsoft is they just have no taste, they have absolutely no taste, and what that means is -- I don't mean that in a small way, I mean that in a big way, in the sense that they they don't think of original ideas and they don't bring much culture into their products. And you say, "why is that important?" -- well, you know, proportionally spaced fonts come from type setting and beautiful books, that's where one gets the idea -- if it weren't for the Mac they would never have that in their products and so I guess I am saddened, not by Microsoft's success -- I have no problem with their success, they've earned their success for the most part. I have a problem with the fact that they just make really third rate products.

(from Triumph of the Nerds)

</comment><comment><USER13> My biased guess is that Microsoft is concentrating too much on forcefully extracting money from whereever it can.

Apple has obviously concentrated on making things that people would actually _want to_ use. The truckloads of money they're raking in is just an (intentional) side-effect.

The plan with Vista was to ram it down everyone's throat through Microsoft's monopoly position, but where is the added value for the users?

Leopard received a much warmer response. Fanboys, yes, and bugs, but still - it's something that people want to use.</comment>


V8 developers start working on ES6 generators for JavaScript - <AUTHOR> http://code.google.com/p/v8/issues/detail?id=2355

<comment><AUTHOR> Note the opportunity here: all your promises code immediately turns into this: <http://taskjs.org/>

<comment><USER2> JS next seems almost as if they turned Javascript into Python. I am pleased.

<comment><USER3> I wish V8 already had generators back when node.js started. It would've been a true solution to callback hell. There's libraries like async to help with that, but it's not as good as something like tasks.js could be.

<comment><USER2> But on the other hand Twisted is not a panacea either, not that this is a perfect parallel or anything. But I agree, this is definitely a step in the right direction.

I wonder if it will be feasible to code in JS Next and have a compiler step somehow take care of backporting. Probably not.

</comment></comment></comment></comment><comment><AUTHOR> Andy Wingo mentioned via twitter that he's working on it: <https://twitter.com/andywingo/status/316644148532891648>

<comment><USER4> Bloomberg is sponsoring Igalia (Andy) to implement ES6 generators in V8 :)

</comment></comment><comment><USER5> Ahaha, finally!

I have been waiting to use this feature on the web, well, since Mozilla implemented it, which must have been at least 5 years ago.

<comment><USER6> Why didn't ecma just use Mozilla's implementation?

<comment><USER7> The spec is quite closely modelled after Mozilla's implementation, yes. Other engines just neglected to implement it.

<comment><USER8> > Other engines just neglected to implement it.

Why would they have? Seems like waiting for ecma approval and specification makes sense.

<comment><USER7> Sure, I didn't mean they did something wrong.

Although it is quite obviously a good idea :)

</comment></comment></comment></comment></comment><comment><USER9> In the mean time you can use fibers with Node. I've been using them for StartHQ (<http://starthq.com>) via Common Node (<https://github.com/olegp/common-node>) and to be honest I don't see how I could have made it maintainable with promises, let alone no flow control library at all.

<comment><USER10> Agreed. Fibers are a great way to take simple synchronous-looking code and make it play well with the rest of node, without resorting to threads.

</comment></comment><comment><USER11> A bit offtopic, but: are all chromium & V8 team members Googlers? just wondering, chromium and V8 are both open source, but I've never head of any major contributors other than Google itself.

<comment><USER12> From what I gathered (ie. talking to mraleph) v8 is mostly just Google employees. I can't speak about Chromium. The contributor situation is not vastly different for SpiderMonkey or JSC. I am usually the only contributor, besides 1-3 others that sometimes work on SpiderMonkey.

Edit: I think some ports are maintained from people outside Google. It's not really easy to tell, because most people have @chromium addresses.

<comment><USER13> MIPS port is fully maintained by MIPS people. These days they even have commit rights.

You can see full list of people and organizations that contributed to V8 in the AUTHORS file.

</comment></comment></comment><comment><USER14> I've been really looking forward to this ever since I saw this post[1] on the possibilities that coroutines introduce for async programming.

This article in question was already discussed in some depth on HN[2].

Can't wait for an era of much more elegant async code!

[1] <http://syzygy.st/javascript-coroutines/>

[2] <https://news.ycombinator.com/item?id=4912413>

</comment><comment><USER15> The es wiki page linked in the bug doesn't say much about array/generator comprehensions, e.g.:

[for (x of a) for (y of b) x * y]

but those would be really nice as well.

A few months ago the ES committee decided to switch them from reading right- to-left (as in spidermonkey comprehensions, python, and haskell) to reading left-to-right (as in C#):

<https://gist.github.com/dherman/b250d1fad15dbb5f77a5>

</comment><comment><USER16> I'd love to use this for cooperative multitasking inside one thread (like in Python example using yield). Would be great for simple scripts for ai in games.

</comment><comment><USER17> So who do we have to pay to get this turned on by default, instead of behind a flag?

</comment><comment><USER18> PHP gets yield, now JS too?

You'd think it would be the other way round!</comment>


Optimization story: Switching from GMP to gcc's __int128 reduced run time by 95% - <AUTHOR> https://www.nu42.com/2016/01/excellent-optimization-story.html <comment><USER3> FWIW, __int128 and the optimizations mentioned works in clang too, my guess is that the author just runs an old version.

        #include <stdio.h>

        int main() {
        	FILE *fp;
        	__int128 v=1234;

        	fp = fopen("foo12", "w");
        	fwrite(&v, sizeof(v), 1, fp);
        	fclose(fp);

        	return 0;
        }

with -O2 -march=native -ffinite-math-only -fno-math-errno, for clang 3.5.0, linux/amd64, gives me:

        4005d0:	53                   	push   %rbx
        4005d1:	48 83 ec 10          	sub    $0x10,%rsp
        4005d5:	48 c7 44 24 08 00 00 	movq   $0x0,0x8(%rsp)
        4005dc:	00 00
        4005de:	48 c7 04 24 d2 04 00 	movq   $0x4d2,(%rsp)
        4005e5:	00
        4005e6:	bf b0 06 40 00       	mov    $0x4006b0,%edi
        4005eb:	be b6 06 40 00       	mov    $0x4006b6,%esi
        4005f0:	e8 bb fe ff ff       	callq  4004b0 <fopen@plt>
        4005f5:	48 89 c3             	mov    %rax,%rbx
        4005f8:	48 8d 3c 24          	lea    (%rsp),%rdi
        4005fc:	be 10 00 00 00       	mov    $0x10,%esi
        400601:	ba 01 00 00 00       	mov    $0x1,%edx
        400606:	48 89 d9             	mov    %rbx,%rcx
        400609:	e8 b2 fe ff ff       	callq  4004c0 <fwrite@plt>
        40060e:	48 89 df             	mov    %rbx,%rdi
        400611:	e8 6a fe ff ff       	callq  400480 <fclose@plt>
        400616:	31 c0                	xor    %eax,%eax
        400618:	48 83 c4 10          	add    $0x10,%rsp
        40061c:	5b                   	pop    %rbx
        40061d:	c3                   	retq
        40061e:	66 90                	xchg   %ax,%ax

<comment><USER4> ...and both compile a 128=64×64 multiplication into a single imul.

        __int128
        mult128(int64_t a, int64_t b)
        {
        	return (__int128)a * (__int128)b;
          a0:	48 89 f0             	mov    %rsi,%rax
          a3:	48 f7 ef             	imul   %rdi
          a6:	c3                   	retq

<comment><AUTHOR> I have:

        Apple LLVM version 7.0.0 (clang-700.1.76)
        Target: x86_64-apple-darwin15.0.0
        Thread model: posix

I did mention that the _same_ source code when compiled with gcc runs faster in a Linux VM than when it is compiled with clang and run in OSX. That means, some of those optimization options either do not mean anything or do not work as well when using clang.

</comment></comment></comment><comment><USER5> I ran into the need for this recently, except for a program written in Java... I really wish the JVM had a 128 bit data type (or at least a muldiv function, in which muldiv(a, b, c) = a _b /c, but the intermediate a_b result can exceed 64 bits.

<comment><USER6> write one? it's simple algebra.

<comment><USER7> Your homegrown object wouldn't have any special meaning in the JVM and wouldn't be able to be optimized as a 128-bit integer.

<comment><USER8> Parent probably means writing the muldiv function, which would return a "basic" 64bit int.

</comment></comment></comment></comment><comment><USER9> I am just curiosu why gcc's __int128 is that faster than GMP.

<comment><USER6> GMP is arbitrary precision. __int128 on a 64 bit processor is optimized for one size.

<comment><USER10> It's actually even better than that. They're only using __int128 to hold the result of a 64 by 64 bit multiplication, and x86_64's mul instruction will give you this for free. gcc is smart enough to generate code that is literally just a single mul.

</comment></comment></comment><comment><USER11> Given N, introducing q=10^N, they are looking for a and b in [0,q) such that

      (q+2a)^2-(2b-1)^2 = q^2-1

For example, for N=1, q=10, given 18^2 - 15^2 = 99, we find a solution with a=4, b=8: 48

That suggests using [https://en.m.wikipedia.org/wiki/Midpoint_circle_algorithm#Va...](https://en.m.wikipedia.org/wiki/Midpoint_circle_algorithm#Variant_with_Integer- Based_Arithmetic) to get rid of that pesky square root (circle drawing uses sums of squares, but I think that is trivially adjusted for)

I also think it is worthwhile to extend this to other bases, as it more easily produces more examples to look at for discovering structure, and gets rid of the arbitrarily chosen number 10.

Edit: for those needing some explanation how to get at that claim:

      let q > 0

(they pick q=10, q=100, q=1000, but this generalises this)

Assume

      aq+b = b^2 - a^2 for some a,b in [0,q]

in other words: b^2-a^2, written in base q, is ab

Then:

      b^2 - a^2 = qa+b                          <=> (bring all b's to the left, all else to the right)
      b^2 - b = qa + a^2                        <=> (factor)
      b(b-1)  = a(a+q)                          <=> (using (p+q)(p-q) = p^2-q^2)
      (b-1/2)^2 - (1/2)^2 = (a+q/2)^2 - (q/2)^2 <=> (multiply by 4 on both sides)
      (2b-1)^2 - 1 = (2a+q)^2 - q^2             <=> (bring all a's and all b's to the right)
      q^2 - 1 = (2a+q)^2 - (2b-1)^2             <=> (switch sides; slight rewrite)
      (q+2a)^2 - (2b-1)^2 = q^2-1

Edit 2: for large q, it probably is faster to do the (p+q)(p-q) = p^2-q^2 trick again (apologies for naming the free variable q the same as the q introduced earlier), and get:

      (q+2a+2b-1)(q+2a-2b+1) = q^2-1

Next, factor q^2-1, write all ways to write it as product of integers, and check each case for integer solutions for a and b in the right range. For example, for q=10, we have:

      99 = 1x99 = 3x33 = 9x11 = 11x9 = 33x3 = 99x1, so we solve 6 systems (I guess one easily discard half of them on arguments of the p+q part being larger than the p-q part, but that's peanuts) of two linear equations in two variables:

      / q+2a+2b-1 =  1
      \ q+2a-2b+1 = 99

      / q+2a+2b-1 =  3
      \ q+2a-2b+1 = 33

      …

      / q+2a+2b-1 = 99
      \ q+2a-2b+1 =  1

This also suggests that the number of solutions with d base q digits for a and b is correlated with the number of integers that divide q^2-1. That would link it to [http://oeis.org/A000010](http://oeis.org/A000010).

Edit 3: and for the 10^N case, one might consider [http://oeis.org/A095370](http://oeis.org/A095370). For example, the 62-digit number 1111…1111 has only 5 prime factors. You have to add 2 factors of 3 to get 9999…9999, so 10^62-1 can be written as product of two integers in 2^7 ways => only 2^6 = 64 equations to solve.

<comment><AUTHOR> Interesting idea. Thank you. I'll try that out.

<comment><USER11> In Python:

      q = 10000000000
      n = 11111111111111111111
      factors = [3, 3, 11, 41, 101, 271, 3541, 9091, 27961]

      q10 = q/10

      bits = len(factors)
      #print b
      #print 11*41*101*271*3541*9091*27961
      for i in range(2**bits):
        r = 1
        s = 1
        for j in range(bits):
          if i&(1<<j):
            r *= factors[j]
          else:
            s *= factors[j]
        # To solve:
        # q+2a+2b-1 = r
        # q+2a-2b+1 = s
        # q+2a = (r+s)/2
        # 2b-1 = (r-s)/2
        #
        # => a = ((r+s)/2 - q) / 2
        # => b = (1+(r-s)/2) / 2
        #
        # r and s are odd, so we do not have to worry much about fractions
        two_a = (r+s)/2 - <USER2>
        if two_a % 1 == 0:
          a = two_a / 2
          two_b = (r-s)/2 + 1
          if two_b %1  == 0:
            b = two_b / 2
            if (q10 <= a < q) and (q10 <= b < q):
              print a, b, b*b-a*a

On my system:

      time (./ExcellentNumbers.py | sort -u)
      real	0m0.031s
      user	0m0.016s
      sys	0m0.011s

Beats the 1m40 seconds the optimisation got in C, but this is cheating, as it hard-codes the factorisation. Doing that the proper way should not add minutes, though.

If you want to tackle factoring large repunits, do make use of the fact that a repunit containing pq digits can be trivially factored as either a p-digit reunite and a 1000…0001000…0001… one or a q-digit repunit. For example, we have:

      111111111111 = 11 x 10101010101
                   = 111 x 1001001001
                   = 1111 x 100010001
                   = 111111 x 1000001

With those factors in hand, find a few others by taking GCDs of other factors, or by 'randomly' dividing numbers. For example, 1111 does not share a factor with 111, so 100010001 must be divisible by 111.

Edit: tried the 42-digit one. It has:

      q = 1000000000000000000000
      n = 111111111111111111111111111111111111111111
      factors  [3,7,7,11,13,37,43,127,239,1933,2689,4649,459691,909091,10838689]

Times on my system to find 335 solutions:

      real	0m0.219s
      user	0m0.185s
      sys	0m0.022s

I think that is a bit faster than what you had.

And you may want to loosen the range of values for b, replacing

      (q10 <= b < q)

by

      (0 <= b < q)

<comment><USER12> This is seriously awesome. Got to love when you make a blog post about a 20x speedup, and the internet returns the favor with an Infx speedup.

<comment><AUTHOR> You need to keep in mind, though, that the factors of 9999999999999999999999999999999999999999 need to be found somehow. Sure, one can "cheat" and use the factors of 1111111111111111111111111111111111111111 and a couple of extra 3s, but, then you have avoided the problem. That is fine normally, but just not an apples-to-apples comparison.

<comment><USER11> Firstly, lots of work has been done here. See for example [http://www.worldofnumbers.com/repunits.htm](http://www.worldofnumbers.com/repunits.htm) (factorizations of repunits up to 8580 digits).

I also think repunits are, in general, easier to factor because ones that do not have a prime number of digits have obvious divisors.

Certainly, rep units of up to 50 digits are factored easily (Google a bignum factorization program online, and try for yourself)

Even disregarding that, the original code computed a square root about sqrt(n) times (that's why its running time went up by a factor of 10 for every two digits added). Even without using advanced factoring algorithms, you can factor that number using, at the very most, sqrt(n) trial divisions.

</comment></comment></comment></comment></comment></comment><comment><USER13> Could you approximate the square root using 2 integers, rather than using floating point arithmetic?

</comment><comment><USER14> Small correction: K should equal 10^d, not d/2\. Unless I'm missing something.

<comment><AUTHOR> d is the number of digits in 10a + b. Therefore, a and b both have d/2 digits.

<comment><USER14> That works too, but the author said they have d digits each.</comment></comment></comment>


Ask HN: Do you use more than one cloud hosting provider? - <AUTHOR> Do you use more than one cloud hosting provider and if you do why do you use more than one? <comment><USER2> Nope. Too much overhead for a solo developer or small team. One cloud provider already eats more time than we want to devote to ops.

And the purported benefits of multi-cloud setups are vague, handwavy, "maybe some time in the future" risk mitigation suggestions.

Since AWS won't be disappearing on short notice, we're not particularly concerned about having to pack up and go on short notice. Yeah, it'd be a lot of work, but why do that work up front AND incur ongoing double maintenance costs (in terms of time) on the < 2% chance that we'll decide we need to switch providers some time in the next decade?

</comment><comment><USER3> Don't do it until you've got a reason to. You're giving up a lot by trying to make a given workload work between providers. Pick a horse, stick with it until you have to change that for business or technical reasons.

</comment><comment><USER4> Depends on the activity and what i'm storing, like if i want to be safe i use more than 1 for sure , but sometimes i only use 1 for some projects since i don't really like having alot of hosting providers in my hand

<comment><AUTHOR> Thanks for the reply. Who have you had most success with? I'm trying to decide who to go with on a new project.

</comment></comment><comment><USER5> If it's simple enough to go on Heroku, we use Heroku to remove much of the need for devops. More complex things require us to drop down to AWS services directly.

<comment><AUTHOR> Cool. Is it a pain to manage 2 different providers though?</comment></comment>


It's all just bits - <AUTHOR> http://www.extremetech.com/extreme/123685-its-all-just-bits <comment><USER2> I get the point the author was trying to make, but saying that you can't make a telephone call without bits is just silly. There are such things as analog electronics.

</comment><comment><USER3> Nothing is "mere." --Richard Feynman

It's equally all "just quanta".</comment>


Freshchat – a modern messaging tool for sales support and engagement teams - <AUTHOR> https://www.freshworks.com/freshchat-livechat-software/?fworks_navbar <comment><USER2> Awesome customer chat support tool</comment>


Clever subway ad – reacting to the incoming train - <AUTHOR> http://dsgnrt.net/img.php?id=227#.Uw6juJK9KK0

<comment><USER2> This is advertising I could stand. Usually I hate advertising in most forms.</comment>


Thoughts on Acqui-hires & Soft Landings - <AUTHOR> http://daslee.me/quick-thoughts-on-acquihiressoft-landings

<comment><USER2> I don't fully understand acqui- hires especially points like this "For example, don't be afraid to say "I've raised $X dollars and my investors are looking for a 2x return."

If the company is flatlining, why arent acquirers just poaching talent and paying no regard to investors? Why is investor return on a product/service that the "acquirer" will not support or that they don't even care about part of the equation?

Is it because acquirers don't want to alienate investors who may have great cos for them in the future? That's what I've heard but that seems like a soft justification to me. There is a much smaller pool of acquirers than investors so while an investor might not be happy with an acquirer poaching from his prior portfolio company, it doesn't seem they'd walk away from a future acquisition if the economics made sense.

Genuinely curious as to logic of acqui-hires from the acquirers perspective as the conversation suggests investors have some leverage in these discussions when it seems logically that they'd have none.

<comment><USER3> Some of the acquirer's considerations for acquiring rather than aggressive poaching are mitigating potential for lawsuits and making it easier to get key employees and founders who _are_ worried about their reputations in the tech business and might otherwise be un-poachable. Also, it makes it easier to capture most of the employees since every other company will aggressively recruit from the startup once rumors of the startup's imminent demise start circulating.

From an effort, risk, and cost standpoint acquisition may actually be cheaper than wholesale poaching while allowing most people on the other side of the transaction to save face which may have its own long-term benefits in the tech business.

</comment></comment><comment><USER4> There are some subtle points in there.

(as an aside, the bar on the left makes it look like a block quote.)

<comment><USER5> > (as an aside, the bar on the left makes it look like a block quote.)

As does <blockqoute> in the html.

</comment></comment><comment><USER6> Thanks David. I agree with these points. Given the founder's priority is for their team, how do they effectively represent both their team's interest and the investor's interest to the acquirer? In a tight situation, who gets the preference and how much?

<comment><USER7> Why do you take it as a given that the founder's priority is the team? As a founder you have different stakeholders. Perhaps your investors have been with you for years and your team just joined, or the opposite. Like the article says, you can't generalize regarding the employees.

</comment></comment><comment><USER8> "For example, founders who don't think of their team's welfare first in a soft landing probably won't get funding from their prior investors."

So in this context, a founder's "team" is the investors, yes? Not the employees?

<comment><USER9> I see no reason to think so. The article uses both 'team' and 'investors'. No reason to think the writer is disorganized.

It also says in a soft landing 'investors basically get no money back.' So the only concern seems to be how the team is treated.

</comment></comment><comment><USER10> So where do customers and early adopters fit into this whole thing?

</comment><comment><USER11> This was interesting and helpful. It wasn't clear though how much this was directed at Acqui-hire vs Soft Landing. It seems most of it was Soft Landing focused?</comment>


I'm 15 and I just launched LoveYourLanding - <AUTHOR> https://www.indiehackers.com/post/im-15-and-i-just-launched-loveyourlanding-ca5491e21b <comment><AUTHOR> Just to be clear, this is not my story, just wish I had been proactive at that age!

</comment><comment><USER2> Hey, good work.</comment>


How do iPhone apps Instagram/DailyBooth/Path implement large center tab buttons? - <AUTHOR> http://idevrecipes.com/2010/12/16/raised-center-tab-bar-button

<comment><USER2> Please stop that snowing :-/

<comment><AUTHOR> OK, enough people have asked, so the snowing is gone...

</comment></comment><comment><USER3> That's lovely apart from the fact that having a camera button is inconsistent with tab navigation.

<comment><USER4> Tab navigation is sometimes inconsistant with the greater purpose of an app. You need some tabs, but also something else sometimes.</comment></comment>


A curated guide for startup business tools - <AUTHOR> https://www.stacklist.com/ <comment><AUTHOR> Hi everyone,

Saw the post for StartupStash the other day and thought I'd share Stacklist. We've interviewed over 500 startups about the business tools they're using to grow.

On our site you can see what tools other startups are using and also find reviews for different business tools.

When we launched in 2015 we were the #1 product for the day on ProductHunt, and #8 overall for September.</comment>


Near Future of Programming Languages [pdf] - <AUTHOR> http://dev.stephendiehl.com/nearfuture.pdf <comment><USER2> Things to think about for the near future of programming languages:

\- The borrow checker in Rust is a great innovation. Previously the options were reference counts, garbage collection, or bugs. Now there's a new option. Expect to see a borrow checker in future languages other than Rust.

\- Formal methods are still a pain. The technology tends to come from people in love with the theory, resulting in systems that are too hard to use. Yet most of the stuff you really need to prove is very dumb. X can't affect Y. A can't get information B. Invariant C holds everywhere outside the zone (class, module, whatever) where it is transiently modified. No memory safety violations anywhere. What you really need to prove, and can't establish by testing, is basically "bad thing never happens, ever". Focus on that.

\- The author talks about "Java forever". It's more like Javascript Everywhere.

\- Somebody needs to invent WYSIWYG web design. Again.

\- Functional is OK. Imperative is OK. Both in the same program are a mess.

\- Multithread is OK. Event-driven is OK. Coroutine-type "async" is OK. They don't play well together in the same program. Especially if added as an afterthought.

\- Interprocess communication could use language support.

\- We still can't code well for numbers of CPUs in triple digits or higher.

\- How do we talk to GPU-type engines better?

<comment><USER3> I disagree with a few of your thoughts, but they're good thoughts!

* Javascript everywhere is a function of low barrier-to-entry for it, but almost everybody agrees it is flawed as a language. If that's the future, we are screwed as an industry. One thing I've noticed (and I say this as a guy who wrote Ruby for 10+ years), is that type safety is becoming a hugely desired feature for developers again.

* WYSIWYG web design (a la Dreamweaver) died off a little because the tools saw a web page as standing in isolation. We know however that isn't interesting on its own - it needs to be hooked up to back-end functionality. Who is producing static HTML alone these days? In the case of SPAs it needs API integration. In the case of traditional web app dev, it needs some inlining and hooks to form submission points and programatically generated links to other "pages". Making that easier is the hard part - seeing a web document as an artefact of an output from a running web application container.

* Multi-threaded, event-driven, coroutine-type patterns are fine in Go, to my eye. What's making you think we can't mix this up with the right type of language and tooling support?

* Is it that we can't code well for CPU counts > 100 or that the types of problems we're looking at right now that need that level of parallelism tend to be targeted towards GPUs or even ASICs? I think I'd need to see the kind of problems you're trying to solve, because I'm not sure high CPU counts are the right answer.

* Talking to GPU-type engines is actually pretty simple, we will deal with it the same way we deal with CPU-type engines: abstraction through a compiler. Compilers over time will learn how to talk GPU optimally. GPU portability over the next 20 years will be a problem to solve as CPU/architecture portability was over the last 40.

<comment><USER4> > WYSIWYG web design (a la Dreamweaver) died off ....

Which is why what we actually need is a la Delphi

<comment><USER5> I have been thinking about that and there is an issue with it; Delphi (and VB) where written in a time when devs paid a lot for software tools. Besides some niches (embedded) that is not really the case anymore. You expect to pay a few $10 at most in total if that. And a lot of people (but that might be the HN/Reddit echo chamber) demand all to be OSS as well they work with. Making 'a modern Delphi' is a _lot_ of work; years of it. And much of that time is not 'fun', it's hard work polishing little parts and having user test groups feedback on it and polishing it some more. The time that you could be Borland seems gone (unfortunately imho) and i'm not sure how you can make the kind of polished tool you are talking about in the current climate. Maybe someone else here has some different views though.

<comment><USER4> There are companies trying it though,

[https://anvil.works/](https://anvil.works/)

[https://www.outsystems.com/platform/](https://www.outsystems.com/platform/)

JetBrains is probably a good example of a "Borland" like company.

Outside HN/Reddit bubble that are plenty of companies that are willing to pay for software, the supermarket cashier doesn't take pull requests.

Also, the back to native focus on mobile platforms, including Google having to integrate Android apps on ChromeOS, might make it less relevant, given that native IDEs do offer some Delphi like experience.

<comment><USER6> JetBrains never did any rapid UI IDE like Delphi did. In fact, all their IDEs are in Swing, which is a mess. I'd totally love having CLion/PyCharm with Qt UI designer, but it's not going to happen.

<comment><USER7> The easiest time I had writing GUIs was when I used PyQT. I designed the UI in Qt Designer, loaded it in the python code, set the bindings and voila, it was working.

Btw Visual Basic continues to exist under Visual Basic.NET and if you stick to the basics you could learn to write C# GUI programs pretty quickly.

I agree writing GUIs by hand is very counter-productive.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> One area I haven't seen any good solutions for is the interleaving of tests with production code. I think we need better ways to express tests without cluttering the production code and excessive mocking. What I'd like to do, and really can't in any language/tooling that I know of, is to extract some arbitrary subset of the code and surround it with tests or a test harness. I'd also like to specify various injection points for tests right as I'm writing the code in a way that doesn't affect the production code and contributes to its readability. Perhaps this is pieces of server and client code or various services all tested together. When I refactor the code I want the tests to "refactor" with the code. I don't want to need to rewrite my tests... Automatic test generation is another interesting area (beyond the basic table or algorithm stuff we might do in tests today).

It's almost like the "problem" isn't the languages themselves, it's the tooling around the languages. I want to be able to do a lot more than "compile", "run", with my code... I can imagine machine learning driven tooling being able to automate a lot of the mechanical aspects of code writing beyond the simple generate a closing bracket that an IDE can do...

<comment><USER9> I don't do coding tests. I talk to the candidate about programming and I only require one interview. I haven't made a hiring mistake in 6 years.

<comment><USER10> okay. care to give any other info? Usually when someone says I haven't failed in 'some impressive challenge in a long time' it means your challenge wasn't that impressive. How much interviewing have you done, what were the hard calls you were asked to me, whats your scheme?

When I was at google, one of the hardest thing I did was look at the marginal intern review scores and tried to pick out the ones from the big pile whom we should look at again and who should not be looked at. There were all kinds of crazy ass stupid interview questions that in my opinion were not very useful to classify capability.

<comment><USER11> > _okay. care to give any other info? Usually when someone says I haven 't > failed in 'some impressive challenge in a long time' it means your challenge > wasn't that impressive._

Or they couldn't recognize failure

</comment></comment></comment></comment><comment><USER12> The "Language Gap" slide seems massively overstated, or maybe I'm misunderstanding. We really have seen a lot of progress in the last 10-20 years, both in industrial languages and in academic ideas that could become the industrial languages of the next 10-20 years (e.g. Idris on the short end, Noether on the longer end). The author laments that pattern-matching is still not standard, but we're getting there; map/reduce/filter are standard in all new languages these days (they weren't 10-20 years ago), some kind of lightweight record feature is standard in all new languages, some level of type inference is standard in all languages. Yes, it's taken longer than you might imagine it should, but progress is happening. Likewise formal methods - they may not be practical in 2016, but there's a lot more awareness, a lot more work being done, and people are starting to try to take the useful parts and apply them in more and more industrial settings. Likewise graphical representation of code - not the LabView nonsense that's exciting to talk about at cocktail parties, but the little touches that today's IDEs do almost invisibly - highlighting, mouseover information, outline views, smart code folding.

I wish we were better at communicating about programming languages. I wish we were moving faster. But despair is unwarranted. We really are in a much better place than 10-20 years ago, and the next 10-20 years look set to bring more improvements.

<comment><USER4> 10-20 years ago some of us could use Smalltalk, do systems programming with strong type safe languages, use RAD environments like Delphi, release applications in Prolog, for example.

To me it seems we are catching up with the past, and as someone already programming on those environments, it looks we have spent 10-20 years loosing our tools, educating the masses, only to get a taste of things used to be.

<comment><USER12> I've certainly seen cases where we take one step back in one area to take two steps forward in another; where it takes 5-10 years to get language C that can do something that language A we were using 5-10 years before that could do - but only if we forget that we also wanted some capability in the language B that we couldn't do in A, and C is the first language that manages to synthesise both. And industry is always going to be a long way behind the cutting edge - most of the features we're excited about today are things that were present in ML. But on the whole it feels to me like both a) the mainstream industrial programming experience today is better than it was 10 years ago and b) the academic cutting edge of programming language design today is better than it was 10 years ago, and I expect both those things to continue to be true.

</comment></comment></comment><comment><USER13> My thoughts are that we don't really need more languages. Arguably we don't need better ones either, because they aren't the problem in _general_ computing. Instead we need better _design paradigms_ that better let us model complex requirements and systems into code. Let's have new languages that then support those paradigms.

We continue to struggle abstracting complex problems using functional decomposition, structured analysis, information (data) modeling, and object- based decomposition.

Many newcomers I meet only know modeling problem domain concepts as data in a database, with behavior and constraints acting on that data in a separate layer, organized using functional decomposition. Of course that layer increasingly approaches a 'big ball of mud' as size and complexity increases. Sounds a lot like we are back data-flow modeling as so popular in the 1980's, in a new guise.

A focus on programming languages in my opinion, masks the real issues we face.

<comment><USER14> Much of the time, new languages lead to new design paradigms. As a general rule, newer languages are more abstracted than older ones. When people don't need to get hung up on the intricacies of low level programming, real progress can be made on the design paradigm front.

<comment><USER13> I'm curious which languages have resulted in which new design paradigms?

<comment><USER15> Two good examples:

Erlang led to Microservices and the Reactive Manifesto. the Open Telecom Platform is still a very modern Microservice library (in my opinion) after more than three! decades

ML led to programming against generic interfaces ([http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/r...](http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/rec08.html))

</comment></comment></comment></comment><comment><USER16> I would love to see programming as a dialogue between user and computer (programmer and compiler). For example:

Compiler would infer the types, and the programmer would read it and say, oh, I agree with this type, but I disagree with this type, that's perhaps wrong, this should be rather that type. Then the compiler would infer types again, based on programmer's incremental input.

Data structure selection. Programmer would say I want a sequence here. The compiler would say, I chose a linked list representation. The programmer would look over it, and disagree, saying, you should put this into an array. And compiler could say, look, based on measurements, array will save this much space but list will be this much faster.

Code understanding. Programmer should be able to say just, I don't know what happens here, and the compiler would include some debug code to show more information at that point.

Or take refactoring. Programmer would write some code, computer would refactor it to simplify it. Then programmer would look over it, and say, no, I rather want this, and don't touch it, and he would perhaps write some other code. The compiler would refactor again...

But all this _requires_ that there is syntactically distinct way (so that perhaps editor could selectively hide it) to specify these remarks in the code, both for computer and programmer. So each of them should have a special kind of markup that would be updated at each turn of the discussion. Because you don't want to just overwrite what the other side has just said; both are good opinions (which complement each other - human understands the purpose of the code but the computer can understand the inner details much better). So, to conclude - I wish future programming language would include some framework like this.

<comment><USER17> The types line is what some people do with Haskell, Idris. I do personally favor writing the large-scale types beforehand, because that gives the compiler a chance of saying "look, you program is wrong", what is way more useful than "hey, your program has this type". Besides, abstract-type driven programming is an incredibly good methodology where it's applicable.

On code understanding, what makes it better than the programmer inserting the debug statements themselves? It saves some misunderstanding from the computer's part.

On refactoring, some IDEs do that. I'm on the fence about its usefulness.

<comment><USER16> Thanks, I will respond to other people here as well.

I know a bit of Haskell and want to look at Idris, someday.

My point was, there should be a clean (best if even syntactic) separation between code itself (i.e. what should actually be done) and its properties (like types). Also, because there are two points of view about the properties (human and computer), this separation needs to be there twice (so for example, each type could be specified by computer and by human). I haven't seen a system that would do it, on a systematic level in the programming language. I only gave examples to show where it could be used.

<comment><USER17> You mean that types should reside on different files, and be inputed by different means?

Now I get the entire programming-compiler conversation. It is interesting. I can see some potential there. Yet, I shrug when I think about all the sparse metadata that I will have to check once I discover a low level bug (there is a reason I'm not programming in Smalltalk).

Somehow the best place for all that stuff to live is right there at the source code. That means the compiler (IDE) should be editing your files, so it better have a great integration with your version control system.

<comment><USER16> > Somehow the best place for all that stuff to live is right there at the > source code.

That's what I am saying, and that's why it has to be syntactically distinct.

Also it needs to be clear what was input by computer and what was input by human, that's the second distinction. Because of how the conversation works. You don't want computer to erase human input, but the result also has to be logically sound. So you need to know both inputs for the comparison and synthesis, which happens at each conversation turn, both human's and computer's.

And that's what "type holes" and similar systems lack - they only record the result of the synthesis, not the two different opinions. Which is IMHO wrong.

<comment><USER17> > You don't want computer to erase human input

I will contest that one too :)

As long as it is interactive enough, and the history is well marked, there is no reason not to rewrite human code.

</comment></comment></comment></comment></comment></comment><comment><USER18> This talk is right that effect systems aren't popular yet, except the way Haskell does them. But it's wrong about the trajectory of languages. Right now is the best time to be interested in using cutting edge languages in practice. Also right now has seen an explosion of new languages with interesting ideas, from Rust to Purescript to Elm (in the authors preferred realm of typed languages). Also industry is backing major post-Java languages like F# and Rust.

In short, the near future of PL is great, and exciting stuff keeps happening. Don't believe the naysayers.

</comment><comment><USER19> _> Lots of people are reinventing Smalltalk on a Mac. (See Bret Victor and Eve)._

At last, someone noticed! ;-)

Though from that expression, what the author doesn't seem to grok is why having a Smalltalk-like environment is desirable; maybe not as the primary way to program computers but certainly as a tool alongside.

It's a shame that a family of programming languages that build on and expanded that model hasn't gained more traction in the industry (not necessarily for people who dedicate their lives to build complex software with a highly general programming language, but for the rest of us).

<comment><USER20> I find the jab at Bret Victor especially undeserved. He's an interaction designer (a really good one who sees through all the fads[0], which is kind of the opposite of what this one-liner implies). His focus is on better _interface_ design, not _formal language_ design; why criticize someone for something they're not trying to do?

And it's not useless; we probably wouldn't have had Elm without Bret Victor's _Inventing on Principle_ [1][2]. And there has been some progress in that direction of interface design of, for a lack of a better term, "programmable environments": look at Apparatus, for example[3]. Where would you even fit that on these slides?

[0] [http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesi...](http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/)

[1] [http://elm-lang.org/](http://elm-lang.org/)

[2] [https://vimeo.com/36579366](https://vimeo.com/36579366)

[3] [http://aprt.us/](http://aprt.us/)

<comment><USER19> Quite true. I find likely that the next revolution in programming languages will come from designing a PL that's a good fit for these programmable environments. Maybe it should break from current undisputed conventions like the radical separation between "data" and "source code", and be more like a spreadsheet.

End-User Development has lots of under-explored ideas on how to build software automatisms that don't require the end user to learn a hard formalism (even if such formalism exists as the basis for the system). Though I understand that programming language theorists are not interested in that angle of the evolution of PLs.

<comment><USER21> There is a dichotomy between sealed programs and evolving programs. Evolving programs like Smalltalk or REPLs are great for exploratory work. Almost everyone wants sealed programs for systems to work reliably. This runs along the lines of Ousterhout's dichotomy as well - scripting vs systems languages.

The engineering break through will be when we have a scripting/evolving system that can be more easily distilled into sealed systems. So people poking around in a spreadsheet will be able to turn that into a reliable application.

IMO, TDD and BDD could be seen as attempts to do exactly this.

<comment><USER22> Do you see this as a useful dichotomy? In reality no system is truly sealed - it's just temporarily sealed between evolution steps, no?

<comment><USER21> I do find it a useful dichotomy because I work with people who evolve their code and wonder why I get my back up about monkey patching (because it's often my job to turn research or prototype quality code into reliable code).

If you've ever had to make another person's research or prototype quality code more robust it can be easy to wonder how on Earth they work the way they do. Having this dichotomy in mind makes it easier to have more sympathy.

It works both ways. Researchers need to understand why platform development moves so slow. This dichotomy helps reason about it.

But you're right, between evolution steps the system is not sealed. That's a concern and why projects like Debian are keen to have reproducible builds. It's also a big part of why containerization is becoming so popular.

<comment><USER22> Ah I see. So with 'sealed' you mean things like reproducible builds and being able to determine the exact set of sources, etc?

The containerization movement is interesting - while having these 'sealed' virtual environments and reproducible system builds is the right direction, I'm amazed at the size and weight of each of these.

<comment><USER21> Sure. By sealed I mean you compiled the program, you might have a turing incomplete configuration (e.g. ini, toml, json) and you can reason about the program. And by evolving (or, I guess unsealed) you are in the process of editing the program. Or you monkey patch it when you run it.

But with things like LD_PRELOAD, different .so minor versions, etc, a compiled program suddenly straddles the categories. Hence my comment about reproducible builds and containerization.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER23> This is a great presentation, I wish I could hear the talk track. While we can all differ on the right "winner" for the next programming language (I don't think Clojure is the right answer, someone else might), we are all stuck with the same set of facts - and this covers the state of things very well. Most importantly, it explains certain truths of the social/economic ecosystem for programming languages - which is what gave us Java, Python, Javascript, and a few other really popular systems that seemed unlikely to succeed when they first appeared. The reasons for their success have just as much to do with "ecosystems" than with language features.

<comment><USER24> On twitter he says:

"The thesis was that programming in 2030 will have very advanced research languages but mainstream languages will effectively stop advancing and we'll be last [sic - left?] with a vast insurmountable gap between the two."

That provides some context for what the slides are about.

</comment></comment><comment><USER25> "It just feels readable". -> "It looks like this other language I know."

But: that language might be English (or other natural language). Which is to say maybe computer languages are leveraging the human "language faculty" and rightly so. Which may mean that some languages are always going to feel more foreign.

<comment><USER26> Considering how many programmers will tell you that C style semicolons and curly braces are more readable than using keywords, I think they've got a point

<comment><USER27> At some extremes yes but, for example, I've spent at least twice as much time programming C and C+ than I have with Python but I still find Python generally more readable. Maybe if the ratio were 100 to 1 instead of 2 to 1 I'd feel differently but that suggests there are actually intrinsic differences in readability apart from just familiarity.

</comment></comment></comment><comment><USER28> This is a _brilliant_ synopsis of the state of the art -- truly fantastic -- and yet the presentation concludes with, "The innovation won't happen because I can't see where it will come from," and that's not entirely fair. Some areas he covers aren't exhaustively covered and what's missing is quite interesting. In other words, cheer up, there's more hope than what's shown here.

<comment><USER29> I think this is just a fustration with how little direct incentive there is from our economic system to fix the problem. The only chance of this paradigm existing is as a long shot project that is gifted to society, and the person that makes this gift has the slim chance that it doesn't succeed and all the effort is wasted.

<comment><USER30> I found that the weakest part of the presentation.

Kotlin and Ceylon both came out of corporate/industrial development. C#, JavaScript and Java continue to evolve entirely due to industrial funding.

I agree that academia is not a great place to do PL research as all the other non-idea aspects of a successful PL don't get enough attention. But industry is doing OK at launching new languages. Perhaps he feels that's "incrementalism" but there's nothing wrong with making solid upgrades that aren't attempts at unicorn style magic cure-alls.

It'd also help if we collectively got over our demand for our tools to always be open source. This has solid justifications behind it but it ensures that programming languages will always be spinoffs of other endeavours rather than having truly focused attention in their own right. When you take away the profit motive, you get stagnation, and that seems to be the main point of the presentation.

</comment></comment></comment><comment><USER31> What people who do academic analysis of programming languages often miss is _culture_. So much about what programming language gets used has to do with what ecosystem it's been targeted at and what colleagues in that ecosystem are using.

<comment><USER23> I couldn't agree more and was just making this point to someone last week - for many of the well-established languages, 80% of the reasons to use or not to use them is the associated culture, from the qualifications of the average applicant to the prevailing approaches to solving problems.

</comment></comment><comment><USER32> It looks like the presentation stops short of any strong conclusion.

<comment><USER33> It's still pretty useful as far as identifying the problem is concerned.

</comment></comment><comment><USER34> Hype is too strong and good ideas of the past are a niche topics. Computer science should focus more on its own history and realize what has been done and needs to be taken further. I wish I studied much earlier about things like process calculi, PL/type system theory, alternative OS design and verification approaches. Just by chance I pick up important information from the web or in rare master's courses where we are just a handful of students (while the machine learning courses get hundreds).

</comment><comment><USER35> "Where will the next great programming language come from?"

Interestingly Scala has come from Academia, Industry, and Hobbyists. And for me it's already the next great programming language. Yeah, it has some warts and is hard to learn but that's true of all great things. :)

<comment><USER36> Yeah this comment stuck out to me in the presentation. Industry has a great record of creating + supporting languages. C#, F#, Dart, Swift, Rust, D are all languages that are actively supported by industry, and some were even created by industry too. Just seemed like a weird statement for the slides to say that new languages just aren't going to appear.

<comment><USER37> If anything, almost too many of them. In the esoteric language area, every new language takes away from libraries for other ones as the communities get spread out. I do think the spread of ideas from that setup is good though.

</comment></comment></comment><comment><USER38> Perhaps the future of programming isn't in linear deterministic code but in stochastic or probablistic languages dealing with machine learning or biology. Maybe we're hitting Godel/Turing-like wall and as we strive for more perfection and provable soundness, we will find we can't scale up to bigger and bigger systems. We'll be stuck with human debuggable linear languages like we have today or systems which operate more like a composition of machine learning models.

<comment><USER39> Of course in practice we know is a lot easier to build and use probabilistic models. However, I hope we don't give up on proovable systems.

When given enough time, if math can stay pure and adequately abstract to eventually describe our entire universe concisely. Shouldn't code similarly have no limitation?

</comment></comment><comment><USER40> TL;DR Everything is awful and nothing will save you

</comment><comment><USER41> I like the slides and agree with the widening language gap. I have a few comments about the conclusions, though.

> The UPenn dependently typed Haskell > program shows a great deal of promise > and > is likely to manifest a decade before other > DT languages generate > practical backends.

I don't agree with this at all. The design problems with tacking on dependent types to an existing system are massive - it's a research problem for a reason. On the other hand, writing a "ghc quality" backend for Coq/Agda/Idris/F* seems difficult, but at least it's an engineering problem instead of a rough idea.

In particular, CertiCoq is a compiler for Coq written in Coq, and the main problem here is verification. Simply writing a compiler is no harder than writing a compiler in any language.

> Interesting ideas out of Microsoft Research on SMT solver > directed > programming editors that enforce invariants and can > generate code during > development.

Another interesting Microsoft Research project along the same lines as Dafny is F _. Both are nice, but F_ is closer to modern dependently typed languages.

> Lots of non-local reporting problems associated > with using unification > during type-checker.

I would argue that the problem is that we use constraint solving for type checking. For example, strict bidirectional type checking leads to more tractable errors, since it's straightforward to follow the compiler's reasoning. On the other hand, bidirectional type checking is less powerful, so it's not like there's a silver bullet here.

> Type-safe OTP.

I wish more people were working on things like this. There's some theoretical work on calculi for distributed systems, but once they encounter the real world they inevitably become horrendously complicated.

</comment><comment><USER42> Regarding the effect systems slide. One of my favourite features of the Nim programming language is its effect system,[1] it tracks IO effects, but more importantly it also tracks the exceptions that are raised by each procedure. This allows for a very nice implementation of checked exceptions and docs which contain the possible raised exceptions of each procedure.

1 - [https://nim-lang.org/docs/manual.html#effect-system](https://nim- lang.org/docs/manual.html#effect-system)

</comment><comment><USER43> "Use the right tool for the job" is _not_ the dumbest cliche in software... in theory. But it requires actually knowing what options are available, what their strengths and weaknesses are, and what problems (various kinds of yak shaving) the job will throw at you. Picking the tool that can best reduce the yak shaving is the difference between professionalism and masochism.

In practice, though, a lot of people quote this who don't know what options are available, what their strengths and weaknesses are, and what the problems of the job will be, and so _when those people quote it_ , it's just a cliche.

</comment><comment><USER44> In case of anyone interested a reasonable engineered language that supports Closure Serialization (mentioned as "hard" in last slide), checkout:

Gambit Scheme: A fast scheme implementation. [http://github.com/gambit/gambit](http://github.com/gambit/gambit)

Gerbil Scheme: Provides full module and syntactic tower on top of Gambit Scheme. [https://github.com/vyzo/gerbil](https://github.com/vyzo/gerbil)

<comment><USER45> Does Guile (or even Chicken) do anything similar?

(My only exposure to it is from Andy Wingo's blog, and I don't know much about Scheme.)

<comment><USER44> Nope.

</comment></comment></comment><comment><USER46> > Will we just be stuck in a local maxima of Java for next 50 years?

1\. Yes, if the extent of the imagination is languages like Idris and ideas like effect systems, that follow a gradient descent from Java, and always in the same direction: being able to express more constraints. What you get "for free" from such languages may not be significant enough to justify the cost of adoption, and the valuable stuff you can get is not much easier than the options available today, which are too hard for anyone to take. If you were to consider truly novel languages that think out of the box (e.g. Dedalus/Eve) then maybe one will stick and make an actual impact rather than just a change in fashion.

2\. How do you even know that we _can_ do much better? NASA engineers may not like it, but they don't _complain_ that we're "stuck" at sub-light speeds. Maybe Brooks was right and we are close to the theoretical limit (that we know must exist).

> We talk about languages as a bag of feelings and fuzzy weasel words that > amount to "It works for my project".

Can you find another useful way, available to us today, of talking about languages?

> "Use the right tool for the job" Zero information statement.

That's right, but it's not a dumb cliché so much as it is a tool we've developed to shut down religious/Aristotelian arguments that are themselves devoid of any applicable, actionable data. One, then, is often confronted with the reply, "but would you use assembly/Cobol?" to which the answer is, "of course, and it's not even uncommon, and if you don't know that, then you should learn more about the software industry before giving any more Aristotelian arguments."

<comment><USER45> > What you get "for free" from such languages may not be significant enough to > justify the cost of adoption

Idris can often infer entire functions from their types if the domain is amenable to accurate type-based specification. For instance, taking the common "sized vector" example, where `Vec n a` refers to a length-n vector of values of type a, functions like

        zip : Vec n a -> Vec n b -> Vec n (a, b)

can be automatically generated via the interactive "proof search" mechanism that the Emacs integration for Idris provides. Similar things are possible in Agda, which is however squarely aimed away from the "practical use" market.

<comment><USER46> > Idris can often infer entire functions from their types if the domain is > amenable to accurate type-based specification.

This is a great example of what I'm talking about. The kind of functions Idris can generate is that of functions that you could manually write with only marginally more effort -- if that -- than the effort required to write the precise type. I don't think those functions ever form a significant portion of a significant program, if at all (those functions must be so generic, or else there would be a search problem that Idris can't solve, that they would already likely be in the standard libraries). When Idris is able to generate an efficient sorting function given some constraints, then I'd be impressed.

> can be automatically generated via the interactive "proof search" mechanism

If you've spent a significant amount of time with such proof assistants, you'd see that the proof search is rather pitiful.

<comment><USER47> > If you've spent a significant amount of time with such proof assistants, > you'd see that the proof search is rather pitiful.

Afaik, Idris' proof search was hacked together in an afternoon just to see if it would work. And it did, surprisingly well considering. Don't know how much it has been worked on since then though. But yes, still leaves a bit to be desired compared to other systems.

<comment><USER46> I wasn't just talking about Idris. There isn't a single tool out there that can automatically prove that your quicksort implementation actually sorts without pretty significant work.

</comment></comment></comment></comment></comment><comment> lain-dono > It's lightweight > I was able to install the compiler

It does not prevent the browser from eating all the resources.

</comment><comment><USER48> Just curious where does Elixir fall in this scheme of things? Any experienced devs who could give a qualified answer, please?

<comment><USER47> Elixir doesn't really push much of the state of the art forward. It's pretty much Erlang with new clothes (and some nice cleanups). I worked with it for over a year and while I loved the 'fail fast' model of programming, most of the errors that were caught were stupid programming errors that would have been trivial to catch by a type system.

What I really want is a type system for reasoning about distributed, stateful, programs. Has to deal with mixing strongly consistent eventually consistent (CRDT) data with synchronisation points (see Bloom/Lasp), hot code reloads, migrations, messaging across nodes, possibly some sort of row polymorphism combined with clojure's namespaced symbols... Like sort-of like Cloud Haskell but with zero-downtime deployments. Or like Pony but with a better distribution story.

<comment><USER49> Distributed Pony will be there soon.

[https://www.doc.ic.ac.uk/~scd/Disributed_Pony_Sept_13.pdf](https://www.doc.ic.ac.uk/~scd/Disributed_Pony_Sept_13.pdf) [pres], [https://www.ponylang.org/media/papers/a_string_of_ponies.pdf](https://www.ponylang.org/media/papers/a_string_of_ponies.pdf) [paper]

I'm not sold on Cloud Haskell or Clojure.

</comment></comment></comment><comment><USER50> OCaml is as "industrial" as Haskell is.

</comment><comment><USER2> "OTP" on p. 23?

"One True Pairing"?

"Online Transaction Processing"?

probably not "On The Phone".

<comment><USER51> Open Telecom Platform? Erlang's runtime

<comment><USER52> I think it's just the biggest Erlang framework. BEAM is the runtime.

</comment></comment></comment><comment><USER53> This is a great deck... but leaving TLA+ out of Formal Methods? It is hands down the most important thing going on there. And it is a combo between academia and industry. Amazon uses it extensively.

<comment><USER46> It also left out all PL research outside of typed FP. It isn't really about the future of programming, but about the future of typed FP. For example, it lists Eve as a "reinvention of Smalltalk" when, in fact, Eve incorporates at least as much cutting-edge PL research as Idris.

</comment></comment><comment><USER54> > Languages that have dabbled with modeling effects with row types have > backtracked on it in favor of IO.

Interesting. I thought algebraic effects + handlers were the new hotness in modeling effects with types.

<comment><USER55> They are hotness because they are having trouble getting them to work (trouble = open research topic :) ), and they want to convince the monad proponents that they are better.

<comment><USER56> what trouble ? [http://www.eff-lang.org/](http://www.eff-lang.org/)

</comment></comment></comment><comment><USER57> Is there a talk for these slides? I haven't been able to find it.

</comment><comment><USER58> This could be titled "Static typing is not going to save you"? There's nothing but static typing languages and related theorem provers from the timeline slide onwards and the conclusion is that it's too hard.

This is a good companion piece for the recent Rich Hickey Clojure/Conj talk :)

<comment><USER23> I don't really see where you get that. Is dynamic typing demonstrating a lot of sustainable success?

<comment><USER58> I edited in the Clojure part after you replied.

Languages that have forgone static typing aren't necessarily trying to solve everything using language types at runtime. See eg Clojure's approach. Or SQL's.

But at the base popularity-contest level the answer is clearly yes: Dynamic languages have been on a roll for the last 30 years - Perl, Python, Ruby, Erlang, Clojure, even JS.

<comment><USER59> That certainly doesn't mean it's because of their dynamic typing. And Erlang and Clojure, as nice as they are, are still about as popular as AWK is.

</comment></comment></comment></comment><comment><USER60> Well this person sure seems very angry and opinionated, yet there's hardly any justifications for his criticisms in this childish rant. I mean if you're going to say everything is "dumb", and "shit" and whatnot, at least tell us why. As it stands this is definitely a case of "maximal opinions and minimal evidence".

</comment><comment><USER61> _cough_ Prolog _cough_

</comment><comment><USER62> Recently a famous AI project was shut down because it was inventing its own language. Perhaps the next generation programming language and design paradigms won't come directly from humans at all.

<comment><AUTHOR> Are you talking about Theano?

</comment></comment><comment><USER63> So are we just going to pretend Perl doesn't exist?

<comment><USER64> You can't expect 20-or-so slides to cover all languages. And I'm not aware of any PL research topics being explored in Perl, so not sure how talking about Perl would fit in.

<comment><USER65> Perl6 in its spec has auto-parallelization of at least the hyperoperators. It has hyperoperators themselves. It has full LL and LR grammars as part of the language. It has optional strong typing for support of incrementally typing your source. It has junctions. It has a native MOP. It has active metadata on all data types (values, variables, subroutines, and types themselves).

Beyond what might be purely PL research, there are some other neat ideas being explored. It does function currying, lazy evaluation, grapheme-level Unicode support, and custom operators from any Unicode grapheme.

It's definitely a language I'd be watching if I was writing about near-future languages.

</comment></comment></comment><comment><USER66> TLDR The future of programming languages should involve not naming your language "Coq". I know I am going through the lowest common denominator, but how do you explain to your boss that you're proficient with using Coq. Ugh. Or professor, since apparently it's a proofing language for academia.

<comment><USER67> "Coq" means "Rooster" in French. Coq (the software) started development at INRIA (France) in 1984 as a small R&D project. I am not particularly shocked that the original developers did not realize the possible double meaning in another language, and being as dismissive as you are seems uncalled for.

There are countless startups whose names in English mean something else entirely in another language. For example "Cocu Social", a cooking startup, whose name in French would mean "gregarious cuckold".

<comment><USER18> The original developers include Thierry Coquand. Also there's a tradition of naming theorem provers after birds (that might have started with Coq though).

But they definitely knew that this pun was there.

<comment><USER68> .. and it is based on a type theory known as the Calculus of Constructions (CoC).

</comment></comment></comment></comment><comment><USER69> Maybe not for me and you, but for software development in JavaScript generally it's really not ideal. [http://www.sellbagswallets.com/handbags](http://www.sellbagswallets.com/handbags)

</comment><comment><USER70> My project introduction book contains a description of the future programming language, you can see. [https://github.com/ShionAt/Keys](https://github.com/ShionAt/Keys) twitter: @ShionKeys

</comment><comment><USER71> Coq should have good interop with cockroachDB.

<comment><USER71> Why are people so against the future of tech?

</comment></comment><comment><USER72> Very disappointed not to see Cilk included.

<comment><USER23> Do you mean this Cilk? [https://en.wikipedia.org/wiki/Cilk](https://en.wikipedia.org/wiki/Cilk)

<comment><USER72> Yes. Cilk is very easy to use and has pretty good performance. I would love to see it used more in industry rather than just in academic work.

</comment></comment></comment><comment><USER73> "It's like X but more practical". -> "There's a library for my domain".

3real5me

</comment><comment><USER74> Dynamic analysis + machine learning could become next-generation coding: [https://maierfelix.github.io/Iroh/](https://maierfelix.github.io/Iroh/)

</comment><comment><USER75> Looking at the 2010 Haskell report: most of the committee members come from 'Academia':

[https://www.haskell.org/onlinereport/haskell2010/haskellli2....](https://www.haskell.org/onlinereport/haskell2010/haskellli2.html#x3-2000)

How is it an 'industrial' language? Haskell is the main 'academic' language for a branch of Functional Programming.

'industrial' is just another weasel word.

<comment><USER37> If you keep your head to the ground, there are quite a few companies like Facebook that use Haskell for important things in production, but it isn't the language even 50% of the company is using. I'm sure there is a lot more lisp in production, but you typically hear about the same ratio from both camps in the blogosphere.

<comment><USER75> I would guess that in a company like Facebook, 99.5% of the code they wrote is not Haskell. If they have, say, 200MLOC of code written (just a number), this would be 1MLOC...

<comment><USER4> There are companies using a bit more of Haskell in production.

[http://cpmed.de/jobs/](http://cpmed.de/jobs/)</comment></comment></comment></comment>


Weekend deployments are for chumps - <AUTHOR> http://blog.bitquabit.com/2011/03/08/midnight-deploys-are-for-idiots/

<comment><USER2> I can't believe in how misguided this post is...

1\. They provide a service to people around the world, yet they don't ensure that someone is available as an emergency contact on Sunday evening, when the first post-deployment usage happens.

2\. They don't have a universal list of "this breaks, contact that guy".

3\. They don't have a known instant rollback procedure for a release.

4\. They don't have cross-component integration tests and they don't do them manually either.

5\. They decide that since they can't do a release that doesn't break stuff and can't organise themselves to resolve it quickly during the weekend when it affects only a small number of people, they'll do releases in the middle of the day now, so that they hear customers complaining right away.

Is that for real? Is he serious? Here's what I would get out of that issue (even if it's basically reiterating the "wrong" things above):

They need to do more integration testing before a release. They need to know who to contact and have to make sure the person is on call and ready for action. The person handling the issue needs to have a simple, quick way to reverse the release without manual intervention (tweaking the code). Again, this specific issue should get regression tests right away. And the most important thing - NEVER treat your customers as a test suite.

Of course I'm aware not everyone can afford operating like that. But at least this could be their goal. "Let's make breakage affect more people, so we know about it earlier and when we're at work" is a really silly conclusion.

<comment><USER3> __EDIT __: I posted a rundown of our deployment process, including where and how tests happen, and why they failed to catch this bug, at<http://news.ycombinator.com/item?id=2301680> .

While I'm sure there's a lot of stuff we could improve, the situation's not exactly as you describe.

Responding to a few contacts:

1 & 2\. We do have a list of "if this breaks, contact this guy." What we don't have (in response to your first point) is a demand that those people be available Sunday night.

3\. We have a known rollback procedure. It does not work if we do a irreversible schema change _and_ the problem's not caught until 20 hours later. We couldn't just throw out 20 hours of data.

4\. We actually do a lot of testing. Beginning on Wednesday, we deploy to our early leak accounts. We steadily increase that through the week. The problem with this particular bug is that you could use Kiln lightly (most of our test accounts are not large accounts) without hitting this problem at all. Even the full QA test suite did not trigger the problem. That happened because Kiln was designed to keep working in the case of a FogBugz communication failure until it couldn't, which was directly proportional to how much you used Kiln. The real problem here, which has been fixed, is that Kiln should _not_ attempt to hide a problem communicating with FogBugz.

5\. We don't do release in the middle of the day. We do them at 10 PM. I have no idea where you got that.

There's a lot we can improve. We need to make sure Kiln not talking to FogBugz, which can bring down Kiln, hard-fails, instead of trying to continue. We need to make sure that all hands are on-deck when people are going to work, as you noted, which is vastly easier to do midweek than Sunday night. And we probably ought to add more automated testing to the integration points. But I think you're painting a somewhat unfair picture of the current situation.

<comment><USER4> > What we don't have (in response to your first point) is a demand that those > people be available Sunday night.

Boring, un-agile places have concepts like 24/7 rosters of operations staff and the ability to rotate "on call" duty amongst developers.

However I agree with your conclusion that performing irreversible rollouts are best achieved during (your) daylight hours.

> The real problem here, which has been fixed, is that Kiln should not attempt > to hide a problem communicating with FogBugz.

Question: why wasn't an alert raised immediately?

</comment></comment></comment><comment><USER5> Wait, what?

You have large numbers of paying customers to whom you're delivering a mission-critical system (source control isn't exactly optional), and your releases involve neither automated production monitoring/continuous deployment nor formal release procedures?

I think your problem is more than just weekend deployments!

My full comments here: [http://swombat.com/2011/3/8/fog-creek-dont-do-cowboy- deploym...](http://swombat.com/2011/3/8/fog-creek-dont-do-cowboy-deployments)

<comment><USER3> The releases are both automated (except for one component, as noted, which we are now automating), and are fully vetted.

Here is the old release process:

1\. Monday morning, the version to be used for the next release is automatically built for the QA team, who begins running their test suites on it and doing soft checks.

2\. By no later than Wednesday, the new version is leaked to testing an alpha accounts on Fog Creek On Demand. Tests are re-run at this point.

3\. The leak is increased later in the week if the QA results look good, or the weekend release is canceled, depending on how testing goes.

4\. Provided everything has been good, on Saturday night, the leak is increased to 100% of customers. This step does not have a full QA rundown, because the code has already been vetted several times by QA at this point. The sanity checks are truly sanity checks.

5\. At the same time, we monitor that our monitoring system (Nagios) agrees that all accounts are online and that there are no major problems, such as massive CPU spikes.

So far, so good. The issue with this release is we had a bug that did not manifest for awhile, because Kiln had been deliberately designed to ignore the failure condition "as long as possible", which ended up just being too damn long. Once we started having failures, we noticed--that's why our sysadmin called us in--but those failures started happening 20 hours after the 100% release, and several _days_ after testing and alpha accounts were upgraded.

I am not arguing our system is perfect, but I'm a nonplussed where the your- deployment-system-totally-sucks stuff is coming from. I'll ask our build manager to post an even more detailed rundown.

<comment><USER6> Sincere question: how do you leak irreversible schema changes to a subset of accounts? Isn't the point of the leak that you're not confident and might need to reverse it? Or are you willing to let those accounts get hosed?

<comment><USER7> Fix it by hand. If it's ten accounts, that's pretty easy. If it's ten thousand, more of a problem.

When you read irreversible, think "very difficult to reverse and not worth the cost of writing and validating code we don't ever expect to run."

</comment></comment></comment></comment><comment><USER8> I work for web dev agencies and it surprises me just how often they launch on a Friday afternoon despite how every single developer pleads with them that its an absolutely awful idea.

Golden rule, Never launch on a Friday.

Personally i've found it easy to persuade clients to do this once you say it'll cost an extra ten grand just for the privilege of a friday launch.

</comment><comment><USER9> I feel for you. On the plus side, process improvements to prevent it from happening next time are _exactly_ how you should respond to things like this.

One which has saved my bacon numerous times is investing a few hours into tweaking monitoring and alert systems. I hear PagerDuty exists to help with this. I use a bunch of scripts and bubblegum, and even that caught 10 of the last 12 big problems. Queuing systems dying has hosed me many times over the years, for example, and a borked deploy which causes that would have my phone ringing before I got my laptop closed.

</comment><comment><USER10> Deploying in weekend or at night is a terrible idea in disguise of a good idea. What we used to do are:

\- No deployment on Weekend

\- No deployment on Friday

\- No deployment after 4pm on Monday to Thursday

\- Deployment is rolled out in stage: one server, 5%, 10%, 50%, 100% of servers.

\- Rollback steps must be accompanied with deployment steps.

\- Verification steps must be specified in the deployment ticket. Verification is done by QA or OPS, other than Dev.

\- Common deployment and rollback steps are automated.

\- Emergency deployment is an exception to the above but must take extra precaution to babysit the deployment process.

Stress level has gone down a lot and problems are resolved much faster once we have the above.

</comment><comment><USER11> Amen.

I've tried convincing many companies I've worked for that weekend deployments are a bad idea over the years.

Even with continuous integration tests, rolling deployments, and all the precautions in the world things can still happen.

You need live people available to handle a deployment.

Personally, I don't like working on weekends. I've worked for companies that refused to believe that this was a bad idea. I learned pretty fast that life is too short to work on a weekend.

If something does go wrong, it's better to have people on hand to correct the error and get back on track. It's much easier to schedule those people during the work week. It's not rocket science.

</comment><comment><USER12> I agree that weekend deploys are a shitty idea, but isn't the real issue here not being able to roll back?

<comment><USER3> Probably? I'm welcome to be schooled here. 90% of the time, we can roll back instantly, because there were no database changes. 5% of the time, we can roll back with slightly more pain, because the database migrations were reversible. In this case, the database migration was not reversible. If we'd noticed immediately, we could still have just activated snapshots, but we didn't notice until 20 hours later. What do others do in this situation?

<comment><USER13> Wait. What blew up that it took someone 20 hours to realize? The first thing you take from that is, don't do _anything_ without double-checking your change to make sure it worked.

In terms of rollback, just don't do anything which isn't reversible. Taking chances with your changes is taking chances with your business. If you don't know how to rollback whatever you're doing, ask someone who does (there is _always_ a way to roll back or add redundancy).

<comment><USER7> "The failed API call turns out to be one that's trivially cached for a very long time, and so is one that Kiln would allow to fail without actually dying."

</comment></comment></comment></comment><comment><USER14> I was taught that Thursdays are best for deployment because you got Friday to fix stupid things, and then weekend to fix the terrible things. By Monday all is working anyways.

And best of all, Friday people are generally happy (it is last day of the week), respectively on Monday expect grumpy users.

<comment><USER15> Isn't that a Monday launch? :)

</comment></comment><comment><USER16> Users seem more comfortable with predictable maintenance than arbitrary outages. Weekend deploys are just bad all around.

When I began in my current role (managing QA/DBAs and app deploys) one of the first things I killed was the late Friday/weekend deploys. They are spirit- crushing and if they go south, they usually go south in a terminal-velocity nose dive.

We set up early Fridays for maintenance, to give us enough time in case something goes south. Aggressive Change Control Requests means the people impacted get a heads up (including Account Managers, who in turn inform clients) _if_ there are any user-facing impacts, and we avoid trying to pack too much in at once.

Having QA, Engineering and the SOC team on hand is...helpful. Maybe its paranoid, but its been very solid so far. When things have gone south, I think the events -since everyone is "on deck" have actually helped build some cameraderie in the teams themselves.

<comment><USER17> I seem to accrete job roles, and one time I was so far behind on my testing that I went to the boss to ask for a Wed-Sunday work week so I could get some actual work done without interruptions.

The first fortnight was great, got through a lot of backlog on sat/sun.

The second fortnight sucked as I was blocked on stupidly trivial issues. That ended the experiment.

I guess the moral of the story is to pick and choose your 'out of hours' work wisely.

</comment></comment><comment><USER18> In my experience , there are two kinds of deployment -- ones without DB changes and ones that are accompanies with DB changes.

The deployments that do not require DB changes are easy -- mirror the prod box(non db) onto a smaller box, , deploy upgrades/updates to prod box . If things go wrong, put mirror box online with a DNS/proxy configuration while apologizing to your customer who complain about slower performance .

When DB changes are involved , you need to have your DBAs do a dry run of backing out changes-- after all practice makes perfect. Communicate scheduled outage to customers, backup db . Mirror your production box. Roll put update -- if things go wrong, restore DB and bring the mirror box online.

I have always focused on DB aspect more -- loss of integrity of data can cause customers to look for your replacement.

But I am not sure if weekly upgrades of production environment with paying customers is advisable .

</comment><comment><USER19> I'm lucky to run a system that is small enough that an entire deploy consists of around 2 seconds of downtime for the server to restart and start the new instance of the application.

We deploy new versions side by side and then then the webserver points at the new application on restart.

Only time it takes any longer is when there are sweeping database changes(schedule the downtime, inspect snapshots incase of issues, etc.)

</comment><comment><USER20> We use PagerDuty (<http://pagerduty.com>) at HipChat and while I absolutely loathe being woken up by it, it's helped us identify issues during off-peak hours much more quickly.

But no matter what systems you have in place or how many hundreds of deploys you've done, there's always a new way for things to break.

<comment><USER21> I am guessing that HipChat is a startup?

Because as an employee any pager I had would be left at work.

</comment></comment><comment><USER22> Oh god. I release 5pm pacific every week because users "can't have a single second" of downtime. We manually test an ever growling checklist fo functionality. There is always, always an issue. The angry emails start to roll in around 5:15 pacific.

</comment><comment><USER23> Their problem isn't their deployment process, its their monitoring.

Blindly ignoring errors is a recipe for failure. You should always look at situation like that asking "how can we monitor this weak point?" Logging plus a service like Splunk work great.

Should always have a solid on call rotation. We have two rotations, and ops one which is first line, and dev in case deeper code changes or more eyes on it are needed.</comment>


Show HN: A Search Engine That Solves a Nationwide Problem - <AUTHOR> http://www.browseu.com/ <comment><USER2> Just as a heads up: "Total debt has surpassed (enter number)" on [http://browseu.com/about-us.php](http://browseu.com/about-us.php)

<comment><AUTHOR> wow... thank you for that.

<comment><USER2> No problem. Congrats on the launch and all the best!</comment></comment></comment>


Pound Dwolla: Tweet money to your friends with #dwolla - <AUTHOR> http://blog.dwolla.com/pound-dwolla/

<comment><USER2> My red flag alarm is screaming right now. I hope they have some amazing fraud protection here.

It's way too easy to compromise a twitter account, I'd to have that attached to my bank account.

<comment><USER3> More that it's way too hard to navigate twitter without giving some random app write permission to your account. Modifiable permissions would help a lot, but of course Dwolla can't do anything about that.

<comment><USER2> That too! Every one of those apps that has write access to one's timeline can now send money wherever.

</comment></comment></comment><comment><USER4> I really like stuff that creatively combines two worlds for sake of simplicity. Not sure if this particular one is going to take off (security/fraud concerns etc.), but I do think that these combinations are all blips on the way to an inevitable, universal, and simple system that lets people take any number of actions without having to context switch (e.g. telling your mobile device to send money to a friend, make a dinner reservation, and share that you paid back your friend and are going to dinner).

Sucks that we have to wait for it.

</comment><comment><USER5> It looks like someone else built this almost 3 months ago: <https://github.com/nmanousos/pounddwolla>

</comment><comment><USER6> I'm assuming the receiving entity also has to have an account with dwolla, or is at least instructed to create one to receive their $?

</comment><comment><USER7> This seems somewhat Hashpay.com inspired: <https://twitter.com/ffloat/status/269959712290791424>

<comment><USER8> yeah "inspired" haha :)

</comment></comment><comment><USER9> To your friends in the USA. As Dwolla is USA only.</comment>