It's Not Sabotage, They're Drowning - jeffrey-sherman https://shermanonsoftware.com/2019/11/15/its-not-sabotage-theyre-drowning/ <comment><AUTHOR> I can perhaps understand where this one is coming from:

 _I refactored the code from untested and untestable, to testable with 40% test coverage. The senior architect is refusing to merge because the test coverage is to low._

You have a piece of software running in production; even if it's poorly written and bereft of tests, your customers are satisfied. Customers (unwittingly) have already vetted this version! A rewrite, even with brilliant design and fantastic test coverage, is still more of a risk than fixing what isn't broken.

This isn't to say that you shouldn't rewrite code, especially if it makes other improvements possible. But don't discount how high a bar new code has to reach to measure up with "it already works". Maybe 40% is still too risky.

<comment><USER2> You don't want to test code. Coverage is mostly useless.

You want to test functionalities: setup end-to-end tests. It will be hard, it will take time and it often is a solo endeavor for the first months. But when tested functionalities stop breaking for no reasons even when you refactor a lot of code, when "the project for which a dev put tests" starts being "the project we are confident to push to prod without breaking things" you should get some traction.

And once you think all your functionalities are tested you can measure code coverage: what is not covered should be dead code you can remove.

<comment><USER3> I can't get behind this.

End to end tests are indeed important.

But let's say you have an end to end test that covers A, B, C, D, E, and F.

One day this test stops working. Well, what's the culprit? A? B? C? D? E? F? If you had more granular tests in addition to the end-to-end tests, you'd know.

Now, I agree there's a possible downside here. Maybe there comes a time when C and D are no longer being used. It might not be obvious and C and D could linger in the code base, with corresponding dead weight in the test suite. This is not ideal. However, I would rather have this than a tough-to-debug test failure.

<comment><USER4> > Well, what's the culprit? A? B? C? D? E? F?

Probably, the one you just changed. How often is it really going to be that hard to debug?

<comment><USER5> I only changed L, which is nominally unrelated to all of those. You thought this was a clean, well-modularized codebase?

<comment><USER3>
        You thought this was a clean, well-modularized codebase?

Well, even if it's nice and clean A, B, C, D, E are each going to have their own dependencies!

</comment></comment></comment></comment></comment></comment><comment><USER6> Nobody's better at letting better be the enemy of good than software engineers. For some reason our culture likes to argue and nitpick over the most mundane stuff, usually missing the forest for the trees.

I've had jobs where the manpower spent just arguing outweighed the cost of the change significantly. One dickhead manager I had spent weeks arguing over the acquisition of a $500 SSD. It made me want to slap $500 down on the table just so he'd shut the fuck up already.

The only way I know to counteract it is by saying "don't let better be the enemy of good".

<comment><USER7> A few points:

1\. Computing and engineering in general is such a discipine where one nitpicky detail can make all the difference. One bit flip, one keystone, one badly selected material. However, the conduct of negotiation, could be improved as always, but it's a general listening problem most of the time.

2\. From the dickheads point or view, everything can be solved by spending more money on HW. Each unexpected spend like this is a risk to open the floodgates and lose both financial and engineering discipline by setting a bad precedent. Not sure you want easy handed decisions there as well.

<comment><USER8> It makes no sense to cheap out on hardware though. It's such a tiny cost compared to the overall cost of the employee, you are wasting money if inadequate hardware is making your employees less productive.

<comment><USER9> In one sense, it doesn't make sense. The productivity boost would likely be worth it alone.

From another perspective, this is a +500$ post in the cost column of that unit (and perhaps n*500 if the whole unit then comes asking for the same thing). The cost of spending time arguing is baked into the cost of salary, meaning it doesn't show since it's the same regardless. It's a form of optimization, but the optimized unit is not productivity.

A friend of mine was working as a recruiter where the whole company was sitting all day long at their laptops. He was denied buying an external screen to be more efficient since he then could have more information on the screen (eg an application next to a browser), "because then everybody wants one", even buying it himself.

edit: nb I'm not arguing for not buying the ssd/screen.

<comment><USER3>
        He was denied buying an external screen to be more
        efficient since he then could have more information on the
        screen (eg an application next to a browser), "because
        then everybody wants one", even buying it himself.

My wife was denied permission _to bring her own secondary monitor from home_ for that reason. Unreal.

I also faced pushback at one job for bringing my own monitor from home. Same reason given. I'm an entitled software developer though, so I basically disregarded my manager on that one and he let it go.

<comment><USER6> We set up a monitor for my wife at her large corporate job without asking permission. While the rest of her office had tiny 1280x1024 screens from 10 years ago, she had a 1920x1200 24" monitor in addition to the corporate shit monitor.

Sometimes people would ask her about it, she would say she bought it herself, and they would say "oh" and move on about their day. It was a complete non- issue.

You could argue people shouldn't be plugging in random components at work and whatnot, but at the end of the day, IT is really powerless to do much about it. Nobody's going to fire you for buying your own productivity enhancers, the situation is just too embarrassing for management if they're reasonable people.

And really, Excel is so focused on visual space that having a larger display for her is a quality of life issue that only costs $120.

<comment><USER3> I completely agree, but there really are managers petty or shortsighted enough to block this stuff.

I think one mistake my wife made, though, was mentioning it to her boss before she did it.

What she should have done was _done it._ Then her boss would be more inclined to let her keep it.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> I think it's kinda hilarious that the article talks about a psychological effect that hurts software teams, and HN gets into a full-on debate about software testing strategies ;)

I've seen this stuff before. Developers making obviously-bad decisions is usually a symptom of a dysfunctional work culture and a code base that's both vital and fragile. It's not fun to work in such places, but it is possible to fix them.

<comment><USER11> The main issue is for management to accept that velocity will be significantly reduced and that many issues will pop up along the way and require a substantial QA effort to keep the quality from dipping too low.

It's still the best way forward as a complete rewrite is rarely a good idea.

<comment><USER10> yeah, I had to explain to a CEO that we weren't going to be shipping any new features for a few months while we upgraded core systems and eliminated tech debt. It was a tough conversation. But about 6 months later we were able to start developing new features again, and everything was much quicker and smoother. The lead dev had regained his composure, too, and wasn't being actively obstructive to everyone who tried to do anything to "his" code base.

</comment></comment></comment><comment><USER12> So many years ago I was involved in an issue with a BTS (a cellular radio base station) for a telecoms equipment manufacurer. The software was written in C, and had a message parsing architecture between processes, with fixed length queues, which discarded messages when they overloaded.

