Tesla Second Quarter 2018 Update - <AUTHOR> http://ir.tesla.com/static-files/7235e525-db16-470c-8dce-9ecac0ad7712 <comment><USER2> Tesla only sold 104 Roadstars in 2011. Now they are on track to sell 250,000 Model S, X, and 3 combined in 2018. The scale of Tesla's accomplishment is truly under appreciated. It becomes even more impressive when you realize that this is an electric car, sold by Tesla owned stores, supported by over a thousand Superchargers. Amazing !!

<comment><USER3> Toyota went from selling 19,000 Prius' in 2000 to 281,000 Prius in the same timescale. It becomes even more impressive when you realize that before the Prius, there was no market for green cars, hybrid, electric, or otherwise. Amazing!!!

[1] Even more impressive is that these are sales of a single model...

<comment><USER4> > It becomes even more impressive when you realize that before the Prius, > there was no market for green cars, hybrid, electric, or otherwise.

The first incarnation of the Honda Insight was before the Prius, and somewhat successful before the Prius came on the scene and took over.

<comment><USER3> Honda Insight was never offered for sale, lease only. I'm not including leases because Tesla does not lease their cars and lease stats are more than a simple Google search away. But if we were to include leases, Prius' stats would look even better.

<comment><USER4> > Honda Insight was never offered for sale, lease only.

No, 17,000 or so were sold, and it was the first mass produced hybrid sold in the US.

</comment></comment></comment></comment></comment><comment><USER5> Beyond the finances, Tesla says they're still on target for 6000 Model 3's a week by the end of the month.

Throw in the other Models and Tesla will be shipping 300,000-400,000 electric cars a year. That's quite an accomplishment.

<comment><USER6> I wish other car companies would create more compelling and somewhat affordable electric cars.

At least in the US, the only two cars I can think of (besides the Model 3, which is hard to come by) that move the needle at all are the Nissan Leaf and Chevy Bolt, both of which look... not great.

Why don't any other car companies offer a 'standard' mid size or compact sedan that's fully electric? Just take an existing decent car like a Toyota Corolla, Honda Civic, etc. and redesign it electric? I know it's a different drivetrain/architecture, but why not a standard looking body instead of some weird buggy space-age thing?

<comment><USER7> > but why not a standard looking body instead of some weird buggy space-age > thing?

I think they're still counting on the signaling. It's said that the Prius was bought by so many in large part _because_ it looked so goofy, in that it didn't look like anything else, so everybody knew it was a Prius, which by proxy meant that you were driving green.

Tesla shook that up, but styling still remains something withheld for the maximum dollars. There are very few stylish cars at cheaper price points because they know that despite whatever features are there, people shop with their eyes predominately.

If they happen to land on a design that's too fetching for the price point they're targeting, it seems likely that they'd uglify it somewhat and withhold the better design for a more expensive vehicle that they may or may not plan to make.

<comment><USER8> The Honda Insight looked even more goofy:

[https://en.wikipedia.org/wiki/Honda_Insight#Design](https://en.wikipedia.org/wiki/Honda_Insight#Design)

They were shown in 1997 and on the road in the US by 2001 or so.

The Prius seems to have been a much better car.

<comment><USER9> I drive a 2004 Prius and my friend recently bought a 2000 Insight.

The Insight is pretty much strictly a commuter car: it's laughably tiny, like a roadster without any power. But it's really fun, and gets outrageously good fuel economy despite how crude the hybrid system is relative to Toyota's.

The Prius on the other hand is an everyday vehicle that's spacious inside and small on the outside. Far better suited to be the only car someone owns.

</comment></comment></comment></comment></comment><comment><USER10> For the six months ending in June 2018 Tesla's operations burned $528 million of cash. It also spent $1.27 billion on CAPEX. At quarter's end, they have $2.2 billion of cash on hand. That's like 7 months of runway. What's keeping the boat plugged up is debt.

Good news is, there are no obvious bond market bogeymen on the horizon in the very near-term.

<comment><USER11> Cash flow was -$528M Jan-Jun, i. e. Q1 and Q2, yes.

But it was only -$128M in Q2. Tell us why you chose the longer time frame for your prediction, exactly?

Your math also has some basic problems, because $2.2 billion / ($1.27 billion / 6 months) != 7 months == 11 months.

More importantly: you're mixing some completely different levels of accounting: cash flow may or may not correspond to changes in capital structure such as CAPEX. When CAPEX involves actual cash being paid, it's also reflected in cash flow. In that case, you're counting the same expenses twice. etc..

<comment><AUTHOR> Your parent is not mixing different accounting concepts. Those are two lines taken directly from the statement of cash flows ("Net cash used in operating activities" and "Capital expenditures").

</comment></comment></comment><comment><USER12> Looks like the bankruptcy short thesis has been pretty much debunked, cash burn way below expected.

<comment><USER13> Except for the 3 billion dollars in short-term debt that they have no hope of repaying.

<comment><USER14> Cite, and I don't just mean the $3b existing, I mean the 'no hope of repaying' part. Cite, or delete.

</comment></comment></comment><comment><USER15> > Gigafactory 1 battery production reached an annualized run rate of roughly > 20 GWh

Kind of interesting...the typical laptop has a 50 Wh battery, and there are about 160 million laptop sales per year. A typical smartphone has a 5 Wh battery and there are about 1.5 billion smartphones sales per year. So that one factory makes just about enough batteries for all the laptops and smartphones.

<comment><USER16> And we would need 730 of such factories to provide all of 73 million annually produced cars with a 200kWh battery.

<comment><USER17> Fortunately, cars do not need 200kWh batteries. 75ish seems like the sweet spot.

</comment></comment></comment><comment><USER18> After hours trading jumped from $300.81 to ~$320. That could change again before morning, but the markets look set to smile on this update. :-)

</comment><comment><USER19> Is that graph of their market share true? Do they really have a ~50% market share? It sounds really high. At that sort of percentage can they really grow at the rate they need? I know they say things like

> We are drawing customers from many other segments, including non-premiums > sedans and hatchbacks.

Is that the source of growth at this point?

<comment><USER20> > Is that graph of their market share true? Do they really have a ~50% market > share? It sounds really high. At that sort of percentage can they really > grow at the rate they need?

Yes, when comparing to other compact luxury sedans such as the BMW 3-series and the M-B C-Class, yes, they are at 50% market share. The question becomes, are they just selling cars to people who would have bought a car in that class, or are they selling to people who normally would have been in a lower class. Anecdotally, they're growing the class, as there's a lot of interest in the Model 3 from people who otherwise would have bought a Camry, Accord, Malibu, or other mid-grade sedan.

<comment><USER21> The Model 3's shipping though are essentially luxury models though, correct? Not the cheap one that would compete with a Camry, Accord, Malibu, all of which can be had for around 20k.

<comment><USER22> Model 3 is supposed to be the cheap/basic version. Maybe a model 5 will be mid/luxury along with model S

</comment></comment></comment></comment><comment><USER23> > In July 2018, we delivered our 200,000th vehicle in the US, which means that > our US customers will have access to the full $7,500 federal tax credit > until the end of 2018

So basically they have until the end of the year to produce as many cars as possible and get their finances in good shape, otherwise they're in trouble.