There were various problems (the subject of a number of war-stories, which I won't repeat now) - but basically anything that wasn't using a properly designed state machine could die horribly when messages started getting discarded.

So we did some work around the fundamental design of the queue handling mechanism. We came up with a software modification which would improve the efficiency of the queues handling, which would stop the queues overloading (which we saw happening occasionally at peak loads on the biggest BTSs).

We could measure various aspects of the queue handling performance, and use queuing theory to prove that the performance would be better at very high loads.

We had a test rig and we could test the relative performance of the new software vs the old software at normal loads.

What we didn't have, was a test rig which could run at the highest loads, so we couldn't test the behaviour of the new algorithms at very high loads.

So the improvements were binned. The existing software was known to fail (badly) at extreme loads. The new software could be tested at reasonable loads, and mathematically be shown to improve matters at very high loads, but because it couldn't be tested, the process said that it must not be deployed!

<comment><USER13> How was the original version deployed? The definition of 'very high load' was different at the time.

</comment></comment><comment><USER14> A possible way to sell instrumentation / metering is to build your own scaffolding, find a problem using it, and sell _both_ the scaffolding _and_ the solution it's provided.

As the article notes, metering _by itself_ simply illuminates problems. For the drowning team (or individual), that simply delivers bad news.

If you can show that the effort actually delivers results, you've got a way to sell the instrumentation as well.

In more pathological cases, you don't reveal the scaffolding, but start cranking out code fixes based on it. You may have the opportunity to sell the metering later, when you're asked how you're finding and fixing the problems.

Rescuing projets from antipatterns is painful at best. Enlightenment is a painful process. It peels away comforting lies to reveal unpleasant truths.

</comment><comment><USER15> When I was trained in lifesaving, one strategy for panicked victims, who might drown the rescuer, was just to give them some space to drown enough to lose consciousness. Then they were much easier to rescue.

<comment><USER16> it doesn't usually apply to drowning victims, but more broadly its applied when someone is choking in general.

if someone is refusing help, you wait until they pass out, and it becomes implied consent. I assume in this example, that would be firing or otherwise being told by your supervisor to take the help.

<comment><USER17> Consent isn't necessarily the issue in drowning individuals, since the instinctive drowning response can make it dangerous to save them even if they're not about to tell you 'let me drown'. Maybe actually a good comparison for software teams that refuse to make incremental improvements out of fear or panic... it's not that they don't want things to be better or refusing help, necessarily - they're just terrified of the consequences if the improvements go wrong.

</comment></comment></comment><comment><USER18> >I refactored the code from untested and untestable, to testable with 40% test coverage.

This tells me you think "coverage" is a good metric, which also tells me you're you're not covering a whole lot of cases (edge or not) where the "untested code" functioned as it should.

You're asking to replace something which has potentially some known issues, with something that has a potentially unlimited amount of unknown issues.

And the more experienced person at your job refused? What a tyrant!

<comment><USER19> I strongly disagree.

The said refactoring was probably not a huge task since he is reporting it done. Larger tasks are most often planned and monitored.

Splitting some class and decoupling some resources + adding the testing framework and implementing a first batch of tests. Of course it might have introduced few regressions.

But

> has potentially some known issues

Read again that. Exactly, none knows how many bugs there are, only how many were found so far. Bug tracking is often lacking, behind schedule, wont fix, etc.

On the contrary modern code analyse tools are frightening good at spotting untested conditions every where (sonarcube comes to my mind). Much better and much reliable than human developer and human tester. Sonarcube does not care if the case can not happen because user interface does not allow the input. The bug is here, and the bug is spotted.

The more experienced person is plain wrong : more tests is better. It's not panacea yet, but it's better.

<comment><USER18> function int untested_sum(int a, int b) { return a + b; }

function int tested_sum(int a, int b) { return a * b; }

function void test_providing_total_coverage() { assertEqual(tested_sum(2, 2), 4, 'Expected sum to be 4!'); }

<comment><USER20> Which is why I'm a big fan of testing tools like hypothesis:

        from hypothesis import given, assume
        from hypothesis.strategies import floats
        from math import isnan, isfinite

        def tested_sum(a, b):
            return a * b

        @given(a=floats(), b=floats())
        def test_sum(a, b):
            assume(not isnan(a))
            assume(not isnan(b))
            assume(isfinite(a) or isfinite(b))
            assert tested_sum(a, b) == a + b

Running that test gives

        Falsifying example: test_sum(a=0.0, b=1.0)

Note how it also forces me to put a bunch of assumptions in there explicitly, hypothesis is _very_ good at finding weird edge cases. For this example I don't really care that it goes wrong when NaN gets involved, but if I did I discover through testing that that case even exists.

</comment></comment></comment></comment><comment><USER21> Reminds me of this scene from Frank Herbert's Dune:

"Because of an observation made by my father at the time. He said the drowning man who climbs on your shoulders to save himself is understandable– except when you see it happen in the drawing room." Paul hesitated just long enough for the banker to see the point coming, then: "And, I should add, except when you see it at the dinner table."

</comment><comment><USER22> > I refactored the code from untested and untestable, to testable with 40% > test coverage. The senior architect is refusing to merge because the test > coverage is to low.

what's likely even more frustrating is that other merges went in for years with no tests or testing in place at all.

<comment><USER23> Seems like unit tests are only really valuable for library code. Application/glue code... not so much, especially if it is something being actively developed and you are constantly throwing away tons of unit tests.

<comment><USER24> Totally untrue. Unit tests in strict sense, perhaps, but nobody writes true unit tests - there's a high chance these are actually short range functional or integration tests. Such tests are of high value.

<comment><USER23> Maybe it just depends on the context. I write embedded linux applications. One application I wrote talks to a Qualcomm modem using their QMI framework and then passes on messages to an antenna subsystem.

I wrote some library functions, which were easily unit testable, then I wrote the glue code, which I found wasn't very testable at all. I found myself having to stub out the entire QMI Framework/modem and the entire Antenna subsystem API since obviously I don't have access to those things at build time. So basically now my application/glue code is being testing in a fake vacuum that may not even reflect the real behaviors of the modem or antenna. So I waste tons of time trying to predict how the modem and antenna might behave, and test my application code accordingly.

Lastly, I end up scrapping a bunch of the tests because the actual behavior of the modem/antenna is different than I predicted and changes slightly with each update.

</comment></comment></comment></comment><comment><USER25> The way to establish change is to do it gradually, with buy-in from all parties _prior_ to introducing the change and to make small steps in the beginning. If you showed up with a huge chunk of code that has been refactored I'd probably not merge your change either. The test cases have been written by the same person that did the refactoring, there is a _very_ good chance that any wrong assumptions you made about the code will be present in both.

</comment><comment><USER26> This allergy to reality is surely the biggest trap not just for startups but people in general. It's surprising but I feel like the norm is for people to care far more about feeling that everything's okay, rather than everything actually being okay.

That said, one problem I see with the anecdotes provided is that the problem solver is doing two things: discovering a problem and solving it. Conflating these two things is a great way to encourage pushback: every change comes with an associated risk, so the general rule is to say no (using whatever flimsy reason) if it's not well understood and agreed that the problem being addressed is a real problem worth solving.

<comment><USER27> > ... the problem solver is doing two things: discovering a problem and > solving it. Conflating these two things is a great way to encourage pushback

This squares with my experience strongly. At a prior job, I remember two or three times where a set of changes was almost rejected for production because despite solving real bugs. The bugs hadn't affected anything in production yet, but the fixes carried the risk of _maybe_ breaking something.

This resulted in some fun times, like a particular client running something like three major versions behind on our software, precisely because management didn't want to accept any disruption risks there, and the old version grumbled along well enough.

</comment></comment><comment><USER28> > When you add visibility to a system, the numbers are always bad. That's why > you're putting in the effort to add visibility to an existing system.

This is something everyone needs to internalize. Don't be upset if the numbers are bad when you first instrument. That's WHY you instrumented. Instrumentation is a ratchet to help you improve your product.

</comment><comment><USER29> I think saying 'they're drowning' is still giving them too much credit. People who built terrible broken systems don't know they are bad at building things, and they probably don't have a clear idea of what would be better or worse to begin with. They don't know it's better to have a system that can be debugged, they don't even know what the difference is. If you give them examples of good designs and bad designs, they can't tell you which is which. When they say 'this is good' or 'this is bad' they will astound you with the reasoning.

Software is an industry with no standards for employment. All it takes to be a Software Engineer is for an incompetent manager to hire you. More than half the people I interview barely have a basic familiarity with writing software. These are people who have been employed as software engineers for years and will certainly find another job. They struggle to write a nested for loop. They write functions with thousands of lines. They just don't know what they are doing.

The author here claims they don't want the visibility of the situation to increase, but I think they don't know it's a problem to begin with. Their stupid excuses for not moving forward are just their stupid thoughts said out loud.

<comment><USER30> My team has built garbage software at times. It isn't because we don't know how to build good software, and it isn't because we don't care, and it isn't because we don't want to build good software.

It is usually because of a continuous sequence of emergencies to which we are forced to react.

An emergency occurs, and we have requirements to do something in 1/3 the necessary time. We get 80% of the way though that and, before launch, there's a new emergency, and we have to rush to that.

So we end up with crap software that looks like shit and only almost works.

But it almost works enough to keep our very large business humming along. Sure, we hate it, and we're making more technical debt, and over time, we get less effective.

But sometimes we go through cycles of a year or two when the business either can't afford to do it right or isn't willing to pay the price to do it right.

Sometimes, they really are willing to accept paying 10x as much so long as they can pay in a year or two.

(I hate it, but it is true)

<comment><USER24> Make it 100x as much with 5 times as many people in 10 times as long. Efficiency is never important when there is money to burn and it's not yours, and you won't be blamed when it breaks.

It does not even take any emergency - often it is conscious or subconscious project management strategy.

It's related to observations about Peter principle, Dilbert principle, Gervais principle and office politics and dynamics.

Avoiding this tendency is essentially only possible with small teams with full ownership of the problem they're working on and direct stakes.

</comment></comment></comment><comment><USER13> So being the person that's manning the lifeboat, what do you do? Kick them down?

If you do nothing everyone will surely drown.

</comment><comment><USER31> Could it be a competence barrier to protect incompetence? I have experienced so many similar experiences, normally with middle managers who are terrified they will get caught out for not knowing what they are doing. I noticed they always stick with brands like Microsoft or SAP are deeply suspicious of open source. Oh and they dont drown, they get promoted. Could this be an opportunity for a startup to identify this risk "as a service"

</comment><comment><USER32> Between sabotage and people wanting to sink the lifeboat, I have a third option: These people have a warped perception of what's happening and priorities around what's happening. Warped by their own irrational beliefs which have come about as a result of cognitive dissonance reduction. Initially, they can see how messy & bad things are but since they, themselves, are responsible for things having gotten to that point, they start bending their own beliefs in a way that will make themselves and their past actions look good. In the final phase of this psychological process, some kind of Stockholm syndrome kicks in in relation to the poor standard of engineering that is making their lives miserable: They start to actively seek out poor engineering because it's the only mode of existence that their psyche will allow them to fathom.

Warstory time.

A tech company I worked at was being encumbered by a codebase with poor code quality. Bugs were being introduced all the time, with no chance of preventing it because nothing is testable/tested. Bugs were introduced at a faster rate than they were fixed. The whole system was a timebomb because it was built in a dying ecosystem. For certain kinds of code changes, their effect couldn't even be made visible at development-time at all. You had to release them into the production system and look at metrics to see their effect, hoping that nothing would blow up, so the system was layers and layers of code that was trying to be minimally-invasive with respect to existing code.

Whenever an engineer would be newly hired, they would, within their first week of working there, suggest "Let's take a month to refactor this/that part of the system". When an oldtimer would hear the new guy say "refactor", their warped perception would hear "accomplish nothing" or "threaten our mode of existence". They would give the following speech: "Hey, get it in your head, noob: We don't do that here. This company is not focused on code quality, it's focused on a mission. Every week we come to work and we accomplish a part of a mission. I _KNOW_ the code is probably the worst piece of shit you've ever seen in your 20 years. [This company only hires extremely experienced people]. The engineers who work here are all on board with our mission-driven culture and pride themselves about their skill at dealing with the shitty codebase. Your suggestion tells me that you can't deal with it, and you are unwilling to absorb our mission-focused culture. You will not get a career out of working here, unless you properly absorb that element of our culture".

So, in their mind, they'd taken "shitty codebase" which is a negative, and turned it around and made it into a religion about a "mission-driven" culture which is a positive. [Cognitive dissonance reduction at work, right there]. The reality was, of course, the poor code quality was a huge drag on this company's ability to accomplish a mission of any kind: Because changes that took their competitors a day, took them a week. Changes that their competitors did in a month, would have been a suicide mission for them and they therefore rationalized their way out of even wanting to do them. ...but I wouldn't recommend to the newly hired engineer in the story to mention that particular elephant that was in the room.

Now, here comes the really sick part, where the picture of the drowning man falls apart: From time to time, due to a rare alignment of circumstances, this company might be _forced_ into a situation of starting an implementation of a new element of the system with a clean slate, i.e. completely unencumbered by the current codebase. They would _intentionally_ implement the new codebase to be just as shitty as the legacy code. They would implement it in the dying ecosystem. They would generously insert unreachable code. They would pursue the fastest path towards making it untestable.

Now, under normal circumstances, if I hear someone telling that story, I would suppose there might be a motive for this. For example, I've seen developers in hedge funds intentionally rig a system to explode if they should ever be forced out of the company and be as hard as possible for anyone else to fix, for obvious reasons having to do with their incentivization structure. But that's not what was happening here. They had a culture of openly sharing knowledge of the system, were hiring new people all the time, and working hard to bring them up to speed about the system's working etc, so it wasn't that.

My guess is that it must be the "Stockholm syndrome" element I mentioned: They started to develop a psychological attachment to a poor standard of engineering. It was making their lives miserable. But it was also the only existence they knew and they felt was available to them, so cognitive- dissonance reduction was maneuvering their psyches into actually favoring that mode of existence.

Some might have said things like: "One day, after we've grown enough, we will do a complete rewrite." Or "Any day now, we might be acquired by another company and will leave all of this behind". But it was more in the vein as when a religious persons speaks of a glorious afterlife.

There is a lot of really sick shit that the human psyche is capable of, and sometimes it surfaces in engineering. I think that's my takeaway from all this.

<comment><USER33> I have so many war stories there's not enough space on HN to contain them. I'll just state my overall experience. I write elegant well designed code, but generally speaking you won't find that anywhere especially if you're working in teams. Unless the code is all written by one person who had a chance to design and implement it well solely by themselves with adequate time, it's going to be a mishmash of they just didn't have time and the pressure was on.

I'm of the mindset that if it works, it's good code regardless if it isn't. This I think is the healthiest mindset to have in any team. I will refactor things slowly to clean up issues and of course my own code is well thought out and integrated into the codebase regardless how reckless anyone else is being. Any other way of interacting with a team would be antisocial and not beneficial ultimately. The way I see it is they wouldn't be paying me if there wasn't more work to do. The most important thing is that it works and the customer is happy. Your disappointment with elegance or coverage comes second to that.

The thing that actually annoys me is when, having exceeded my own delivery deadlines and everyone else's if I provide value added like a new feature that puts us far ahead of our competition I get pushback. Management doesn't want to have to maintain it. Even though my code is really solid compared to the rest of the garbage going in there. They just see me as a plumber fixing a leaky pipe and don't want anything further. I get that there's ROI and whatnot but it still bothers me when I show them some next level shit and I'm told to mothball it. Especially when I'm the reason we're usually way ahead of schedule. </rant>

<comment><USER32> I've had that same thing happen to me numerous times too. I wrote code that demonstrably and undisputedly added to the value of the product in a way that went far beyond anybody's expectation. I took no longer to do it than it would have taken to do it the "normal" way. People get mad at me making the argument "Well if you leave the company, somebody else is going to have to understand your next-level shit, and we just simply don't have people here who can do that. So then what?"

<comment><USER34> I think it depends on the details. If your code is simply cleaner, well documented etc, then fully agreed.

If you introduce new dependencies, or the latest free monad transforming framework when there was none, then I'd be wary as well.

<comment><USER32> I don't do "framework" ;-) In fact I'm usually the first to protest when somebody tries to introduce frameworks or other bloatware. And getting excited about algebraic structures is something I got out of my system while doing my PhD. I'm strictly talking: Value-add to the product, albeit at the cost of higher complexity to the extent that it is unavoidable.

</comment></comment></comment></comment></comment><comment><USER35> This is one of those things you don't truly understand until you've experienced it first hand. I have. Very appropriate metaphors.

</comment><comment><USER36> In my world (marketing, not dev) the saying is "you cannot optimise something you do not measure".

</comment><comment><USER37> "I think that is not sabotage, but I don't have any real data that support or dismiss my statement" would be a better title.

Your mileage may vary.</comment>


Ask HN: Initial user traction for two-sided market platforms? - <AUTHOR> How can you get initial users for platforms that involve two userbases? Platforms such as Amazon, Medium, etc? <comment><USER2> First figure out which side is harder to attract. Demand side or supply side? In most cases the demand side is harder as you could easily get people/companies who want more $. This however does not hold in every market.

I am going to use the term the marketplace driver for this. Not sure if it already exists.

The market place driver will make the platform attractive for the other side.

A strategy for this could be to intially offer something of value to the marketplace driver without the need for the other side. So they get value without having to conclude a transaction.

Then eventually transition to the marketplace business model.

Another tip would be to focus. like around a geographic location, product or niche service. Then expand out from there.

</comment><comment><USER3> Which vertical are you working in?

In 99% of cases you're going to need to seed the initial content/products/services.

\- The two Reddit founders created thousands of accounts and posted all the content, this gives the idea of 'busyness'

\- The Paypal founders made a ton of eBay listings themselves and set Paypal as the payment method, to increase awareness.

\- Airbnb seeded their initial content by posting listings of the properties on Craigslist and included a link back to Airbnb.

But just throwing money and/or resources at a problem doesn't prove that you're actually creating a sustainable business solving a real-world problem that people have.

</comment><comment><USER4> Cheat. Like pg would say, "do stuff that doesn't scale" \-- this means:

\- Paying for quality content. If you're starting a blogging platform (e.g. Medium) and no one is reading it, you need to get some high quality content on there. Pay some top bloggers or people with social followings to write something on your site.

\- Paying for traffic. If you built a cool social platform, you can "force" going viral on reddit, twitter, etc. by buying upvotes & retweets. If the content is high quality, the content will organically blow up after the artificial "push."

\- Offer crazy incentives. Say you're building an Amazon competitor. Do crazy stuff like "if your product doesn't sell in 14 days, we'll buy it for you!" Obviously, this can't scale, but when first starting out, it can be a useful strategy.

Whatever you do, you're going to be burning cash. There's no way around it, barring unicorn cases like Snapchat and Instagram.

</comment><comment><USER5> Look at the line "shoot the hostage" in the first scene of this movie:

[https://en.wikipedia.org/wiki/Speed_(1994_film)](https://en.wikipedia.org/wiki/Speed_\(1994_film\))

basically you have to find some cheat to cover one of the sides. Almost all of the successful community sites that I know of involved some kind of aggressive promotion at the beginning, enough that some people would have ethical concerns.

</comment><comment><USER6> Can you add a secondary source of value that will attract one of the parties first?

</comment><comment><USER7> I think the rule of thumbs is to focus more on the producers, to have a quality market. This will appeal to consumers and will keep them coming back.</comment>


The DOOM 3 Network Architecture (2006) [pdf] - <AUTHOR> http://fabiensanglard.net/doom3_documentation/The-DOOM-III-Network-Architecture.pdf <comment><USER3> I really cannot wait for Fabien's book on the Wolfenstein 3D engine to come out. I really hope that it does.

<comment><USER4> Is there something particularly special about Wolf3D that you are awaiting, or just his write up on it?

<comment><USER3> More his writing. He does a phenomenal job digging into old code bases and extracting the meaning from them.

The promise of a step-by-step illustration of the Wolf3D engine is very interesting to anyone that cut their teeth playing it.

<comment><USER5> Also to anyone interested in the history of the transition between 2D and 3D gaming.

It's totally a fetish of mine, this strange period we got from 93-97 in 3D gaming, from flat-shaded polygons to the strange pixelated quad-polygons of the Sega Saturn right up until we finally got something like Majora's Mask on the N64 that truly started to demonstrate its full power.

The developments and the history are fascinating.

<comment><USER6> Any feelings on Marathon on the Mac? I recall that game feeling quite groundbreaking in the semi 3d era.

<comment><USER7> I remember I showed it to my 80-something grandmother when Marathon first came out, on the ridicuously-overpowered computer used by the department IT guy who shared an office with my mom.

My grandma said, "It's beyond my ken." And she was an amazing person - <USER2> high school math to disadvantaged urban kids (in the city - she commuted), and this was just a moment where I could see someone experiencing a whole new reality, and rejecting it for the effort it would take to accept it.

And that's not always a bad thing. My grandmother had no real reason to be familiar with what would become a huge industry and culture. But it was eye- opening to see that rejection happening.

<comment><USER8> That's really interesting that you were able to observe and understand that. I remember a few moments like that in my childhood when the internet age was dawning and not being able to comprehend how a person could reject something so marvel.

Now that I'm much older, I'm able to understand why someone might want to do that now. I wonder what it will be in my lifetime that I will be unable or unwilling to comprehend.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Dota2 interestingly enough just uses protobufs for network and replays I believe.

[https://github.com/skadistats/smoke/wiki/Anatomy-of-a- Dota-2...](https://github.com/skadistats/smoke/wiki/Anatomy-of-a- Dota-2-Replay-File)

<comment><USER10> CSGO does as well.

</comment></comment><comment><USER11> Sending game snapshot state as deltas is pretty interesting as initially thought they were sending actual diffs of snapshot but they just mean they're not sending all state at once and from the bitpacking section it looks like they're using some kind of custom binary format. The reason they're deltas is that even though they're using UDP, deltas only work when you have the previous snapshot and so they require acknowledgement of the delta, something you don't get with UDP by default. Even the compression is custom.

Extremely small message sizes was really important to them.

</comment><comment><USER12> As a web dev this kind of stuff blows my mind.

<comment><USER13> Exactly what I was thinking :)

</comment></comment><comment><USER14> this looks really great, are there any similar resources for people looking to unpack game networking protocols/optimization?

<comment><USER15> This is one I particularly liked. Age of Empires networking inner workings:

[http://www.gamasutra.com/view/feature/131503/1500_archers_on...](http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php?print=1)

<comment><USER16> This is definitely a classic. A more recent but no less seminal presentation is David Aldridge's overview of Bungie's networking approach (and more broadly all modern FPSs): [http://downloads.bungie.net/presentations/David_Aldridge_Pro...](http://downloads.bungie.net/presentations/David_Aldridge_Programming_Gameplay_Networking_Halo_final_pub.pptx)

</comment></comment></comment><comment><USER17> From the same place and somewhat related: [http://fabiensanglard.net/doom3_documentation/DOOM-3-BFG- Tec...](http://fabiensanglard.net/doom3_documentation/DOOM-3-BFG-Technical- Note.pdf)</comment>


See the power of HTML5 with campaigns from Desperados - <AUTHOR> http://www.youtube.com/desperados

<comment><USER2> Correct me if im wrong but isnt this flash? Very cool though!</comment>


How Opentable makes money - <AUTHOR> http://www.businessinsider.com/10-things-investors-need-to-know-before-opentables-ipo-2009-5

<comment><USER2> My startup is working on an Opentable competitor (beta this fall, very excited). The article points out the most important part of the online reservation business..."restaurants are really paying $515 to gain 197 new customers [average]".

They're charging for the wrong thing (big software/hardware cost upfront, and price per reservation), and not focusing on the real value that they provide which is generating new customers. The software should be almost free upfront and easy to use. The focus of the business should be generating new customers and helping restaurants better monetize and market to the diners that use the system.

<comment><USER3> They do charge per reservation and a monthly fee. The "big" purchase up front is well-known in the restaurant industry as POS equipment is quite pricey, so they may not mind the initial investment. The higher barrier to entry for OT may also help keep up quality. Do you have a particular insight into the restaurant industry that would suggest otherwise?</comment></comment>


Las Vegas makes it illegal for the homeless to sleep on downtown streets - <AUTHOR> https://www.latimes.com/world-nation/story/2019-11-06/las-vegas-street-sleeping-law <comment><USER2> This is a recurring feature of american politics that the homeless are legislated out of places to sleep. It is sad, and uncomfortable. As a homeowner who deals with homeless people I get why they want them not to be there. But eventually they have to go somewhere, I just don't know where.

<comment><USER3> One thing i never understood about Liberals (being a Liberal myself, it's just a couple of items i don't agree with), is why don't they agree that bumming must be a felony in itself? It is in many countries. Effective, proven solution. There must be no bums in the streets.</comment></comment>


Show HN: Risotto compiles JSX using Golang - <AUTHOR> https://github.com/mamaar/risotto

<comment><USER2> Dude. Gonads. Really?

The last thing anyone wants to be thinking about when doing frontend development is your junk.

Like it or not, shit like this affects how people view our whole profession. Do us all a favor and act older than 13.

<comment><USER3> Well, if it would stand for go+monad, I would actually have found it quite funny.

</comment></comment><comment><USER4> I made something similar available here: [https://github.com/tiborvass/go- jsx/](https://github.com/tiborvass/go-jsx/)</comment>


Ask HN: Can "Show HN" be dangerous? - <AUTHOR> Imagine someone submits something they have been working on "Show HN" to get some feedback. For example they developed a low latency HD video chat app (FastChat), where the person's face is modeled beforehand. Then during the chat only the movements of the face are transmitted, thereby requiring less data to be sent.
During the "Show HN" some bugs are discovered and issues with scaling, but overall the feedback is extremely positive. So they know, that it is worth working on and continue to make it a proper product (dealing with scaling, privacy, security, pricing). Since they are a sole developer it will take time to do this.
Wouldn't it be possible that Skype, Whatsapp, Zoom or some other actor in that area would copy their idea? Given that they have explained on some level how it works in the "Show HN". In addition, now that it has been shown to be possible, the big companies can assign a team to reverse engineer it.
Two weeks later, the original developer has fixed the problems and launches the product successfully. A few days later Skype introduces a new video chat feature that essentially does the same thing. No one bothers to switch to FastChat, since it doesn't have any outstanding features.
Is this scenario likely? Can it be dangerous to post your MVP on "Show HN"? <comment><USER3> If the feature is so easy to implement that Skype can roll it out in a couple of weeks, it's probably not a sustainable model to build a business on. There would be no "economic moat"[1] to protect your business against competitors. Eventually, your competitors would figure out how you implemented your algorithm and implement it themselves.

Also, even if FastChat was the only app with your new feature (maybe because you were able to patent it), that still wouldn't guarantee success. Skype, Zoom, etc. would already have a huge base of customers while FastChat would be starting with none, so they'd have the advantage of network effects (a FastChat user would first have to convince someone they wanted to talk to to install FastChat). They'd also have much more resources to throw at alternate approaches to making their apps faster, and they'd probably be much more reliable than FastChat because they'd have large operations staffs to keep their servers running under high loads. Corporate users would probably want to stick with a service with a proven track record, since this kind of service is now mission-critical infrastructure for them.

[1] [https://www.investopedia.com/ask/answers/05/economicmoat.asp](https://www.investopedia.com/ask/answers/05/economicmoat.asp)

<comment><AUTHOR> Thanks for the link!

<comment><USER3> Buffett's "moat" is one of the many useful concepts I learned about from reading comments on HN. Glad to pass it on...

</comment></comment></comment><comment><USER4> > Can it be dangerous to post your MVP on "Show HN"?

The short and obvious answer is: sure, it can be.

You might get cloned by someone with an advantage you don't have _at the moment_ , before your product can get the traction it needs to become sustaining. It's far easier (in all respects) to clone something in the earliest stages than to go through the painstaking, time consuming process of working through all the twists and turns it takes to figure out how X fits with Y. It's a weird, complex problem - when and who to show a thing to - <USER2> you're unlikely to find an easy answer to, it really can't be modeled perfectly. You don't know who is out there reading HN that might kick your ass. That's a coin flip. This site is filled full of technical talent that can rapidly clone anything you've produced, so if they have any other advantages that you lack, you could certainly be helping someone take you out.

Some people here will retort that that just means you were doomed anyway. That doesn't inherently follow. Getting an early momentum advantage such that you get some good entrenchment before the clones attack, can make all the difference, even if someone comes at your product with more capital to spend than you have for example. To the extent you get any entrenchment, you become that much harder to displace easily.

The ideal is to deliver your product to the audience that wants it. If the technical audience on HN are not the best audience for your product, do not present it to them.

<comment><USER3> > Getting an early momentum advantage such that you get some good entrenchment > before the clones attack, can make all the difference...

But in this case, I think that FastChat (the new app) is the clone and Skype, Zoom, Webex, etc. are the entrenched players in the videoconferencing market. FastChat is essentially a clone of Skype, Zoom, etc. because it does the same thing that they already do - it just has one improvement that may or may not make a significant difference to potential customers. Thus, FastChat would be trying to enter an already crowded market whose players are large, public companies (and whose most profitable customers are large corporations).

</comment></comment><comment><USER5> The scenario you describe seems worrisome, but I would consider that not getting feedback on your product is a huge danger of its own. Unless you have a big private network that you can share discreetly with, but that has its own problems in that you're getting feedback only from people that know you.

Also, I think that the probability of this happening is possibly lower than you think, as it assumes that your posting is wildly popular AND popular enough that someone at a big tech co. thinks it's worth building AND that person is convincing enough to convince his team to build your product AND they're able to move as fast as you're saying AND they execute well enough AND there is not room enough for more than one co. in the market you're after.

Even if you do manage to keep things a secret and choose a different path, who is to say that the alternative path doesn't somehow end up exposing you even more due to the large number of unknowns that you'll encounter as a founder?

You may even be able to move faster than Zoom as a solo dev depending on the circumstances. In the long run, I really don't think that a posting to HN will destroy a co. Most of the time it will be something else like lack of motivation, time, resources, etc.

<comment><AUTHOR> These are some good points. Yes, the scenario was very optimistic :)

</comment></comment><comment><USER6> It can, and for that reason it's best to have a moat. In my opinion, there's two types of moats: technical and ideological.

Technical moats are hard to pull off when you're small. I'd suggest weaving together enough features that no one will copy the specific manner or style in which you've weaved them together. If the success or failure of your product depends on the novelty of a single feature, then it's not properly prepared to slay copycats.

Ideological moats however work even with a solo founder. If you're building something that's easy to copy, you're going to take huge morale hits when other people inevitably implement the same features. You might stop and question your motivations then, or decide to quit. Often times what kills you isn't the competition, but rather your thinking that the competition constitutes a problem in the first place.

This is what ideological moats are for. _No matter what anyone else does, you 're going to continue working. You can't be killed._ The reason for this should be that your product isn't merely the sum of its parts, but is an ideal you're working towards. This might not be true, but you need to believe it anyways.

</comment><comment><USER7> It's only dangerous to your determination, and work ethic. Because it can feel hard to continue an idea if there is already an implementation out there.

Ordinarily though, to make money you will have to release the product, and competitors as well as customers will now know about you.

If your entire implantation took a short time, then it will be easy enough to clone.

To avoid cloning by a major company, you should pick an implementation that goes against one of their core user experience elements. For example, Slack began as a chat service for small working teams, and only small teams. Other chat services existed but they let you talk to anyone, or they were pure customer-service chat. Those competitors found it hard to integrate any ideas from Slack because doing so would essentially weaken their existing product.

</comment><comment><USER8> I think it is also highly possible that for the example scenario somebody from Skype or Zoom team reaches out to the poster and hires him/her.</comment>


I'm In Like With You raises $1.5 million, plans to use it all to hold a big party - <AUTHOR> http://news.cnet.com/8301-13577_3-9978390-36.html?tag=nefd.riv

<comment><USER2> This story would be interesting if it was true. Instead, it's incredibly boring.

<comment><AUTHOR> The party part is at the bottom. In the past I have seen some interesting im in like you comments, so I thought people would like the story.

"Forman told CNET News.com that the entirety of the $1.5 million would be used to throw a large-scale party, but we think that one's a joke."

My feelings are that they had better be careful about hiring expensive employees because they will blow through the 1.5 million like no tomorrow. Hire the flash game developers, buy (inexpensive) ads, don't hire too many expensive employees.

</comment></comment><comment><USER3> The editorializing of titles should really be mellowed down.

<comment><AUTHOR> The title only included factual items from the article 1) The funding 2) The humor came from the company and was not just made up out of thin air.

<comment><USER4> Yeah, I don't see that as editorializing. That would be "Im In Like With You Raises $1.5 million funding and I still have no idea what that site does."

</comment></comment></comment><comment><USER5> Good for them. I like iminlikewithyou.</comment>


Apple Reports Record Second Quarter Results - <AUTHOR> http://www.apple.com/pr/library/2015/04/27Apple-Reports-Record-Second-Quarter-Results.html <comment><USER2> I'm starting to wonder if maybe Tim Cook is a better CEO than Steve Jobs. No one will ever have Jobs' combination of taste and presence, but I think these numbers are showing that spending as much time managing the supply chain and making inroads into emerging markets is as important as playing with foam cutouts with Jony Ive.

<comment><USER3> You know how it typically takes one CEO to make a newly founded startup viable and successful, then a transition to another to keep it there? Think that's what we're seeing here.

<comment><USER2> Yes, on steroids.

</comment></comment></comment><comment><USER4> The dramatic collapse of iPad sales is interesting. A tumble of 23% is huge, to go with five straight quarters of year-over-year declines.

<comment><USER5> Most likely tablets are dead: no room between large phones and ultrabooks.

<comment><USER6> I think more likely the market is somewhat saturated. There's not a lot of compelling reason to upgrade if you have one from the past 2-3 years.

<comment><USER7> And there are few compelling reasons to develop sophisticated iPad apps anymore. App prices are low, the platform is buggy, and building a good iPad app is a more complex and expensive endeavour than building an iPhone app.

<comment><USER8> > the platform is buggy, and building a good iPad app is a more complex and > expensive endeavour than building an iPhone app.

Citation needed? What do you find buggier about iPads than other iOS devices, and what makes them harder to develop for?

<comment><USER9> iOS as a general platform tends to blast API's more quickly than most platforms--take a look at all the top-line games that needed special versions for iOS 8.

In addition, Apple has it's own "private" API's that app developers aren't allowed to use which makes development more complicated than it has to be.

Finally, iPad's have way more screen size than iPhones. Little things that you might get away with on a 5 inch screen suddenly look really bad when blow up to 10 inches.

</comment></comment></comment></comment></comment></comment><comment><USER10> Jobs admired Sony, which introduced and won several new product categories. But when the founders left, esp Morita, this stopped, though of course they remain successful to this day - they just aren't creating new product categories.

Cook, as an operations guy, will keep things running. But can Apple lead new product categories under him? The Apple Watch seems to be showing he can... If so, it's something even more impressive than biggest cap etc. Something Sony didn't manage.

The iPad is dying not because of longer upgrade cycles, but for the same reason desktops are: it's less convenient than a phone (or watch).

<comment><USER11> Sorry are you trying to say that sending an email from a watch or a phone is more convenient than an iPad?

I personally think its the novelty factor that wore off. I bought on of the first net books when they came out, but realized after a while, that a full sized keyboard outweighed the size benefit.

</comment></comment><comment><USER12> A really interesting number is the 4% QoQ increase in Greater China revenue: a very big Chinese New Year.

</comment><comment><USER13> Some are arguing that the death of the iPad means that Apple is now basically a one-product company which could be an achilles heel no matter how many phones are sold.

<comment><USER14> Fun fact: Macbook revenue is now higher than iPad revenue.

So much for the early hype of tablets killing the PC.

<comment><USER9> Great. So Apple completely restructured their OS for a market segment (tablets) that is now below the original market segment (laptops).

<comment><USER15> They did? I think they restructured their OS for (a) Mobile, and (b) Mobile <\---> Computer integration. Both of which should pay off pretty well.</comment></comment></comment></comment>


Object Detection with Open Images using Tensorflow - <AUTHOR> https://blog.algorithmia.com/deep-dive-into-object-detection-with-open-images-using-tensorflow/ <comment><USER2> One thing that really puts me off Tensorflow is the large amount of work you have to do just to get your data in.

I recently trained a detector using Nvidia's detectnet and the DIGITS environment really makes it easy from dataset/database creation to model generation and training. The web interface handles all the padding and resizing for you when you import your images, and detectnet does online augmentation during training. It takes data in KITTI format which is just image + textfile with labels. No wrangling in Python needed.

The documentation is pretty terrible though, you have to pore over github issues to fix and modify things, but it does work.

<comment><USER3> I would be lying if I didn't agree with you. The valuable part is that Tensorflow's extendability and functionality are best in class. Making an object detector in scikit-learn is incredibly difficult, same with torch. Keras definitely can improve the experience but keras is also quite fragile. When in doubt, use the best tool for the job.

<comment><USER2> For what I was using it for - locating fruit on a plant - detectnet works pretty well (it runs at 7fps on a TX2 at 1280x960). It's a modified GoogLeNet with some custom layer on the end to do the bounding boxes. DIGITS itself is just a management console.

That said, you can train Tensorflow models using DIGITS, so I assume that DIGITS handles the data IO for you:

[https://github.com/NVIDIA/DIGITS/blob/master/docs/GettingSta...](https://github.com/NVIDIA/DIGITS/blob/master/docs/GettingStartedTensorflow.md)

It looks like you just define a wrapper around your model so that DIGITS knows how to run it and evaluate the loss, but otherwise your model could be anything.

</comment></comment></comment><comment><USER3> Author here, if you have any questions/comments I'll check back in periodically and answer them here!

<comment><USER4> 1\. Assuming someone is looking for only one or a handful of objects, why would they train their own dataset on open image instead of using the inception/object_detection built into TF? Seems like this use case is for systems that are looking to eval/classify a lot of different object classes.

2\. Why would someone run this on Algorithmia instead of their own hosted NC/P2/P3 instance?

3\. Have you tried open image with any other DNNs like Shang's implementation of FastMaskRCNN?

<comment><USER3> 1) The biggest reason is label diversity. COCO is a great dataset, but at 90 labels you're going to be missing some potential. The problem with commercial machine learning development is access to data, and with Open Images and it's 545 classification labels we get that diversity.

2) Scaling is hard, Cross-language Interoperability is hard, And bringing your product to market is hard. Algorithmia solves all of those problems with grace and has a development experience that is second-to-none. Don't take my word for it, compare it against tensorflow-serving other competitor technologies.

3) I haven't yet but I could certainly see an improvement in performance, we did notice a dramatic difference between our SSD and faster-rcnn model as was expected. This was only an intro, but if you create a model that performs better than ours, we'd love to host it on Algorithmia.

<comment><USER5> A small elaboration. OpenImages v2 has 545 classes for object detection, and 5000 classes for image classification.

<comment><USER3> Thanks, it's worth mentioning that we're entirely focused on the dataset for object detection here, but it has a massive classification dataset as well.

</comment></comment></comment></comment></comment><comment><USER6> I mean, this is neat but as someone who actually tried to build a computer vision product, can I just say Open Images data aren't quite enough? Also, computer vision isn't quite at "human level" yet. For your own project, building a model that has 90% accuracy on the test set is awesome but for an actual product to be released into the wild, it could have serious problems (not to mention adversarial examples).

</comment><comment><USER7> A minor nit but the function to dedup the image ids and the corresponding comments seem to be off from a data structure/algorithmic POV.

"Looking at our deduplication function, it's functional and performant, but not very descriptive. Essentially it checks a running set called seen, which is checked for originality as the deduplication script progresses. As python Dicts are essentially a hash map, the in check compares element hashes instead of each individual component of the dictionary object. This massively speeding up the deduplication process."

Uhm..I don't think so.

It is just extra work to check if the objects are already in the set vs just stuffing them all in and let the set handle uniqueness.

Am I missing something?

[https://gist.github.com/pstoll/ae73582763540051d321a4eb15304...](https://gist.github.com/pstoll/ae73582763540051d321a4eb15304226)

Again, a minor thing. But seeing something like that makes my 'what else do I need to review' detectors go up.

</comment><comment><USER8> live demo: [https://algorithmia.com/algorithms/zeryx/openimagesDemo](https://algorithmia.com/algorithms/zeryx/openimagesDemo)</comment>


High-speed academic networks and the future of the Internet - <AUTHOR> http://arstechnica.com/articles/culture/future-internet.ars

<comment><USER2> Telecom engineering is cool again. Wait, it always was in my mind, since I am majoring in the field.</comment>


Building a visual language for the 99% - <AUTHOR> http://occupydesign.org/

<comment><USER2> Otherwise known as propaganda.</comment>


Obscure Facebook URL - <AUTHOR> http://spoiledtechie.com/post/2013/08/29/So-there-I-was-Searching-for-an-obscure-Email-Address.aspx <comment><USER2> _> [https://www.wwww.wwww.wwww.wwww.wwww.0.facebook.com/rdnation](https://www.wwww.wwww.wwww.wwww.wwww.0.facebook.com/rdnation) _

Looks like anything.0.facebook.com is an alias for z.c10r.facebook.com.

 _So..._

      $ host hackernews.0.facebook.com
      hackernews.0.facebook.com is an alias for z.c10r.facebook.com.

      $ host www.xyz.hackernews.0.facebook.com
      www.xyz.hackernews.0.facebook.com is an alias for z.c10r.facebook.com.

It is called a _Wildcard DNS record_ [1], which allows you to have ~.example.com go to a single IP address and have the server handle it. This is really useful for web hosting, etc, and 37signals uses it for hosting basecamp [2], so each customer gets unique name at ~.basecamp.com.

[1] [http://en.wikipedia.org/wiki/Wildcard_DNS_record](http://en.wikipedia.org/wiki/Wildcard_DNS_record)

[2] [http://37signals.com/svn/posts/1512-how-to-do-basecamp- style...](http://37signals.com/svn/posts/1512-how-to-do-basecamp-style- subdomains-in-rails)

<comment><USER3> I couldn't help but wonder if c10r was an abbreviation (is there a name for this form of shortening?):

      % grep '^c..........r$' /usr/share/dict/words
      cabinetmaker
      calligrapher
      carpetbagger
      cartographer
      cheeseburger
      chiropractor
      collaborator
      commissioner
      communicator
      confectioner
      conquistador
      counteroffer
      countertenor

<comment><USER4> Yep, numeronyms.

[http://en.wikipedia.org/wiki/Numeronym](http://en.wikipedia.org/wiki/Numeronym)</comment></comment></comment>


Dive into the details of iOS 11: Is Apple still detail-oriented? - <AUTHOR> https://hackernoon.com/dive-into-the-details-of-ios-11-is-apple-still-detail-oriented-fe70af065a7d <comment><USER2> Non-closable pop-up window.</comment>


Haskell in Production: The good, the bad, and the ugly - <AUTHOR> http://mwotton.github.com/hs_gbu/ <comment><USER2> I don't think the library situation is nearly as bad as some people--not necessarily the author of this presentation--make out.

For one, Haskell actually has a pretty good and growing collection of libraries, probably disproportionate to the language's popularity. Web development, in particular, is well represented: there are several competing web frameworks; Yesod even has commercial backing now. Haskell even has some libraries that are not well reproduced in other languages like QuickCheck and Parsec. I've also been looking at sbv lately, which seems rather more convenient than other languages' alternatives.

Additionally, libraries aren't the only thing that matters. In fact, most libraries are pretty trivial. I remember seeing a presentation by Brian O'Sullivan online about his experiences with using Haskell at a startup. One point that really stood out to me was about libraries: sure, some libraries (like JSON parsing, I believe) were missing; however, it only took him something like a couple of days to write it from scratch. Those days are easily overshadowed by Haskell's core advantages. I would much rather spend a couple of days writing a new library than trying to track down a bug Haskell's type system would have caught. The beauty of this system is also that each library only needs to be written once and can then be reused, making the world better for everyone.

Now, there are some other issues with Haskell. Cabal really is a big one. I just spent quite a while fighting cabal, and I'm not even sure how I won in the end :P. Happily, I believe people are working on addressing the cabal issue.

I'm sure there are other annoyances besides. But no language is entirely free of annoyances. Considering everything, I really do think Haskell is a good choice for a very wide range of programming problems, especially in a startup setting.

<comment><USER3> I find the linked slideset uninteresting, as it misses the speakers words - its just a collection of positive and negative words. Still, I want to reply to your comment, even if my reply is bit harsh, but Haskell always makes me a bit bitter:

First of all, I played with some web frameworks in Haskell and didn't like them at all: the yesod community had a very dismissive tone towards people that didn't want to use what they perceived as "standard" and Snap is well organized, but sometimes weirdly implemented around the corners (WAT? The templating library also serves static files?). I would love to use any of them, but they are still not fit to build ecosystems like Django, Rails or Spring.

Its nice that you picked the JSON library (by Brian?) as an example for a lib that can be written in "a few day". `aeson` is a great library. Its just not something that someone without detailed Haskell knowledge can write in a few days. It requires good knowledge of Haskell, especially things like the GHC.Generics library and Template Haskell (Hint: GHC.Generics is not very well documented for practical uses as well, the documentation spares you of the hard cases).

I found that if you go away from those 'core' libraries, quality drops sharply. Giving just one example may be unfair, but I do it anyways: the readline bindings (haskeline) didn't build on OS X for 2 major releases straight. Also 0.1 and 0.2 seem to be very common version numbers on hackage and most documentation boils down to type descriptions. For loves sake, I couldn't find a good and proper tutorial working with bidirectional streams (think websockets) and asking a GHC committer ended in "well, we're still not sure what the best abstraction for this is, theres multiple competing" and someone on the Haskell User Group Berlin said "well, its not such an easy problem, but it will be solved in a year or so". In Ruby, thats implemented in an hour (safe and sound using libraries, with proper abstractions), today. Yes, I honestly think that the library situation is bad - its not the lack of libraries, its the number of half-hearted libraries vs. the real good ones.

Also: Pro-active teaching, like producing screencasts and tutorials is sadly not very common in the Haskell community as well (weirdly, this is spotty: haskell-cafe, Real World Haskell and Learn you a Haskell are shining examples of how things should be, also in other communities).

I am surprised by how much the Haskell community always says "type system" first, but seems to put all other practical considerations on the backseat. Also, it is common to just dismiss concerns without addressing them.

That said, I still love Haskell and enjoy developing in it when things are working smoothly, I just wished that the community were more receptive and less dismissive to actual problems of people that are not as deep inside the language as people spending every evening on it.

<comment><USER4> Before my rant: I think the Haskell community is incredibly nice. It is the most helpful and brilliant group of people I have interacted with in my life.

Rant:

Yes, I have spent a while getting up to speed with Haskell. I think it has definitely made me a better programmer to learn, but I really don't like how quickly everything seems to go in the deep end.

The need for the 'right' abstraction and 'good enough' stuff like Cabal really irritates me. Cabal is especially hurtful to the community growing. I think there needs to be a much bigger investment in Nix, that is an absolutely amazing project that barely gets the attention it deserves.

Another thing that really makes me not want to invest time in Haskell is how quickly code starts to depend on language addons. I think that idea can be done well, like in Racket, but for Haskell it really seems like a scary way of bandaging the standard.

<comment><USER5> What do you mean by bandaging the standard? And why are extensions scary?

In general none of the extensions change the behaviour of valid "standard haskell" (beyond adding a small handfull of new keywords, rendering those words illegal as variable names). So calling it "bandaging the standard" seems a bit harsh/odd.

I think extensions are a nice way of keeping the language moving forward without being slowed down by the standardisation process. The standard can then catch up in its own time.

<comment><USER3> Because there is no better way of saying "this is not finished yet and might be removed at any time".

</comment></comment></comment></comment></comment><comment><USER6> I don't even know Ruby, but it's clear that the idea that Ruby is an "amazingly primitive" language that people are using instead of Haskell because it has existing libraries and services or because "startups are not technical" is drastically wrong and almost insulting. To the contrary, Ruby, probably more than any other language, has a large community that's highly enthusiastic about its programming style and culture, which is the reason most of those libraries and ecosystems were created in the first place. I know this is just a few bullet points, but vaguely mentioning a few (good) reasons to evangelize Haskell (plus a motorcycle) along with three seemingly random relatively small issues as criticisms of Ruby (plus a horse and wagon) distorts reality almost to the point of unrecognizability.

<comment><USER7> Compared to GHC, MRI really _is_ primitive. Parts of this are intentional: the object model is intentionally simple, and one of the design goals was to keep unixy goodness close to the surface, so the IO model, forking and so on are quite shallow shim layers over the system calls.

Other parts, like the threading, the GC, and the parser (oh god, the parser) are suffering from baggage that's never had GHC-levels of academic effort thrown at it.

        To the contrary, Ruby, probably more than any other language, has a large community
        that's highly enthusiastic about its programming style and culture, which is the reason
        most of those libraries and ecosystems were created in the first place. I know this is just
        a few bullet points, but vaguely mentioning a few (good) reasons to evangelize Haskell
        (plus a motorcycle) along with three seemingly random relatively small issues as
        criticisms of Ruby (plus a horse and wagon) distorts reality almost to the point of
        unrecognizability

The presentation is making the point that MRI _itself_ is primitive, and addresses the plus points of the community in the very next slide. For people who care about the implementation underlying their code as much as they care about their own code (or more), MRI's shortcomings are a visible downside.

</comment></comment><comment><USER8> Although I'm mainly a C++ developer, I'm a big fan of functional programming languages.

Haskell is more difficult, it requires to really grasp some computer science principles whereas you can start hacking php/python/ruby right away. It requires to _actually think about what you're going_ to do instead of integrating a couple of libraries: that's a double edged sword.

You need to understand that the added value of Haskell for most start ups is near zero. It will more difficult to hire, the final result will not be better and in the end code quality matters less than business relevance.

If your technical founder is a Haskell guru and knows a couple of engineers, then sure, why not, it may provide some competitive advantage, otherwise just forget about it.

<comment><USER9> _You need to understand that the added value of Haskell for most start ups is near zero._

I used to have that opinion as well, but I am slowly retracting it. Very strong typing and great abstraction does make development easier. E.g., I have been writing parsers lately for an application-specific macro language. Writing such parsers using a good Haskell parser combinator library such as parsec is many times more productive than parser generators for most imperative languages.

Another advantage is that strong languages allow you to refactor code easily. If you change some types, the compiler will find type mismatches, allowing you to fix code rapidly. I can imagine that startups often refactor and substantially modify their codebase.

In the end you do not only want to develop an application quickly, but also correctly. If a strong language can be used to eliminate most errors and improve productivity, I see it as an asset to a startup.

<comment><USER8> You have tools to help you find mismatches in Python. I agree that maintaining a large code base in Python (or Ruby) is harder, but it's possible and is mainly a question of discipline and process.

 _If a strong language can be used to eliminate most errors and improve productivity, I see it as an asset to a startup._

Most startups projects I've seen are technically trivial.

<comment><USER10> > Most startups projects I've seen are technically trivial.

may be this is due to the fact that technically non-trivial problems aren't easily solved by startups, who might tend to choose a technology thats easy to use (such as php/ruby), but makes it difficult to solve the technically non- trivial problems with the same degree of ease?

I m just guessing here having no real insight.

</comment></comment></comment></comment><comment><AUTHOR> Ask HN: Anyone using Haskell in production? <http://news.ycombinator.com/item?id=1909093>

</comment><comment><USER11> ...I know that HN people are mostly *NIX oriented or dislike Microsoft technologies ...but how about F#? ...wouldn't it provide most of the advantages of a ML family language but coupled with the "smoothness" of VS tooling and .Net integration that could take some of the deployment pains away and provide the "accelerated liftoff" needed by startups?

(It's a question, not suggestion... I must admit I've never had the balls to use ML of Lisp like languages in production so far...)

<comment><USER12> well, you got it in the first paragraph - because Windows isnt Unix, and people dont use it for production. F# is in theory nice, but devops'ing windows, I just dunno man.

<comment><USER11> I've heard there's also good F# support via Mono now (but then again, I dunno about devops'ing with Mono... I wish someone had the balls try this and post about the experience...)

<comment><USER13> I've been deploying F# into production for a couple years, on to both Windows and Linux. They're rather simple daemons that talk to databases, message queues and filesystems, and do telecom logic (routing/billing).

Overall, Mono has been incredibly smooth. I prefer to compile from source as RedHat doesn't come with packages for mono. That takes time, but isn't a big deal. F# support seems lacking when it comes to some of the tooling (compiling, interactive).

mono-service, the service daemon to act like a Windows Service host (allowing same code as on Windows, and ~5 lines to a minimal daemon) sometimes has acted weird, but it's been due to how it handles it's runfiles and lockfiles, and once you know that it's easy enough to make sure they're ok. (As in, if one user ran it, the perms are wrong so another user can't even check it, and the error messages aren't there/clear.)

F# performance is on par for .NET. If a certain high-level feature is not generating great code, there's always the option to drop down or approach another way. F#'s much more flexible than C# when it comes to performance.

F#'s why I stay on the MS stack. .NET is pretty compelling with it's base library and great tool/developer support. But after seeing powerful languages, I just get so annoyed with the verbosity of things like C#.

<comment><USER14> Verbosity in C# practically disappeared with 3.0, released with .Net 3.5.

There are a couple of things left that annoy me, but mostly it's gone.

<comment><USER13> It got _better_, way better, much nicer than Java. It's not even remotely gone. Type inference is crap in C#, and they even admitted in some cases, it was due to compiler design problems, not language design[1].

Even local vars can't be type inferred if they're functions, because of C#'s confusing decision to use the same syntax for lambdas and quoted code.

The ASP.NET MVC team resorted to using reflection on anonymous types, because there was no lightweight way to pass in a set of options at runtime. With a more expressive syntax, that'd be needless.

C# has statements that aren't expressions, which really bulks up code and adds flow for no reason. In F#, even "if" and "try" blocks are expressions which again keeps slimming things down, and more importantly, keeps the code simpler.

In one direct "line-by-line" translation (C#->F#), F# reduced the number type annotations I needed by 95% (1/20th).

No pattern matching (and thus no active patterns!), little type inference, no syntax for tuples, no lightweight function syntax, no code nesting, no workflows, (and a weird hardcoded one just for async), no top-level functions, no custom operators, and C# is flat-out downright clunky when compared to F#.

It may be one of those "you don't know what you'll miss until it's gone" kind of deals. I've used C# now and then, even last month on an entire project, and it just feels tiring.

1: [http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-n...](http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why- no-var-on-fields.aspx)

<comment><USER15> +1. Your story sounds a bit like mine a that guy's - [http://lukeplant.me.uk/blog/posts/why-learning-haskell- pytho...](http://lukeplant.me.uk/blog/posts/why-learning-haskell-python-makes- you-a-worse-programmer/) :) It's a bit old, so some things don't apply anymore, but still.

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> I've no doubt this presentation makes some interesting points, but I'm as inclined to finish reading it after noticing it's destroying my browser history as I would continue evaluating software after noticing it's randomly corrupting my home directory.

Please leave history alone or at least use window.history.replaceState().

<comment><USER7> Also a bloody pain to read on a mobile device.

<comment><USER17> It's not exactly easy to read on a desktop either.

</comment></comment></comment><comment><USER18> "strong _static_ types save time"

I would find the presentation without controversial points at all were it not for this one sentence :)

Edit: aaargh, I treated mention of Ruby primitivism as a joke and forgot about it; if taken seriously it can be controversial as well.

<comment><USER19> every single NoneType error I have gotten using in the python I'm paid to write would go away with a static type system.

Every single function I've changed the signature of and then failed to change one caller would go away with a static type system.

I cannot count the number of times I've had to stop and write down the types of things I wanted to reason about, an d then keep all that in my head, to figure out what was going on in a large code base. Guess what? Most of the types were static. If I had Haskell's good type inference, I wouldn't have had to do any of this time-wasting endeavor.

The statement isn't controversial. Correct code type-checks. When there are type errors in your code, in a dynamic language, they would be bugs found at runtime.

[edit for formatting]

<comment><USER20> Dynamically typed languages are used everyday to write robust software (erlang, lisp, etc...).

You're making a common mistake, which is to reason about static typing advantages _everything else being equal_. Sure, if static typing had no drawbacks, it would be insane for any language not to be statically typed, for some of the reasons you're giving (and others). But everything is not equal. Static typing is a tradeoff, and lots of its advantages are often caused by something else (or in combination with something else). Don't get me wrong, Haskell is an impressive feat (just starting learning it), but in haskell, typing is associated to advanced type inference, purity, etc...

In my experience being paid to to write python, a lots of NoneType, attribute errors, etc... often have a deeper underlying reason linked to bad architecture, and bad programming practices. I am not convinced typing would make improving those projects easier (certainly, a primitive typing system ala c/c++/java does not in my experience).

<comment><USER21> Type error: "everyday" is an adjective, adverb expected in this context ;)

The examples you cite would be detected by a type checker. The attribute errors wouldn't even need a complicated one. (I've never had an attribute error in C.) It's fine to complain that these things are due to bad architecture, in whatever way that might be, but if there were a type checker involved then the code wouldn't even build if there were a type problem. It's fine to rail against poor design, or systems that are hard to use for no good reason, but in the mean time the code usually has to actually work.

(And if there were no type problems, it would run fine without one, bad architecture or no.)

</comment></comment></comment></comment><comment><USER22> Ah, powerpoint presentations where the truth is somewhere between the bullet points. I would have preferred a blog post which gives the author enough breathing space to justify his claims.

Haskell's single biggest problem is that it looks unfamiliar to programmers who are trained in traditional imperative languages. Due to its minimal syntax, its error messages can be confusing to a learner. New languages like Scala and Clojure are packaging many of Haskell's concepts in a more familiar syntax. They are gaining popularity since they actually solve hard problems like concurrency.

In my opinion, startups prefer Ruby because they prefer to start solving the problem right away without worrying too much about its correctness. A classic case of "Worse is better" works for most web applications. Whereas, Haskell requires some thinking into how to best model the solution before you start implementing it. This often leads to more 'correct' code.

<comment><USER23> I think that one of its biggest problems has been the vast majority of the "Teach Yourself Haskell" books/articles.

When I first had a go at learning it, I ran into two common problems with them. Firstly they usually did a great job of showing you how to write a quicksort or a Fibonacci sequence but then struggled to explain how it applied to most every day challenges (things like i/o - and yes, I sort of understand the complexity around that in Haskell, but as a developer, it's one of the key things I'm likely to want to do).

The other problem was that examples were typically full of what I would consider appallingly named/abbreviated functions,parameters etc

"fib' (f, g) p"

for example.

When you're already struggling to understand langauge concepts, having your code full of "f,g, and p" and trying to remember what they mean really doesn't help.

I think it's improving (Learn You a Haskell looks pretty good, but I've not had a serious attempt to re-learn since that appeared), but it's always been a bit of stumbling block for me in the past.

<comment><USER24> > The other problem was that examples were typically full of what I would > consider appallingly named/abbreviated functions,parameters etc

As adimitrov points out, this is in many ways a carry over from mathematics. However, this isn't the only factor.

For the parameters:

Expressions and functions in general are usually much shorter in Haskell than in other languages, so one can see _how_ the variable is being used, e.g. the conventional definition of map is:

      map f [] = []
      map f (x:xs) = f x : map f xs

One can tell that f is a function and that it's doing something to the first element of second argument, and then recurring on the rest of that list. That is much much nice, than (at worst)

      map function list = if null list then [] else ((function (head list)):map function (tail list))

Secondly, the types tell a lot about a function and it's parameters, for the above

      map :: (a -> b) -> [a] -> [b]

one can easily see that the first argument is a function and the second is a list, and the specific types mean that there is a single sensible way to combine them: apply the function to every element of the list.

(Lastly, there are conventions, which take a little time to learn, but they help. E.g. f, g, h for parameters which are functions, (x:xs), (y:ys) for head/tails of lists.)

However, naming the functions poorly is a problem. (But type do help with this too, especially with Hoogle[1].)

[1]: <http://haskell.org/hoogle>

<comment><USER23> The x:xs one is fine as long as it's properly explained in the tutorial - e.g. it's a list of items, with x being the first item and xs being all other items in the list.

The

map :: (a -> b) -> [a] -> [b]

may well be abundantly clear once you understand Haskell's types, but is rather less so when you're first learning. In that particular case, I'm not entirely sure I could come up with a clearer set of names, but there's plenty of times when I was first learning that I really struggled with getting to grips with a concept simply because the naming left me wondering why I was passing an A into a Q to get a list of Zs (or whatever it was).

<comment><USER25> I'm not sure how specific to Haskell this actually is, though. Think of templates in C++ (esp. template functions) or generics in Java. You use T or whatever as a placeholder for actual types. Any time you need more than one type, you're forced to make a similar decision about how to describe a type about which you know very little.

It's is a heck of a lot more concise than either of those, though. Might this be the actual stumbling block? You're _saying_ a lot about map -- in a very precise way, mind you -- without _writing_ a lot.

<comment><USER23> C++ templates and generics are relatively advanced features though. I wouldn't be expecting to teach them in lesson 2 of the langauge.

And what you would call a parameter in a production app is not necessarily the same you'd call it in a tutorial.

</comment></comment></comment></comment></comment></comment><comment><USER26> Does anyone really think that a slide presentation is a better way of saying what the author wanted to say than an essay?

And if so, do they also think that Norvig's Gettysburg Powerpoint Presentation is better than Lincoln's Gettysburg Address?

</comment><comment><USER27> What does CoW mean? As in "GC breaks CoW & caching". There are quite a few acronyms and supposedly even some animal with these three letters.

<comment><USER28> Copy-on-write.

</comment></comment><comment><USER29> Is this a slideshow? I can't do anything here in FF 16.0.1.

<comment><USER30> Ditto. I just turned off page styles and read the text. There's not much of it.

</comment></comment><comment><USER31> What about virthualenv (virtualenv for Haskell)? Does that help alleviate some of the cabal issues?

<comment><USER32> It worked well for me, and there's cabal-dev too. BTW, I think virthualenv is now called hsenv.

</comment></comment><comment><USER33> I'll consider Haskell for serious programming when (and if) it gets a decent record system.

[http://bloggablea.wordpress.com/2007/04/24/haskell- records-c...](http://bloggablea.wordpress.com/2007/04/24/haskell-records- considered-grungy/)

<comment><USER34> That blog post seems fairly outdated. There are several lenses libraries that provide decent record support:

[http://stackoverflow.com/questions/5767129/lenses- fclabels-d...](http://stackoverflow.com/questions/5767129/lenses-fclabels- data-accessor-which-library-for-structure-access-and-mutatio)

Personally, I'd much rather have a better baked-in record system, but that's unlikely to change substantially now.

<comment><USER35> The state of the art is the amazing `lens` package <https://github.com/ekmett/lens/wiki/Overview> . See this example, <https://github.com/ekmett/lens/blob/master/examples/Pong.hs>

<comment><USER33> Looks great! I hope it gets more broadly adopted. Thanks for sharing.

</comment></comment></comment></comment><comment><USER12> "startups arent technical"

I guess YOUR startup isnt technical... But there are in fact technical startups out there. It's just that they make more money than yours, do better and are generally cooler.

<comment><USER28> My startup involved custom hardware and realtime messaging. I still would have been better off in the early stages writing it in Ruby.

</comment></comment><comment><USER36> > Ruby is amazingly primitive

What? In what sense in Ruby primitive?

<comment><USER37> "primitive" is an awkwardly chosen word with negative connotations... I suppose it is in the sense that it doesn't do type inference (or reasoning about types at all, for that matter). Like a Lisp it simply executes what you write without any validation beyond syntax checking.

The idea is that Haskell's type-based, lazy approach allows for a more high- level approach of specifying what you want instead of how you want it executed. I'm not sure it always succeeds in that, but that's another matter. It's an interesting language nevertheless, with elegant code, but if I need to build something quickly I fall back to Python (which is "primitive" in the same sense as Ruby).

<comment><USER38> > Like a Lisp it simply executes what you write without any validation beyond > syntax checking

But then in Common Lisp when something goes wrong you drop into the debugger and can look at your code's state. In python/ruby my program just goes poof! and I get a backtrace. Then I'll either have to add statements around the suspected cause of the bug to inspect the environment or restart with a debugger and retrigger the bug.

The Common Lisp Way(tm) is also available in Smalltalk; I think those systems give you the tools to deal with their dynamic nature, while python and ruby (and others as well) do not.

And then languages with more static type systems can give you the tools to deal with their static nature. In Haskell that would be powerful type inference and expressive type system.

<comment><USER37> Well, dropping to the interactive prompt is a statement or two in Python. You could do that when something goes wrong (for example, in the inner, or outer exception handler of your application).

There's also tools for Python where you can browse/modify state of a program remotely through a debugger, for example winpdb, others included in IDEs.

Overall, dynamic debugging support is quite good, if you are willing to search around a bit. But probably not as good as CL or SmallTalk, if they're especially engineered for these kind of things. I don't know enough about them to comment on that.

</comment></comment></comment></comment><comment><USER39> I think it is very positive. I read it as "Things are being done, please be patient. B.t.w. what's done is insanely great".

</comment><comment><USER40>
        * $LANGUAGE is amazingly primitive
        * GC breaks CoW & caching
        * dynamic -> lexical scoping between $OLD_VERSION & $NEW_VERSION
        * concurrent behaviour requires event-driven style

Exactly the same could have been written about Lisp in the late 80s

</comment><comment><USER41> eh? haskell program can be really slow, especially when it is written by non- experts who don't understand lazy evaluation well.

<comment><USER42> A _< Language>_ program can be really slow, especially when it's written by non-experts who don't understand _< CorePrinciple>_ well.

</comment></comment><comment><USER43> This is a terrible set of slides. The only new thing I gathered from it is "cabal sucks". Then the presentation came to a sudden end which left me thinking "what, that's it?" How does such a low quality link get so many upvotes? _takes notes for future marketing endeavours_

<comment><USER28> It wasn't really intended to make much sense by itself. I find if I make slides that stand alone, the audience reads the slides and ignores me. I put the slides up as a courtesy to the people in the audience.

There was less than zero marketing involved - I gave this talk months ago and only just noticed this thread.

<comment><USER43> Apologies if I sounded like I was criticising what you do - I'm sure that these made a lot more sense in the context of a presentation. I was questioning why the person who posted this link did so and why it has been upvoted to such an extent.

<comment><USER28> not caremad, just clarifying. I'm as baffled as you are.</comment></comment></comment></comment>


Upload multiple files to AWS S3 at once, and get their URLs with one command - <AUTHOR> https://github.com/ammar1y/s3upload <comment><USER2> I don't see any code or examples. What was the purpose of sharing this?

<comment><AUTHOR> What do you mean? The link takes you to the README file which contains usage example and instructions. And you can find the source code in "s3upload" file.</comment></comment>


Paint Servers: SVG and Canvas - <AUTHOR> http://ajaxian.com/archives/paint-servers-svg-and-canvas

<comment><USER2> Can someone decode what the hell this article is about? A paint server is a.... ?

<comment><USER3> I assume "server" must be some internal developer terminology, because the article seems to be entirely about _client_ -side rendering -- specifically about using SVG or JavaScript+Canvas to tweak the rendering of HTML/CSS, in custom experimental builds of Firefox.</comment></comment>


Flipper Zero: Under Development Multi-Tool Device for Pen-Testers - <AUTHOR> https://flipperzero.one/ <comment><USER2> Wow, you found it. We did not plan to publish this project in a big internets until prototype will be ready. At this moment you can join the developers forum to participate.</comment>


IOS 4.3 battery life - <AUTHOR> http://alexknight.net/blog/2011/3/20/ios-43-battery-life.html

<comment><USER2> It's been going around Twitter you need to turn of the 'Ping' service in settings which prolongs battery life, don't ask me details, I don't have an iPhone, I'm just repeating what I read.</comment>


AnDevCon The First Android Conference Review - <AUTHOR> http://www.thebitsource.com/tech-conferences/andevcon-the-first-android-conference-review/ <comment><USER2> Motorola outsourced the entire thing to BZ MEdia to make it look like an Android Conference, but in fact it was another Motorola marketing stunt. Reason why Google did not sponsor the conference, lets don't forget that they also have a partnership with Samsung. Motorola this, Motorola that. Samsung was not even mentioned. A complete fiasco.</comment>


UltraSPARC T4 tech summary - <AUTHOR> http://www.realworldtech.com/forums/index.cfm?action=detail&id=122683&threadid=122683&roomid=2

<comment><USER2> I think Anandtech put it best. Paraphrasing: T4 is proof that Oracle has not yet abandoned SPARC and provides enough performance that those who are heavily invested in Solaris/SPARC won't feel obligated to look for an alternative. It probably won't convince anybody to switch to SPARC.

</comment><comment><USER3> Oracle has invented the Pentium 4!

edit: 8 cores per die and 8 threads per core is neat but the high clock rate and the relatively small caches are going to make it a tricky beast to program for.

<comment><USER4> I have some experience programming against the previous architecture (T3).

It depends on what you're doing. For some purposes it's great to have that many cores/thread, such as network servers or others systems that handle zillions of quasi-independent messages.

On the other hand, if your software only have a few active threads that do heavy computation once in a while, it's very tricky (even the packaged BLAS libraries only have so-so performance, even though they parallelize heavily and are supposedly optimized for their caches) and IMO you're better off with a traditional multicore processor.

</comment></comment><comment><USER5> Unfortunately due to Oracle's behavior, it is completely irrelevant.</comment>


Toward UI and UX Guidelines for Virtual, Augmented, and Mixed Realities - <AUTHOR> https://medium.com/usable-or-not/toward-user-interface-and-experience-guidelines-for-virtual-augmented-and-mixed-realities-939eec8394e4 <comment><AUTHOR> I found this while looking for a deeper discussion than "Apple Augmented Reality Human Interface Guidelines" [1].

[1] [https://developer.apple.com/ios/human-interface- guidelines/t...](https://developer.apple.com/ios/human-interface- guidelines/technologies/augmented-reality/)</comment>