<comment><USER24> It will drop to $3,750 in January and then $1,875 in July. [https://arstechnica.com/cars/2018/07/tesla- sold-200000-cars-...](https://arstechnica.com/cars/2018/07/tesla- sold-200000-cars-in-the-us-so-the-7500-tax-credit-is-going-away/)

<comment><USER23> Even that phaseout will probably result in a lot of cancellations from people who have been on the waiting list for several months already but who haven't taken delivery by the end of the year. Especially for the orders at the lower end of the price spectrum, which haven't even started shipping yet.

Loss aversion is real, and people aren't going to be happy about being asked to suddenly pay ~20% more for the exact same car. Since the base models haven't started shipping yet, it stands to reason that after the end of the year that will be mostly what's left on the waiting list. So if they lose a lot of those reservations, they're stuck with huge capital expenses and a potentially very significant decrease in orders.

<comment><USER20> > Loss aversion is real, and people aren't going to be happy about being asked > to suddenly pay ~20% more for the exact same car.

It's 10% more at most, and they are making it pretty clear now that the Short Range model will not be available before January 2019. Even then, many people can't even realize the entirety of a $7,500 tax credit. A single person needs $60k in income to generate $7,500 in taxes due after the standard deduction, and a married couple needs $80k to reach that point. Most people who are holding out for the $35k Tesla because that's all they can afford are also going to have a Tax due of less than the $7,500 credit.

<comment><USER3> 7500/35,000 = 21.4%

It's a 21% price increase, assuming the buyer would have been fully eligible for the credit.

Yeah, that's definitely going to change the math for a lot of prospective buyers. A basic Model 3 isn't worth $35,000 cash compared to other similarly priced EVs, especially not when those competitors will still qualify for the rebate.

<comment><USER20> >It's a 21% price increase, assuming the buyer would have been fully eligible for the credit.

True, but not until 2020. In H1 2019 there is still a credit of $3750, and in H2 2019, there's a credit of $1875, so it doesn't fall off a cliff.

</comment></comment></comment></comment></comment></comment><comment><USER25> Out of curiosity, how many of you bought and sold TSLA over the last few hours since the report?

</comment><comment><USER26> Reading the comments, feels like HN is schizophrenic which is actually not surprising (online mob mentality). The shorts and haters were out in full force before on HN, calling Tesla the next Enron, absolutely slamming Elon. Today, praise and congratulations.

</comment><comment> brian-armstrong Buying a car that's more than, say, $30,000 is such a laughably poor decision. Cars depreciate rapidly unlike real estate where you actually maintain some equity. If you're in your 20s and looking to pump your new RSU wealth into something, almost anything is a better choice than an expensive car.

<comment><USER27> Who are you to dictate what I should do with my hard-earned money? As long as you can comfortably afford it without any debt, spend the money on what you are enthusiastic on.

Next time you are buying groceries, laptops, or go to a restaurant, I am going to point out all your laughably poor decisions of not spending your money on the absolutely cheapest options.

<comment><USER28> That's a pretty ridiculous comparison because of the difference in scale. There are significant opportunity costs to putting 10s of thousands of dollars into something that will depreciate in value over time rather than increase. Especially when you're in your 20's. That amount of money invested could be worth a lot more in 30 years. Compound growth is your friend.

<comment><USER29> I find it unlikely that the average HN member does not understand that earning money is a better financial decision than spending it on highly-depreciable luxury items (because such insights are entirely obvious), which is why comments like "compound growth is your friend" rub me especially the wrong way.

If one can reasonably afford a luxury item, it is _perfectly fine_ to spend that money on that luxury item.</comment></comment></comment></comment>


Entrepreneurs can change the world - <AUTHOR> http://www.youtube.com/watch?v=T6MhAwQ64c0&feature=player_embedded

<comment><USER2> I remember first watching this and being scared. Scared of one day forgetting the last quote in this amazing video:

"Remember when you were a kid, when everything was within your reach, and then say to yourself quitely and with determination, it still is."

I'm 20 today and still think that. But my greatest fear is one day losing sight of that because of a "normal" work or life or family commitment.

Amazing video though, mate. Thanks for sharing.</comment>


Why Software Is Slow and Shitty - <AUTHOR> http://pketh.org/why-software-is-slow-and-shitty.html <comment><USER2> I think this article misses the point. Modern development practices don't automatically translate to shit software (except maybe Electron?). Furthermore a lot of software today is shit for reasons besides performance.

The main problem nowadays is that the incentives changed. Back in the day, software was sold at a fair price and needed to be good value otherwise people might go to a competitor. The software should be serving the user as much as possible. This was also possible because software publishers weren't overvalued and as long as they could bring a good amount of profit to pay nice paychecks to a handful of people everyone was happy.

Nowadays the majority of software out there is "freemium", it's either free and ad-supported or designed to extract as much money out of the user as possible, often using anticompetitive practices. There is no longer a desire to serve the user (in case of ad-supported products they are intentionally crippled), the quality bar is much lower (due to spyware and analytics they know exactly what the minimum bar for quality is and have no incentive to go beyond that) and the lack of competition or vendor lock-in prevents people from leaving. Unsustainable growth and overvaluation means they have to charge much more money for a product worse than what we used to have 20 years ago, and even then a lot of these companies aren't profitable.

<comment><AUTHOR> hey Nextgrid,

The point i was trying to make was more about modern development Organizations/structures leading to shit (not so much practices, although ya electron).

That said I totally agree with you about twisted incentives. A gross business model results in gross software no matter how skilled the dev/design team.

IMO the trends toward metrics-driven/freemium companies, is a consequence of top-down org models – predominantly where those at the top have no understanding of, or respect, for craft. Rigid structures typically only understand rigid metrics.</comment></comment>


Google to build its own office space - <AUTHOR> http://www.mercurynews.com/ci_18011875?nclick_check=1

<comment><USER2> The race is on now between Apple and Google! Who will be the first to break ground on their respective paragons of green corporate campuses? I am giddy with anticipation!</comment>


Why you should ban e-mail in the workplace? - <AUTHOR> https://blog.weekdone.com/improve-communication-in-the-workplace-banning-email/

<comment><USER2> The title should either read: Why should you ban e-mail in the workplace? or Why you should ban e-mail in the workplace.</comment>


On Teaching - <AUTHOR> http://avinashv.net/2008/11/on-teaching/

<comment><USER2> He missed the absolute most important aspect of teaching: communication skills. The great teachers I have had have all been able to explain their material clearly, and have been able to tell when students understood vs when they needed to redo an explanation. The worst teacher I have ever had was clearly a genius, had a great sense of communication, and certainly was passionate about teaching, but he simply could not properly communicate his ideas to the class.

<comment><AUTHOR> I quote myself from the article:

> While this seems to be a blueprint of what makes a perfect teacher, I prefer > to think of it more as what made my most impressive teachers such great > educators in every aspect.

This wasn't, though it seemed like it, a blueprint to the perfect teacher. I think that aspects like communication skills, confidence, and to some extent, appearance are given.

</comment></comment><comment><USER3> Excellent post, and excellent blog! I've added you to my RSS shortlist.

Out of curiosity: is there a system that you use to set up those citations? Or do you hand-code them each time?

<comment><AUTHOR> Sorry for not getting back to you sooner. I wish I could "watch" threads for comments.

I use a Wordpress plugin called WP-Footnotes (<http://wordpress.org/extend/plugins/wp-footnotes/>) that handles everything. It has a few issues, namely, I can't use Markdown syntax within the footnotes, so I have to hard-code links within them, but it's worth it to have everything automagically work.

I'm glad you found my writing worth subscribing to, thanks!</comment></comment>


Seoul: The World Capital of Plastic Surgery - <AUTHOR> http://www.newyorker.com/magazine/2015/03/23/about-face

<comment><USER2> I'm fascinated by Korean culture! I recommend Colin Marshall's podcast Notebook on Cities and Culture, which recently completed a Korean tour: [https://itunes.apple.com/us/podcast/notebook-on-cities- cultu...](https://itunes.apple.com/us/podcast/notebook-on-cities- culture/id266539442?mt=2)

Or check out his blog: [http://blog.colinmarshall.org](http://blog.colinmarshall.org)

</comment><comment><AUTHOR> The ads the article quotes make me sad.

\- _"This is the reason celebrities are confident even without their makeup"_

\- _"Everyone but you has done it"_

<comment><USER3> The before & after pictures plastered everywhere (that increase in frequency as you get close to Gangnam but are still very common) have the same effect for me. Input person who at least has some semblance of an individual physical appearance and output yet another who looks like all the others. When numbers are as high as possibly being 50%+ for women in their 20s, it becomes even scarier. I have numerous 20-something female Korean friends that make me doubt that statistic but I'm sure it's not far off.

<comment><USER4> I worked for a Korean company for mover 7 years and a few times a year found myself in Gangnam. I was out with a colleague and his sister, she said "oh, everyone (meaning female) has had a little work done." Given, as you suggest, the prominence of the plastic surgery business it isn't surprising.

</comment></comment></comment><comment><USER5> There may be an upside to this. It could mean that sexual selection will evolve them based on traits other than physical appearance.

<comment><USER6> How is that an upside?

<comment><USER5> It means the people who were born ugly, but otherwise perfectly fine, will have a fighting chance.

Imagine Stephen Hawking's eye-to-speech device like cosmetic augmentation.</comment></comment></comment>


Four more carmakers join diesel emissions row - <AUTHOR> http://www.theguardian.com/environment/2015/oct/09/mercedes-honda-mazda-mitsubishi-diesel-emissions-row <comment><USER2> In the corporate world, the powerful profit motive often seduces weak-minded managers into making decisions that ignore legal and ethical concerns. Strict regulation and law enforcement is the only corrective we have.</comment>


What is "immediate connection" good for? - <AUTHOR> http://lacezero.wordpress.com/2014/09/04/what-is-immediate-connection-good-for/ <comment><USER2> There are two programming language environments, or better to say operating systems, that are designed for this kind of immediate coding: Forth and Smalltalk. Forth plays its strength when controlling hardware. Your code is immediate executed, and you see the results, e.g. a robot arm moving instantly. Times of Forth coders running circles around teams using traditional programming languages are nearly over.

Smalltalk on the other hand still has to find its killer application. Smalltalk was 35 years to early, and since then every few month a new language is hyped, each one one step closer to Smalltalk. Computing history turns in cycles and we soon will have a situation comparable to VM/370, where every application is running its own operating system. I hope that there will be a Smalltalk killer application exploiting the immediate changes in coding to power users, similar as Forth controllers do, but on GUI level.

<comment><USER3> Swift playgrounds.

<comment><USER2> I never played with Swift, as its an Apple gimmick. I only read the wikipedia article right now, claiming its a compiled language. Are you able to inspect variables in a running systems, are you able to change the running code without restarting the system?

A few other examples come into mind, where immediate coding is of benefit.

First we have all those educational toy languages in the tradition of Logo, that are designed for children to learn the first steps in coding, that benefit for immediate execution.

Next we have the tools, that are often not considered as real programming environments, e.g. table calculation in Visi calc tration, and tools like matlab, mapple, maxima, axiom, or R.

</comment></comment></comment><comment><USER4> One example is algorithms heavy code. There are already numerous resources(e.g [1]) that visualize algorithms and data structures. If those kinds of animations could be generated on the fly, it would be much easier to write that kind of code.

Being able to visualize code blocks (kind of like Light Table) and move them around between files, maybe even modify inheritance structures graphically could be useful too.

Seems like there are a lot of cool things you could do, but IMO the challenge is coming up with a few things that are actually useful for a significant amount of code and yet remain possible to build.

[1] [http://www.comp.nus.edu.sg/~stevenha/visualization/](http://www.comp.nus.edu.sg/~stevenha/visualization/)

</comment><comment><USER5> Quote: "To sum up his talk here, he talks about inventing on principal–something you believe in."

Actually, I'm pretty sure he recommends investing on _principle_.

[http://www.merriam-webster.com/dictionary/principle](http://www.merriam- webster.com/dictionary/principle)

Quote: "a moral rule or belief that helps you know what is right and wrong and that influences your actions"

[http://www.merriam-webster.com/dictionary/principal](http://www.merriam- webster.com/dictionary/principal)

Quote: "most important, consequential, or influential : chief <the principal ingredient> <the region's principal city>"

<comment><USER6> [http://en.wikipedia.org/wiki/Muphry's_law](http://en.wikipedia.org/wiki/Muphry's_law)

</comment></comment><comment><USER7> We are trying this for our prototyping tool in the most straightforward way:

\- Evaluate and update result on typing

\- Inline show errors on typing

[http://framerjs.com](http://framerjs.com)</comment>


Facebook Is Worth More Than ... - Interactive Feature - <AUTHOR> http://www.nytimes.com/interactive/2012/05/18/business/dealbook/facebook-is-worth-more-than.html <comment><USER2> Let's play this game again in 7 days.

<comment><USER2> and 7 days have lapsed! FB is down 28%. Wonderful.

</comment></comment><comment><USER3> While I'm not going to say that facebook is worth 100 billion (or even the 66 billion it's at right now), it's easy to forget one fact: facebook is operating in almost every part of the globe. The companies that are referenced in the feature may be large and well established, but few if any have the global penetration of facebook.

<comment><USER4> Global penetration is only useful if you can make money from it though, and it brings the problems of operating in multiple countries with different currencies, cultures, legal systems etc.

Lots of the companies referenced in the feature have stayed in their home market for a good reason.

</comment></comment><comment><USER5>
      Ford Motor Company: $38.4 billion
      Public Storage:     $23.6 billion
      Whole Foods:        $15.4 billion
      Sara Lee:           $12.4 billion
      Campbell Soup:      $10.7 billion
      JetBlue:            $1.2 billion
      EarthLink:          $897.4 million combined

I think this does a better job of showing that stock prices are about _future expectations_ rather than _current assets_ than just about anything else I could find. Just have Ford Motor Co. on here typifies that.

The real question is whether it can possibly live up to that.

<comment><USER6> Facebook isn't tied to paying the pensions of hundreds of thousands of people due to poorly conceived agreements made in the 1970s which they will be nationalized if they attempt to get out of, which means they avoid the drag on their valuation suffered by the major American health insurance company on your list.

</comment></comment><comment><USER7> Given the fact that stock valuations are highly volatile I think the current drop os FB as well as comparisons of market caps is kind of pointless.

Things have the value people are willing to pay for them, and no matter what stock experts say this has imho nothing to do with actual values or assets a company might have. It maybe enough for some analysts to not understand your business model and your stock value drops way down. On the other hand, if analysts like it stocks go up. And that doesn't tell anything about the actual quality of your business model.

Equaly pointless but at least more entertaining were the list of what Apple could buy with its 100 bn in cash.

Interessting point in case: The soaring stock price of the german TV set maker (Loewe I think it was) after someone claimed they where about to de bought by Apple. Did the value of their assets change over night? No.

Now, FBs stock drops because people say they don't see any actual value behind and the stock was actually overvalued right from the start. Maybe it was I don't know. But nobody complains when stock drop because some banks say they don't belief in future prospects. So it seems to me the same people choose their arguments only to fit the current situation.

Not all of them of course, the really good ones (W. Buffet among others) act diffrently.

</comment><comment><USER8> Shouldn't this say "Facebook is valued more than..."?

</comment><comment><USER9> Fun way to generate a bunch at once: for(var i = 0; i< 100; i++) jQuery(".nytg").find("a").click()

<comment><USER10> ... and then the animations begin O.o

</comment></comment><comment><USER11> I have to agree with the sentiment - why is this an interactive?

Why not just stick all of the data in a single table or create a cool info graphic.

News sites also enjoy creating photo carousels. Why?

</comment><comment><USER12> Unfortunately, Facebook is worth only $66 billion now...so about two Pricelines.

<comment><USER13> Yahoo Finance shows a market cap of $84.84 billion as of tonight.

<comment><USER14> Google Finance shows $66.28 billion right now.

<comment><USER13> Interesting.

At the time of IPO, several sources said the $38 offering price gave FB a market cap of $104 billion. At $31 a share, that does indeed translate to $84.84 billion.

Google Finance lists 2.14 billion shares outstanding, which is where they get their market cap. Yahoo Finance lists 2.74 billion shares.

Hmmmmm.

</comment></comment></comment></comment><comment><USER15> Actually, Facebook is not worth more than Google ($195.7 billion)

</comment><comment><USER16> I'd venture that none of the brands mentioned in this comparison are used by as many people as Facebook. Everybody you know uses Facebook. How many people do you know that drive a Ford? 1 of 10?

<comment><USER17> But how profit does Ford make when someone buys one of its cars? How much profit does Facebook make when a new user signed up.

Users aren't everything.

</comment></comment><comment><USER18> Pointlessly interactive.

<comment><USER19> Gratuitous use of javascript.

</comment></comment><comment><USER19> How many bitcoins is that?

</comment><comment><USER20> The JS that drives that is awful. Why are they not using an array?

        nytg.buttonText="What else is facebook worth more than?,What else is facebook worth more than?,What else is facebook worth more than?,Keep going?,One more time?,Another one?,Again?,It might be time to stop,I can generate thousands of these".split(",");

<comment><USER21> If you think this is "awful" JS, you're in for a rude awakening.</comment></comment>


Lists of JavaScript methods which you can use natively - <AUTHOR> https://github.com/cht8687/You-Dont-Need-Lodash-Underscore <comment><USER3> Alternate title for the article: "Lists of lodash features replaced by ES6 if you don't mind throwing an exception when given invalid input such as null or undefined".

All kidding aside, a lot of our lodash code ends up looking something like this:

        function (xs) {
            return _(xs).pluck('foo').filter().value();
        }

That code clearly expects that xs is an array of objects. However, we might occasionally end up with xs being undefined, or with xs being an array but one of the elements is null, etc.

Most of the time, we want our function to just swallow those errors and return an empty array in such cases. This is exactly what lodash does, but if we tried to call xs.map(...) in that case we'd get an error. Similar caveats apply for grabbing the foo attribute if one of the array elements ends up being null or something.

For this reason, I recommend continuing to use lodash almost all of the time, even when there's a native Javascript method available.

<comment><USER4> > if you don't mind throwing an exception when given invalid input such as > null or undefined

That's exactly what I would expect. If only everyone always thrown an exception on any undefined, life would be so much better.

<comment><USER5> Depending on the particular domain of the task.

There are perfectly valid reasons why silently failing is OK.

<comment> squeaky-clean Seriously. A really common example, ever have a website that completely fails to load when you're running adblock? Would you rather have a blank page, or a 99% functional website with a couple of error messages in the console?

<comment><USER6> The answer is: that's an expected failure, so you make the error handling explicit by catching the error and taking care of it appropriately (including proceeding to the rest of the page load, naturally). Implicitly handling errors behind JavaScript's loose typing rules is a recipe for disaster.

<comment><USER7> Explicitly handling errors is almost always a bad idea, no matter what programming language it is. There are very few errors you can reasonably handle, and they must be designed for. It's specific application domains that need different handling strategies: e.g. embedded, device drivers, software that's trying to maintain some very strict invariants. A web page isn't usually one of them.

Usually errors should be sent up the stack to the request / event loop and logged / telemetry / etc.

The question here is something different, though. It's what should be considered an error, vs what should use the null object pattern. I don't think anyone can make a categorical judgement on which is better without context. It's suggested here that the null object pattern implemented by lodash is desired; I don't think it's wrong in principle to rely on it, as part of a cohesive design - e.g. it's used in such a way that it doesn't make development or finding bugs harder than necessary.

<comment><USER8> Take a look at Common Lisp and Dylan and their respective condition/restart systems. This is how error handling _should_ look like: they let you handle your errors where it makes sense and naturally recover from them if it's possible.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> The need for Lodash and Underscore is diminishing, but not because of JS getting native support for a subset of utilities, but because there are already better alternatives. Utility libraries like Ramda[1] or pointfree- fantasy[2] with related modules which offer a better support for FP idioms and more useful higher-order functions are what made me drop Underscore.

I think that, with a language with such tiny stdlib, there always be a need for some kind of utility belt-style library ("if only for convenience", as another commenter write, which is actually the main point of such libraries). It's just a matter of choosing the best library for your coding style and project at hand. It may be a hassle, but an alternative is an stdlib the size of Python's - and I'm not sure if it's a good direction.

[1] [http://ramdajs.com/0.21.0/index.html](http://ramdajs.com/0.21.0/index.html) [2] [https://github.com/DrBoolean/pointfree- fantasy](https://github.com/DrBoolean/pointfree-fantasy)

<comment><USER9> The Ramda API changes with every version. If you don't pay attention for a few months and accidentally upgrade (Ramda doesn't seem to want to do Semver, I'm not sure why), then suddenly half your code is broken.

We depend heavily on Ramda and I like its API better than Lodash and friends (it's more guessable, more consistent), but with the changes it keeps having I regret choosing it.

Our core product is currently on a Ramda version that's so old that there's no online documentation published for it, so we just look in the source. We ought to upgrade but I'm not convinced all code paths that use R are sufficiently covered by automated tests.

<comment><USER10> Technically, Ramda is using semver; 0.x releases are used for when the API is still changing substantially[0].

[0] [http://semver.org/#spec-item-4](http://semver.org/#spec-item-4)

<comment><USER9> Ahyes, good point. In the Ramda authors' defense, they never claimed it to be good for anything production level.

</comment></comment></comment></comment><comment><USER11> Instead of searching for the compatibility of each individual function I would much rather just use a custom build of Lodash with the collection of functions I need (which can even be handled by your build process now and some tree shaking). And I get a lot of utility functions with it too that I use a lot like Throttle and Debounce.

<comment><USER12> If you just use lodash from a CDN, many, many users will already have it. If you make a custom build, then everyone has to download.

<comment><USER13> Didn't someone do a study and found that cache hit rates for CDNs were in the 10-20% range?

You might be better off bundling lodash and tree shaking everything you don't actually use away.

<comment><USER14> And it will also lead to the site not working out-of-the-box for privacy- conscious people like me who block third-party JS by default.

<comment><USER13> Well you can avoid that with an inline script that checks for it and includes it from a local path if it fails.

But that's just more waiting, and you still end up downloading the ENTIRE script (unless you get REALLY fancy with webpack in a way I don't even want to think about...)

<comment><USER15> > But that's just more waiting, and you still end up downloading the ENTIRE > script (unless you get REALLY fancy with webpack in a way I don't even want > to think about...)

I have a friend who has done, in production, exactly what your subconscious is afraid of. I should get him to do a write up sometime: it's both amazing and horrifying at the same time...

<comment><USER13> I'd actually love to see that!

I've thought about it a bit before, and always ignored it because there'd be no real benefit.

But i could see writing a crazy webpack config that breaks out all my lodash functions into their own bundle, then tries to add a script tag to the CDN version, doing some quick processing to determine if it's in the cache, and if it's not falling back to including my own custom-built script tag (and canceling the request to the CDN version).

I'm sure it wouldn't provide any benefit to anyone, but it would be a fun code-golf exercise!

</comment></comment></comment></comment></comment></comment></comment><comment><USER16> There's a huge gotcha: _.map, _.forech, ... can iterate over objects (often used as associative arrays) - Native map can't.

At some point you'll need lodash and co again - at least for convinience.

<comment><USER17> Object.keys() is rather well supported these days though.

<comment><USER16> Yes, but means that you need to implement map, foreach, filter yourself. So you might be better off with lodash.

<comment><USER18> I think he's referring to `Object.keys(object).reduce`. We polyfill `Object.entries` so we do `Object.entries(object).reduce((result, [key, value]) => ...)`

</comment></comment></comment></comment><comment><USER19> [https://github.com/cht8687/You-Dont-Need-Lodash- Underscore#_...](https://github.com/cht8687/You-Dont-Need-Lodash- Underscore#_find) \- the Array.prototype.find() method that's suggested has _no_ support on Android's stock browser or Chrome for Android. That's a _huge_ chunk of the browser market, but there's no mention of it on the list. In fact, there's no consideration for mobile at all on any of the suggestions.

If you're going to use any of the suggestions, check MDN or CanIUse first.

<comment> lloyd-christmas Here's another useful resource, I think I found it from HN a while ago.

[http://kangax.github.io/compat-table/es6/](http://kangax.github.io/compat- table/es6/)

</comment></comment><comment><USER20> I understand why, and once upon a time I was the guy who would commit code where I replaced jQuery and underscore (at the time) calls with native calls. It works, and is totally fine. But what was the point? Some kind of optimization? It was pretty pointless in hindsight and just made my coworkers trouble. Now all my JS code is Ramda/lodash all the way, and it's great (although I opt for Clojure/script when possible)

<comment><USER21> These emperor has no clothes posts are very popular, and some may ask what's the point. It's a question worth considering. I think by instinct people especially programmer/engineer types like the idea of purity.

But if you consider that every decision must be put through a cost/benefit analysis, I think the appeal is that - I (or anyone in the future that will ever touch the code) must learn JS. OK. Now they must also learn framework X. That's the added cost.

Our memory is limited too, like a computer chip. When I know JS I can instantly access what I need. If you think of a Google or cheat sheet lookup like a disk access, well memory is faster than disk.

<comment><USER22> My rationale is that any one of these functions is probably going to be put into a utility function that's documented and named already, and of course tested with some optimizations, in some file somewhere in my code base. If it's useful enough, it'll probably be there. And while I don't often do front end, having these utilities support older versions of browsers or if there exist quirks in certain versions of browsers that render the solution nonviable is just not something I want to spend time caring about. When I did Java, the same articles would come out about Guava and Apache Commons.

One should not be afraid to use battle tested libraries, but don't bring dependencies for no reason.

</comment></comment></comment><comment><USER23> _.filter is NOT equivalent to Array.prototype.filter.

The array could be null/undefined, in which case the _.filter just works fine, but Array.protoype.filter does not.

I hate to riddle my code with null checks I actually do not care about.

<comment><USER24> (arr || []).filter... Is something I do when I'm not sure if the array is null or not. Looks shitty but works fine. (Now if arr is not falsy and not an array either, this blows up. But I don't know what lodash does then too)

To be honest, I'd rather check / handle nulls rather than to rely on an external library semantics. They might also change it tomorrow and upgrading would be a pain.

<comment><USER25> The language changes too. In ES5 `Object.keys` throws an error for `Object.keys('abc')` but in ES6 it returns an array.

<comment><USER24> Still a pretty conservative breaking change. Something you'd expect from a committee of people. Lodash has more wiggle room to make absurd changes in future.

<comment><USER25> Lodash follows semver so major changes are opt-in unlike lang level ones though.

</comment></comment></comment></comment></comment><comment><USER26> My main concern with Lodash is not necessarily the size, but that it adds to the API surface a new developer has to learn when entering a project. You get a lot more value from the cost of learning a dozen API methods from React compared to having a developer looking up pluck, pull, xor, zip, flow, etc from lodash.

I really recommend "Sebastian Markbage: Minimal API Surface Area - <USER2> patterns instead of frameworks" [http://2014.jsconf.eu/speakers/sebastian- markbage-minimal-ap...](http://2014.jsconf.eu/speakers/sebastian-markbage- minimal-api-surface-area-learning-patterns-instead-of-frameworks.html)

</comment><comment><USER27> For the sake of 25KB for the full Lodash library, is it really going to make much difference? That size will be eclipsed by just a single small image on your website.

Development is all about tradeoffs. Liberal use of Lodash can make for clean code that abstracts away subtle browser differences. For a small download size it sounds like a great tradeoff to me.

<comment><USER28> If the 25KB are packaged with each library you add to your webpage, + ads , + analytics then maybe.

One often doesn't need lodash. In fact, the only methods one does need are Object.keys to get the keys of an object and Array.prototype.reduce to iterate over an array, 90% of the time.

But yes, difference, zip, chunk, assign... are semantic and make for cleaner code. And yes flatten, xor are non trivial to implement, and the code one doesn't write is the code one doesn't have to test if already tested.

Of course, the best solution would be for the ECMA spec to implement most of lodash methods. I would also like to see an official way to curry, the same way Function.bind allows partial application.

</comment></comment><comment><USER29> Well, Lodash is focused on performance, and 3.X.X supports IE8 and a lot of older browsers, it's a pretty solid util library. If you add in all the good utilities function. As long as you use them a lot in your code, Lodash is definitely worth it

</comment><comment><USER30> A nice thing Lodash has that Native doesn't is the 'matches' shorthand for things like find. I find it easier to read and quicker to write than a callback.

        _.find(items, {id: 10});

</comment><comment><USER31> Functions like repeat() still need lodash - it's not supported on IE and Opera:

[https://github.com/cht8687/You-Dont-Need-Lodash- Underscore#_...](https://github.com/cht8687/You-Dont-Need-Lodash- Underscore#_repeat)

</comment><comment><USER32> I prefer Ramda to Lodash and Underscore. It has a lot of functions that are missing in vanilla JS.

<comment><USER25> You might dig

[https://github.com/lodash/lodash/wiki/FP- Guide](https://github.com/lodash/lodash/wiki/FP-Guide)

</comment></comment><comment><USER33> I don't use Lodash, but I remember reading that it does lazy evaluation[1]. For example, if you map an array, then take the last 3 items, it only calls the map function for those 3 items.

Does anyone know if V8 can do any optimizations like this for native Array functions? That would be a good thing to know before downloading lodash.

1) [http://filimanjaro.com/blog/2014/introducing-lazy- evaluation...](http://filimanjaro.com/blog/2014/introducing-lazy-evaluation/)

<comment><USER34> This cannot be done with native array functions as they exist now.

The reason Lodash is able to do this is because the collection is wrapped in an a special object that keeps track of all of the functions you call on it. Those functions don't run until you call .value() on the whole pipeline that you have setup, and then the optimization happens.

Note that this requires a separate API. One API returns your results immediately, the other (lazy) API instead returns a wrapper object after each call without yet doing the mapping/filtering/etc, ready to add more instructions to the pipeline that you must ultimately call .value() on in order to actually run.

Native functions don't have this separate lazy API that does the wrapping with this special object, and don't have/return an object with a similar .value() method.

</comment></comment><comment><USER35> Getting rid of unnecessary dependencies can have a huge impact on site download performance, especially on mobile. Even in the case of having the site cached, every resource you link will have to perform an HTTP request to at least receive NOT-MODIFIED. It can add up, especially if you're on a semi- spotty connection and trigger TCP congestion avoidance.

<comment><USER13> Don't miss the forest for the trees. Re-implementing _.forEach, _.map, and _.reduce to do something like loop over objects yourself is going to most likely end up taking more code than just using those functions from lodash.

Not to mention that you most likely won't have the same amount of testing, speed/optimization, or "familiarity" across devs with a home-grown solution.

Yeah, don't pull in lodash if you are making a small library and you only need it once, but if you avoid lodash in a codebase where you use it a non-trivial amount, it's most likely going to be worth it.

Plus with modern (at least to js land) tree shaking, and/or the way that lodash can package each function individually, you don't need ALL of lodash in order to use one or 2 functions.

<comment><USER35> I do not agree at all. What is so hard about for loops? I do not agree that using the native-to-the-platform looping constructs will create as much code as half a megabyte. I'm looking at it right now: the full build of Lodash is 503KB. That's also half-a-meg of code that needs to be parsed by the JS engine. And nothing else you said has anything to do with site performance. Do users care if it took you 10 seconds versus 11 seconds to write a particular looping construct? Do clients care?

<comment><USER13> Well you conveniently skipped right over the part of my comment where I said that you shouldn't be using the whole 500kb lodash library... (also, it's disingenuous at best and borderline lying to say that lodash is 500kb. The DEVELOPER version is 500kb, the production version is 67kb before gzipping, and 22kb after gzipping)

If you are only using _.forEach, then you should only include _.forEach, which comes out to about 10kb before gzip compression, 5kb after (i just built it myself to test). And all but about 1.2kb of that is "core" code, so if you add additional lodash functions, most of them will increase the code size by about 2kb at the most.

That means that for an overhead of about 8kb, you can start adding extremely useful functions all throughout your codebase with very little overhead. 1.2kb to easily and quickly iterate over an object using the key and the value in each block;

        _.forEach(obj, function(value, key) { // do stuff })

Pure js:

        Object.keys(obj).forEach(function(key) { var value = obj[key] // do stuff })

Not that much of a difference space wise, but the performance is terrible if you are iterating over a large object, and by using Object.keys you exclude some UAs.

Now let's look at _.find in an object...

        _.find(obj, { 'age': 1}) // returns the first object (in the object) that has a property 'age' that equals 1.

Pure JS:

        var objKeys = Object.keys(obj)
        var retval
        for(var i; i < objKeys.length; i++) {
          var value = obj[objKeys[i]]
          if ('age' in value && value.age === 1) {
            retval = value
            break
          }
        }

And that's untested, will only work for an object of objects, has unknown performance, and sure as shit took me more than 1 extra second to write (about 5 minutes once i looked up what the compatibility of the 'in' operator is).

You could use the native .find() function, but that won't work on chrome for android, android browser, IE (any version), safari 7 and older, and opera. Plus you'd still need something like Object.values() in order to convert the "parent" object into an array to search through.

Plus what if i want to find an object in an array and in another object? (which I actually just had to do, which is why i thought of this use case) Well now you've just doubled your code, doubled the amount of tests you need to write, doubled the chance for random bugs to crop up (what happens if one of the object values is undefined? What happens if obj is null?).

With stuff like the lodash cli where you can make builds that literally only contain what you need, the lodash babel plugin that will allow you to require lodash functions and it will build only what you need, or webpack which will tree-shake away everything you don't need (and actually does a better job than the lodash-cli does!), there's no need to avoid lodash like the plague.

I'm not saying include all of it, i'm not saying use it in everything, i'm saying that you should use your brain and include it if it's going to increase the speed that you can develop, reduce the number of bugs you will face, simplify your codebase, and won't negatively impact your users. (after all, a single image will blow the 5kb of js you'll be saving out of the water)

<comment><USER35> I skipped over it because it's a solution in search of a problem.

I think developers should be expected to understand the native constructs of the language they use. You previously also talked about "being more familiar to onboarding developers". Why should Lodash be more familiar than the native looping constructs to anyone? Why _would_ Lodash be more familiar to a developer you're onboarding who is more used to some other library completely?

If you're not used to using Lodash, then it would not be a time savings to use it, as you'd have to spend time learning its idioms. It means you've probably learned other idioms, instead (perhaps, you know, the ones you should have learned to be able to claim to know how to use the language). So if you know the native idioms, there isn't a point to learning Lodash.

You had to take time to look up operator-in because you're not used to using operator-in. Regardless, it was a waste of time. What's wrong with the following code?

        for(var k in obj){
           if(obj[k].age === 1){
              // there you go
           }
        }

And I mean problems with that code itself, not problems that are actually a problem with upstream code? And how much of the problems with that upstream code are because your project is a Gordian Knot of 3rd party dependencies?

You default assume other people's code is better than yours. In the last 20 years of software development, I've seen code better than mine in several standard libraries. But the JS ecosystem is not one of them.

<comment><USER13> >You had to take time to look up operator-in because you're not used to using operator-in

I'm using in (`if('age' in value)`), but not for..in. There's a difference. I don't need to use that (you didn't in your example, even though you should have), but then my code would blow up in many of the same cases as yours will.

Anyway, what's wrong with that code is you'll need a hasOwnProperty check, you'll need to break out of the loop when done, it blows up if 'age' isn't a property on one of the objects in the object, it blows up if one of the properties of obj isn't an object, it blows up if obj is null/undefined, and it will deoptimize the entire function it's in in most cases in V8.

To at least fix the bugs that yours has that mine didn't, your code should be:

        for (var key in obj) {
          if (obj.hasOwnProperty(key)) {
            var val = obj[key]
            if ('age' in val && val.age === 1) {
              // there you go
            }
          }
        }

but again that still needs some undefined/null guards at a few spots, and it needs to be able to handle both an array and an obj at where obj is to really be an equivalent of what i was using _.filter for.

>You default assume other people's code is better than yours.

No, I know the lodash code i'm using is better than mine because i've looked at it, i've looked at it's test coverage, i've looked at it's performance numbers, and i've looked at it's usage.

Also... >I skipped over it because it's a solution in search of a problem.

Then why did you skip this part in my last comment:

>it's disingenuous at best and borderline lying to say that lodash is 500kb. The DEVELOPER version is 500kb, the production version is 67kb before gzipping, and 22kb after gzipping

You made me curious, so i actually took a look at my current in-development app i'm writing that i include lodash. The grand total from all lodash functions is 22k un-gzipped, and 7k gzipped.

For that i've significantly reduced my code complexity, increased compatibility, reduced the amount of tests i needed to run and maintain, and improved performance in one pretty out-there edge case.

You don't need to use lodash, and in many cases you shouldn't. But don't act like your applications are better than others in any way because you aren't using lodash.

<comment><USER35> > it blows up if 'age' isn't a property on one of the objects in the object

No it doesn't. It will return as undefined, which evaluates to false when compared to 1 using either triple- or double-equals.

And why call hasOwnProperty here? I'm pretty sure I want to know the age of any properties inherited into my object from a superclass.

At worst, I will grant you an undefined/null check:

        var val = null;
        for(var k in obj){
          if(obj[k] && obj[k].age === 1){
             val = obj[k];
             break;
          }
        }

This works with both objects _and_ arrays.

<comment><USER25> I'm guessing after repeated use you'd abstract that into a function. Maybe even a collection of them.

<comment><USER35> No, why would you? It's just a loop. Not all code deduplication is a good idea.

<comment><USER36> > No, why would you?

Because he's a better programmer than you are, and he knows it.

> It's just a loop.

There are many kinds of common patterns in loops, abstracting them into resuable higher order functions, aka a collections api is rather basic functional programming; "it's just a loop" is a blub phrase of someone who doesn't see the point because they have tried it long enough to understand the value in a different paradigm.

<comment><USER35> I know it's currently thought as so, but functional programming is not the be- all, end-all paradigm. If you've been around for a while, you'd have seen the ebb and flow a few times already.

<comment><USER36> No one said it was, but in this use case it's far superior to hand written loops. Virtually all modern programming languages have a functional collections API precisely because of this advantage. If you're still writing loops by hand, in nearly all cases, you're stuck in a less effective procedural programming mindset and have simply stopped updating your skills beyond the basics.

If you've been around for a while, you should have already accepted the benefits of functional programming in the places it's most effective and banished low level procedural programming of loops except in cases where extreme optimization is required. There's no eb and flow here, higher order map/reduce/filter style has been the best way since the 60/70/80's when Lisp and Smalltalk were doing it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER37> I would consider switching from underscore if there was a reliable polyfill so that I wouldn't need to be aware of all these browser compatibility constraints. That way I can just drop the polyfill in a couple of years instead of replacing every underscore use.

I guess the babel polyfill would do this.

<comment><USER38> babel polyfill is roughly core-js.

</comment></comment><comment><USER39> It took me a moment to figure out what this was for:

[https://github.com/cht8687/You-Dont-Need-Lodash- Underscore/b...](https://github.com/cht8687/You-Dont-Need-Lodash- Underscore/blob/master/convert/convert.js)

Cripes!

</comment><comment><USER40> This seems like a great post on why you should be using lodash.. especially all those IE unsupported things. Like mentioned in the comments, it's not just about having one or two of these features, it's about how they compose so nicely in lodash

</comment><comment><USER41> You'll be stuck with using a shim for old browsers for quite a while to come, especially when it comes to mobile.

The good thing is, at some point in the future you can just drop the shim and everything keeps working.

Lodash does has a lot of additional nice utility functions though.

</comment><comment><USER42> Yes, you could implement every feature of just about any library yourself. Why, though?

<comment><USER43> I think the point of the page is to demonstrate that for many, many lodash functions, there are direct equivalents in native JS - not rewritten features.

<comment><USER42> They don't have the lazily-executed features though, right?

</comment></comment></comment><comment><USER44> That's interesting why some of functions (_.repeat, _.findIndex) were marked as "Not supported" in Opera but all of them are supported in Chromium-based browsers. Did the author only consider Presto-powered Opera?

</comment><comment><USER45> Would it be possible to build an tool that scans your code for simple helpers you wrote yourself or that you include from dependencies and replace them with equivalent functions of lodash or native?

</comment><comment><USER28> That list ignores mobile browsers though, the ones that are mostly never updated.

</comment><comment><USER46> maybe lodash itself should warn when something is available natively, but for it to add extract browser detection for this is overkill.

the real way to do this is to write ES6 and compile to ES5 and provide both to the browser.

</comment><comment><USER47> What do the checkmarks mean?

</comment><comment><USER48> waiting for non mutating versions of sort and sortby

<comment><USER49>
      [].concat(array).sort()

</comment></comment><comment><USER50> or you can just use lodash

</comment><comment><USER51> The native version of find is still using _.find.

<comment><USER52> Eh? No it's not, it's just using Array.protoype.find

</comment></comment><comment><USER53> "However, when you are targeting modern browsers" \- possibly one of the worst mistakes companies do. Then they decide to support older browsers after customers complaints. Then shit goes down!

<comment><USER54> I've yet to see a company going under and citing lack of old browser support as principal culprit.

</comment></comment><comment><USER55> You might also not need to write any code at all, just set up a form for customers to send in their requests and hire a bunch of people to manually process them. Bam! 0K, no dependencies, almost instantly working web service.

But that's not your priority when building website, it doesn't matter if your JS is 60Kb or 20. No one cares how much dependencies you build system pulls. You need tested, reliable and working libs to do their job, and not write your own routines for 3 months.</comment>


Ask HN: Bonding Internet Connections - <AUTHOR> Hi Guys - I'm based in Australia and have slow ADSL2+ (4Mb/1Mb down/up). I live semi rural so have limited to no mobile reception. I can get 'skymuster' which is a satellite connection that should provide about 20Mb down. That said I've has mixed reviews like it 1) stops working in heavy rain plus 2) accounts are limited to 200bg and I probably use double that in a month and 3) I run my mobile calls over wifi so worried about the latency of satellite only.<p>I've started looking at signing up to both services to get the best of both and  bonding these 2 connections. The solution to bond connections that keeps showing up is Speedify. There doesn't seem to be a huge amount of options for a non-technical person like me. I'm wondering if people have any recommendations on the best way to bond 2 internet connections? <comment><USER2> If it were me, I would put each service on it's own wifi device/network and switch between networks based on my own whims. In a perfect world, it might be perfectly automated. But spending a minute to switch networks is a tradeoff I'd be willing in exchange for having the machine do what I want.

[https://askubuntu.com/questions/53499/how-to-merge- multiple-...](https://askubuntu.com/questions/53499/how-to-merge-multiple- internet-connections-into-one)</comment>


Triode and Internet Radio - <AUTHOR> https://furbo.org/2019/11/14/triode-and-internet-radio/ <comment> java-man This is great!

But how do you make [will be making] money?</comment>


What Is a Data Scientist? - <AUTHOR> http://www.forbes.com/sites/danwoods/2011/11/27/linkedins-monica-rogati-on-what-is-a-data-scientist/

<comment><USER2> A data scientist is two things:

1\. A business analyst who has traded Excel for a Unix command prompt and a scripting language, because (a) there's more data now than before, and (b) data is harder to clean because of (a).

2\. A mythical unicorn creature that has spawned a conference, multiple books, and thousands of page views for O'Reilly, Business Insider, Forbes, etc. They're all "data-driven organizations" that double their page views any time the word "data" is whispered. As a result, they parse shitty articles into four ad-driven pages and publish books on "Data Mining Your Cat" or "Machine Learning Models for Organic Dietary Schedules."

Here are some better questions that will save you some time:

1\. What is this article? Buzzword soup mixed with terrible journalism.

2\. How do I become a data scientist? Don't--instead, build a good foundation in statistics and keep coding. You'll be happier and wealthier for it.

EDIT: removed a bunch of snark. Not all of it, obviously. ;)

EDIT 2: added some snark back. I really hate this "data scientist" meme.

<comment><USER3> I second your snark, and also find "data scientist" to be analogous to "food cooker", but I've also come to realize that there _is_ a need for branding whatever-it-is as separate from "business analyst" because otherwise expectations from non-technical customers get very confused.

I interact with many buyers of buzzword-laden "big data" (snark on that one reserved for another day) and "data science" offerings. If you tell them you're a business analyst they will make many hidden assumptions based on the overall population of people using that title. Among those assumptions:

1\. The business analyst will probably know SQL, but if we want to do something like analyze our query logs it will cost us developer time.

2\. The business analyst will have domain knowledge about financials and _maybe_ user engagement, but probably not anything else. The business analyst will not be able to tell us, for example, the characteristics of our 99-th percentile slowest page loads.

3\. The business analyst is not hip and modern, because everything is about the "big data" these days.

Realistically, the language of modern business data applications requires a name for someone who is not just a business analyst as we knew them from the 90s. The people offering the services need a name to differentiate themselves when applying for jobs, and the customers need a way to indicate that they are not looking for "just a business analyst." We seem to have ended up with a rather foolish bit of terminology to serve this need, which is not surprising given that it emerged to facilitate an asymmetric market of the clueless looking for the knowledgeable.

</comment></comment><comment><USER4> what's with all the resentments? A few years back, titles like UX designer, UI designer, front-end developer, and back-end developer were non-existent too. Aren't they all just designers or programmers?

As a maturing technology tree branches out, more and more specialists will be born.

<comment><USER2> Totally agreed. Those titles serve to differentiate between responsibilities given to designers and programmers.

So how does a data scientist's responsibilities differ from those of a business analyst?

<comment><USER4> From a 30k feet point of view, the difference is that a business analyst or data miner focus on answering questions with data; whereas, a data scientist focus on asking questions with data.

<comment><USER2> What does "asking questions with data" mean?

<comment><USER4> Quoting from the article,

"On one side, I've been working on building products, like the recommender system, Talent Match, modeling and finding ways to empower users to use LinkedIn through their products. Groups You May Like was another product I started.

The other side is finding interesting stories in the data. It's exciting to be able to tell stories collected from the careers of 120 million professionals, and trying to learn what that data can tell us about the world at large. That has given us stories such as, "top times of year to be promoted," "overused buzzwords" and "top CEO names." Industries are ebbing and flowing, and there are a lot of insights about the world at large from people's profiles when they are combined and aggregated."

</comment></comment></comment></comment></comment><comment><USER5> When I see

 _It is a new and emerging field, and it has to do with adapting to demand._

I know I don't have to read anymore. This sounds like describing your job as an elevator operator as "managed a complex interface to adapt to customer demands by efficiently handling their transport."

She answers it in the first sentence: _Monica Rogati: By definition all scientists are data scientists._

That's it. Article done. No more SEO bullshit. For that matter, all statisticians are, too.

</comment><comment><USER6> A "data scientist" is a business analyst who has never worked in industry before and is unaware that there already is a job title for what they do.

<comment><USER7> Or quantitative analyst, but that sounds like you're participating in some kind of banking fraud.

<comment><USER8> I agree. There are different values in data to be discovered not just business.

</comment></comment></comment><comment><USER8> The article seems to describe a person who does data mining for living. I guess "data scientist" sounds better than "data miner".

<comment><USER9> I've seen a wide variety of job descriptions for these jobs. Sometimes it sounds like a data miner, sometimes a business analyst, sometimes an accountant. It's hard to know what a Data Scientist is until you look at the specific job description.

</comment></comment><comment><USER10> I work in scientometrics, which is like econometrics but with scientific papers and patents (patents are not optimal, but it's an adequate proxy for innovation). It's useful to detect new trends in science and adjust funding accordingly.

We do a lot of data mining, information extraction from very organic sources, data visualization, etc. It's a growing field and it's very challenging and we have access to incredible datasets.

I think I fit their definition of a data scientist, but I'll never use that title. It's pompous and sounds something like someone in marketing would make up (and I worked as a market research analyst for a number of years). My title is simply research analyst.

Data scientist is bad, but the worst title I've seen was: web strategist & tactician

</comment><comment><USER11> The term is pretty broad. I think the difference between a Data Scientist and a Statistician is the emphasis Data Scientists put on machine learning, databases, and distributed processing.</comment>


CNN Settles Defamation Lawsuit with Covington Student Nicholas Sandmann - <AUTHOR> https://www.yahoo.com/entertainment/cnn-settles-defamation-lawsuit-covington-211655456.html <comment><USER2> The absolute worst part of "journalism" today, is how these organizations have a slush fund and insurance for cases where they're caught lying and destroying lives - never mind actually doing the job of verifying a story, they've just de-risked not verifying it. It is all factored into the risk-model of their operations.

For anyone following this, Elizabeth Warren got off without consequence for amplifying these smears because: "claims against them (congress men/women) are barred by sovereign immunity under the Federal Tort Claims Act" [1]

So - in the US, as long as you're a serving member of congress, you can unload on a private citizen with zero consequence.

[1]: [https://www.huffpost.com/entry/judge-dismisses-covington- ken...](https://www.huffpost.com/entry/judge-dismisses-covington-kentucky- students_n_5dc20b5ae4b08b735d61b8fc)

<comment><USER3> The risk model that Gawker was using apparently didn't account for Peter Thiel - who destroyed them.

[https://www.thetimes.co.uk/article/how-peter-thiel- destroyed...](https://www.thetimes.co.uk/article/how-peter-thiel-destroyed- gawker-with-a-little-help-from-hulk-hogan-zs85dpzvl)</comment></comment>


Science has infected itself (voluntarily) with a life-threatening parasite - <AUTHOR> http://bjoern.brembs.net/2015/09/many-symptoms-one-disease/ <comment><USER2> Yep, one of the ways that academia distinguishes itself as a "sick system" is a complete inability to organize collectively against threats or to maximize opportunities.</comment>


'Duck Dynasty' vs. 'Modern Family': 50 Maps of the U.S. Cultural Divide - <AUTHOR> http://www.nytimes.com/interactive/2016/12/26/upshot/duck-dynasty-vs-modern-family-television-maps.html <comment><USER2> I really dislike these county maps. Darker color is shown as more fans, when in reality some of the largest, more intensely shaded counties have relatively few people in them. I believe it imparts a false impression of whatever the map is trying to inform the viewer on.

edit: douche points out that these maps are not purely based on county lines.

<comment><USER3> But if you don't normalize by population, you just end up with a map of the most populous locations instead of a map of the highest popularity

<comment><USER4> I think you don't understand what that word 'popularity' means...

<comment><USER5> I guess you don't believe something can be popular in a small community.

<comment><USER4> It can be, that doesn't make it popular in general. Duck Dynasty has zero viewers in my living room, does that make it an unpopular show? Having a small number of absolute fans in isolated clumps does not make something popular unless you specifically scope the definition to make it appear so.

</comment></comment></comment></comment></comment><comment><USER6> Many of the shows are based on affinity or identity politics so the results are not terribly interesting.

Unsurprisingly a TV show based on affinity for Louisiana or affinity for LA will have by far the strongest signal be predictable affinity for either LA area. Likewise the identity politics, its very hard to express surprise that a TV show carefully engineered to appeal to black people, successfully sells to black people, therefore the map of viewers extremely strongly resembles a population map of black people.

If they had corrected for those effects THEN they would have had interesting data.

I did find it interesting that "deadliest catch" correlates more strongly with latitude than distance from the coasts. I've never watched, but I'd assume its mostly set on a boat?

<comment><USER7> I think the point is that the urban vs rural divide has not been the dominant conflict in America up until now. In the past other identity politics such as black and white or north vs south have dominated. Every state has rural and urban areas - why is it just now, in the early 2000s, that the urban vs rural cultural divide now dominates the cultural discourse?

Duck Dynasty and Modern Family is just one more symptom of the cultural divide. It's interesting because it's a small part of a much larger conflict with major political and economic implications that have already been felt (most obviously, the recent US election).

Also for me it's personally very interesting. I'm going to start watching shows that it would not have occured to me to watch, because it's one way to escape my own cultural bubble. Normally Duck Dynasty and Empire wouldn't be on my list, now they are - because it's a way to understand a culture that would normally be somewhat alien to me.

<comment><USER8> > I think the point is that the urban vs rural divide has not been the > dominant conflict in America up until now

Given the Connecticut Compromise at the start of the union, urban vs rural have been a part of the USA since the beginning.

<comment><USER9> It was also basically the conflict that began the Civil War. The South was predominately agrarian/rural and the North was mostly industrial/urban.

</comment></comment></comment></comment><comment><USER7> Oddly enough, this map makes me think Trump is more intelligent than I thought. Educated urbanites made fun of the GOP for having a Duck Dynasty cast member as a convention speaker. In reality, that speaker probably had more appeal to the average Trump voter than any of the parade of elites that the Dems brought out for their convention.

<comment><USER10> How come the millionaire Duck Dynasty cast member isn't an "elite," but everyone brought in by the Democrats was?

<comment><USER11> To me, something also worth noting is that prior to the Duck Dynasty show, none of the people behind the company had their well known "bearded outdoorsman" looks. There's a widely circulated photo where they look like your average upper middle class suburbanite.

The point on the Democrats celebrity endorsement is true, but I'd argue that the GOP celebrities, including the Duck Dynasty people, are of the same vein and aren't the rural everyman they portray on the show.

<comment><USER9> I would actually argue that the opposite is true - that their previous personas were an act put on to meet social norms. They are certainly something of a caricature of themselves today, but is likely a lot closer to how they see themselves.

</comment></comment></comment></comment><comment><USER12> The maps are somewhat (ok, a lot) misleading because they show land area, not population. Duck Dynasty looks like a giant hit in Harney County, Oregon, but come on, there's only 7,146 people living there (2013).

<comment><USER13> But if almost everyone that lived there loved it the the the label is accurate. You think it's misleading because it doesn't convey a population density component?

<comment><USER12> Yes, that's exactly what I'm saying. That map, at least at first glance, makes Duck Dynasty look like a giant hit in Oregon. You have to read the fine print to find out that it's essentially just because a bar in Burns has a satellite dish.

<comment><USER14> > That map, at least at first glance, makes Duck Dynasty look like a giant hit > in Oregon

Well, it makes it look like a big hit in Harney County, OR, and a flop in Portland. Which appears to be accurate-- of the people in Harney County, lots of them watch Duck Dynasty. There isn't much fine print there.

</comment></comment></comment></comment><comment><USER15> Watching late night TV, it's interesting how political Seth Meyers' show has become -- on par with Jon Stewart and Trevor Noah. Colbert is slightly less biting. Then Fallon, very gentle.

Yet Fallon's ratings are still weak in the Duck Dynasty areas. (Being gentle doesn't buy him much?)

<comment><USER16> People know when you're making fun of them and tune out.

<comment><USER17> I am a liberal and even I have tuned out of these late night shows as I got sick of the low quality mockery of "the other side". I initially had high hopes from Trevor Noah but his race baiting approach to mockery (and I say this as a "person of color" if that means anything) just put me off.

I've had a year without late night TV or "mainstream news" and frankly, I feel a lot better. I've been able to focus a lot on furthering my knowledge and experience in technical and scientific things.

<comment><USER18> My issue with Trevor Noah and his ilk is they peddle the false, shallow version of "diversity" which is anything but. As long as a bunch of socioeconomically identical, young, childless, professional, and urban people have enough variance in the melanin content of their skin, they are a diverse group.

Former military? Drive a pick-up truck? Grew up in a trailer? Yeah, nobody wants THAT kind of diversity.

</comment></comment></comment></comment><comment><USER19> > When we looked at how many active Facebook users in a given ZIP code "liked" > certain TV shows

How are they getting Like data from Facebook Pages that granular from Facebook?

<comment><USER20> By asking them for it. IIRC, they did the same with various sports fandoms a while back.

</comment></comment><comment><USER21> They didn't mention it in the article, but a cursory glance makes Tosh.0 look like the battle ground map.

</comment><comment><USER22> Odd that they chose African-American as a singled out demographic in addition to the urban/rural split. They could have selected Hispanic. It's a larger demographic.

<comment><USER9> Hispanic people tend to be more politically divided than those of African ancestry, who have historically voted as a bloc.

</comment></comment><comment><USER23> Given the direct comparison to the result of the election in the opening paragraph, I was disappointed that they didn't quantify the similarity of each show's map to the electoral (county-by-county) map.

</comment><comment><USER24> Tosh.0 (#10) has an interesting map

seem not especially urban, but with a pretty sharp drop off right at the Mason Dixon line

seems like maybe it perceived as too much making fun of southern culture? I haven't watched a ton of Ridiculousness (#13)

but my impression of it is that it's a less snarky show with highly similar clip content

and it seems to appeal to a much broader area of the country

</comment><comment><USER25> I'd be more interested to know which of the areas has the highest median fanbase of all the shows. Based on the conclusions this article wants us to draw, certainly that would be the "least culturally polarized" place in the U.S? Or is this just more data noise with very little signal value...

</comment><comment><USER26> So it is confirmed watching videos of guys getting hit in the balls is universally funny among all groups. "Ow My Balls!" being most popular show in 2505 is looking like a very prophetic right now.

</comment><comment><USER27> Nothing surprising here.</comment>


The UK government now says it is Not going to try to ban encryption - <AUTHOR> https://www.businessinsider.com/uk-government-not-going-to-ban-encryption-2015-7

<comment><USER2> > [David Cameron] wanted to "ensure that terrorists do not have a safe space > in which to communicate."

And then we might ban umbrellas, so that terrorists are always wet and miserable.</comment>


Make a Photo Filter with Machine Learning - happy-go-lucky http://motherboard.vice.com/read/hack-this-make-a-photo-filter-with-machine-learning <comment><AUTHOR> Good link. Thanks for sharing!</comment>


Telepresence: the next killer app (Cringely) - <AUTHOR> http://www.pbs.org/cringely/pulpit/2007/pulpit_20070831_002850.html

<comment><USER2> Sure. And we'll have cold fusion by 2010, and a man on Mars by 2012.

Fiber-to-the-home has been promised for over 10 years. It may be getting closer, but widespread availability by next year? I doubt it.

But the biggest problem is that no one actually WANTS a videoconferencing unit in their home. The technology's been around for decades; ok, maybe not a high- res large screen TV, but a 5" screen over POTS. To put it simply, people don't want to have to dress up and do their hair just to place a phone call (and what do you do if someone calls when you're in your PJs?)

The only real application at home are long-distance calls with family members or friends who live far. This works okay with webcams, and I can't see enough demand to buy large-screen video-conferencing units for this purpose to make it a killer app.

</comment><comment><USER3> The economist just had a story on this:

[http://www.economist.com/business/displaystory.cfm?story_id=...](http://www.economist.com/business/displaystory.cfm?story_id=9687655)

Doesn't really look like startup territory to me.

</comment><comment><USER4> Video conference units are awesome in work from home developer scenarios. When collaborating on code, the ability to see the guy at the other end coding away, is soooo much better than wondering if he hung up or got disconnected when he stops talking to think or type. It really must be tried to be believed. (And understanding Indians is a lot easier when you can see as well as hear them:)). Also, with these things available, there is even less reason for developers not to work out of private offices.

YC should convince Tandberg or Polycom to provide them some samples for a lower cost. I'm sure some founders could find ways to put them to good use, and the manufacturers could get some exposure in markets where they're not well represented.

</comment><comment><USER5> He's not talking about video-conferencing with a dinky webcam which yes, has failed. He's talking about a system where it really feels like the person is there. The attributes of life size-ness (sp) and eye contact make the difference.

I don't think people will want this to replace telephone calls, rather to hold business meetings. A Thanksgiving dinner would be pretty cool too. So it feels like everyone is at the same table.

</comment><comment><AUTHOR> The article mentioned Apple as the company who might sell these systems, but I wonder if a start-up devoted exclusively to this business model might do it better? One could use off-the-shelf hardware (to a large extent) and be almost purely a software company.

<comment><USER2> The camera and microphone can make a huge difference. Businesses use brands like <http://www.tandberg.com/> or <http://www.polycom.com/> and some of their hardware is very good, if expensive. I'm not sure how off-the-shelf hardware compares.</comment></comment>


Announcing Chef Server 12 Release Candidate - <AUTHOR> http://www.getchef.com/blog/2014/09/07/chef-12-release-candidate/

<comment><AUTHOR> A related announcement about their open-source strategy: [http://www.getchef.com/blog/2014/09/08/there-is-one-chef- ser...](http://www.getchef.com/blog/2014/09/08/there-is-one-chef-server-and- it-is-open-source/)

</comment><comment><USER2> I would love to hear about Erlang and Postgresql adventures of the Chef team. Did you find Erlang problematic to work with Postgresql (there are a couple of not very actively developed drivers that people usually complain about) ?

Did you move more code to Erlang in version 12 compared to v.11 ? Do you regret moving to Erlang now and are you shopping around for a new platform (JVM) ?

<comment><USER3> I'm an engineer with Chef who for the 12 released has focused on the upgrade process from the Open Source Chef 11 server, as way of background.

We've had no problems working with Erlang and Postgres. We use epgsql as our Postgres driver ([https://github.com/epgsql/epgsql](https://github.com/epgsql/epgsql)).

That being said, Chef doesn't tax the db heavily and our Postgres needs are not complicated. We did write our own db abstraction layer, called sqerl. It's open source (as all the server is): [https://github.com/opscode/sqerl](https://github.com/opscode/sqerl)

For version 12 we did move more code into Erlang. While version 11 put most of the code into Erlang, the multi-tenancy and RBAC system remained in Ruby and on CouchDB (At the time this was Enterprise only, with 12 this is all open source). A big push for 12 was moving this into Erlang and Postgres. With this complete the entire server is now all Erlang and Postgres (except perhaps for some small periphery tooling).

We don't regret moving to Erlang at all. We have no plans to move off of it and are very happy with it. By making the change to Erlang the scale of the server improved tremendously and there's no compelling evidence that switching technology stacks would offer us anything Erlang doesn't.

That being said, we're not going to use Erlang just to use Erlang. If there is a compelling reason to use another platform for something, we will, but the server isn't switching anytime soon.</comment></comment>


Microcontroller LCD Initialization (2012) - <AUTHOR> http://web.alfredstate.edu/faculty/weimandn/lcd/lcd_initialization/lcd_initialization_index.html <comment><USER2> One bug that I encounter many times in projects using similar displays is not giving enough time for commands to process. Often times what works while testing may work 99.99% of the time but that 0.01% it doesn't work could end up as an incorrect character or even an invalid command!

A recent bug I figured out later was sending a certain graphical character matched the "display off" command, and the command bit was not being set quickly enough due to a long cable connection. Once the display off command was sent the screen would not turn back on...

The best way to solve this is to implement firmware to read the status flag of the display, if you are lucky enough to have one. I find this helps a lot with all types of sensors and other external interfaces, send the data and read it back. You will thank yourself that 0.01% of the time it didn't work!

</comment><comment><USER3> Gah I hate these bloody awful displays. You find out regularly that the display's memory isn't organised how you think (linearly) because the early displays were tiny, so writing say a line out on a 40x4 display turns into a nightmare.

The positive bit is once you've hidden all the oddness behind an API (mine is lcd_init(), lcd_cls(), lcd_pos(x,y), lcd_write(str) ) then they're totally fungible.

<comment><USER4> I think it's because bigger displays consist of multiple controllers, handling different sections of the display. (at the bottom, there should usually be 2 chips, but for bigger displays there are 3) So you have to address these separately.

But nothing really weird.

<comment><USER3> You're 100% right but it's very inconvenient to use. For example if you want to copy a buffer to the display you have to track the position and then execute commands to move the cursor to the new region.

Less of a problem now in C but back in the day, Z80 asm / PIC asm it was a PITA.

</comment></comment></comment><comment><USER5> It's amazing that this weird architecture has endured for so many years. These displays continue to be cheap and handy.

<comment><USER6> Most of the programs I've seen do what the author calls "Initialization by Instruction" anyway. Bootstrapping and initialization are notoriously tricky to do in hardware, and a lot of us have been bit by this before. Besides, even a compliant power supply (i.e. one that normally meets the electrical requirements, which aren't all that strenuous, to be honest...) can end up being operated in a non-compliant environment.

The cool thing about these things is that most of them are 99% similar, which has helped with endurance more than anything else. It's a weird architecture, yes, but you can often replace a thirty year-old LCD with a brand new one and it'll work, often without any firmware adjustment. _That_ is hard to beat (and, besides, there's hardly any reason to beat it).

<comment><USER7> interesting, "beat it" was the development name for the drumbeat project, and the lable of the main routine in the original source code. Is it circumstantial that you chose "beat it" in your comment or is there an inside knowledge?

<comment><USER6> It's purely circumstantial :).

</comment></comment></comment></comment><comment><USER8> My favourite el cheapo displays are the SSD1306 OLEDs. They're tiny and work over I2C (or SPI). Cost about $3 from eBay from China. It's a fun weekend job writing your own printf and plotting libraries, trying to figure out the various modes. I2C isn't enough to do real-time refreshing of the entire display, but it's perfectly reasonable to plot sensor readings when you're just updating a few regions. You can also get libraries for the Raspberry Pi and Arduino (via Adafruit).

I remember years ago being quite proud of implementing a software variable- width font (since this wasn't a character display). Quite slow on an AVR, but looked nice.

</comment><comment><USER9> The 8-Bit Guy on Youtube made a great video series on character LCD screens and how to run them.

In the first video he shows how to drive one manually using just switches: [https://www.youtube.com/watch?v=hZRL8luuPb8](https://www.youtube.com/watch?v=hZRL8luuPb8)

In parts 2 and 3 he shows two ways how to drive them with a C64: [https://www.youtube.com/watch?v=vV8FbwobrKY](https://www.youtube.com/watch?v=vV8FbwobrKY) [https://www.youtube.com/watch?v=pQk3XgpuaJ4](https://www.youtube.com/watch?v=pQk3XgpuaJ4)

</comment><comment><USER7> in other words power must turn on and ramp time to operating level must be somewhere between 100 micro seconds and 10 milliseconds. this is accomplished easily with power conditioning between hardware and supply voltage. My first digital project is still operating in niagara falls ontario up on the wall in 2 of the more popular museums. the record fastest drumbeat in the world was held by "some guy" and was around 127 beats per minute. the brains of the project was a microcode 16f84, and 17f84. the 16f drove the display and fed alphnumeric while the 17f counted beats on a piezo electric drum pad and compared to the "record" beat. the skin of the finished project was slick, the inside was a fibreglass bread board. $1500 pricetag at time of release for $150 in parts and some brainwork.

<comment><USER10> "127 beats per minute"

This sounded slow to me, turns out it is

Some guy doing 20 beats per second [https://www.telegraph.co.uk/news/newsvideo/weirdnewsvideo/10...](https://www.telegraph.co.uk/news/newsvideo/weirdnewsvideo/10187844/Worlds- fastest-drummer-sets-record-with-over-20-beats-per-second.html)

Edit: Quoted wrong

<comment><USER7> The device was built in 1997, the record was for single stick drumbeat and ">was> around 127 beats per minute" would be a closer paraphrase. In any event this is about the hitachi lcd display rather than drumming.

</comment></comment></comment><comment><USER11> Certainly clearer than the old HD4470 FAQ was. So its a handy reference if you're coming across these for the first time. Many people I know end up writing one init routine and use it and reuse it again and again and again ...</comment>