We are moving into the quantitative finance industry - <AUTHOR> https://www.fpcomplete.com/business/blog/moving-quantitative-finance-industry/ <comment><USER2> The advantage Haskell has in finance is there are a number of long term success stories to point to.

Standard Chartered traders use an excel to Haskell interface for risk management and trade execution.

S&P Capital IQ uses a Haskell DSL called Ermine for their reporting engine.

Tsuru capital is the largest hedge fund to use Haskell for trading but there many smaller shops like Alpha Heavy Industries.

[http://www.haskell.org/haskellwiki/Haskell_in_industry](http://www.haskell.org/haskellwiki/Haskell_in_industry)

FP Complete repeatedly mentioned Standard Chartered's Excel to Haskell system as something that they would want to see more widely adopted.

</comment><comment><USER3> Matlab, C++, C# and Java rule the roost in the finance world. Anything else is treated with intense suspicion by finance companies. (I was once at a very large financial company that wouldn't approve Python for use internally at all because it was open-source. Let that sink in. We used it anyway of course.)

And yes, R and Python are making real inroads in quant finance, but they still have a small market share. Most of the guys writing code either want MS Office integration (sadly all traders love Excel), raw speed (C/C++/Java), or easy prototyping (Matlab). People don't know Haskell, audit departments don't know Haskell, and Haskell isn't as fast as C++, so this is an uphill climb, but I wish them the best.

If you want to know the state of the art in quant finance, go stare at the horrible over-engineered debacle that is QuantLib and see what kind of programmers we have working in this area.

<comment><USER4> > sadly all traders love Excel

Why do you say 'sadly'? Excel is an incredible tool that other traders can work with, it is sufficiently expressive to run trades and backtests, and the connectors (e.g. Bloomberg) are better than the python equivalent

<comment><USER5> There's a long history of spreadsheet errors and literature on same going back a few decades now.

In a business sim class in college a couple of decades back, I discovered that the Lotus spreadsheets (as I said: a couple of decades back) had a totalling error which double-counted individual row totals in the bottom line (everything was twice as profitable as the spreadsheet indicated).

At an early gig, one of the senior developers instituted a practice of code walkthroughs on projects (only a subset of them). One of these involved, you guessed it, a spreadsheet (we used a number of other development tools for much of our work), in this case Excel. Again, numerous errors which substantively changed the outcome of the analysis. One of the walkthrough leader's observations was that you could replace all of the in-cell coding with a VBA macro making debugging far easier (all the code and data are separated and in one place each).

The particular analyst whose project this was: he insisted to the very end that this "wasn't a program" and he "wasn't a programmer" and that the walkthrough didn't apply to his situation. Despite the errors found and corrections made.

At the time (mid 1990s) the walkthrough lead turned up a paper from a researcher in Hawaii on the topic. I'm not certain it was Raymond Panko, but his 2008 paper (a revise of a 1998 work) discusses the matter in depth:

[http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm](http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm)

</comment></comment></comment><comment><USER6> Having built systems that try to do this in the past, I encourage you to question a few assumptions that many people have about the inefficiencies of this silo'd model.

(1) That quants want to program (or that the business should want them to) in something other than R, Matlap, NumPy, Julia, etc. (2) That the hard part of moving a model into production is translating the model. (3) That the model is the part of the system that will be the main driver of success.

Good Luck!

<comment><USER7> This is very interesting. What actually is the hard part and what drives success, in your experience?

<comment><USER6> I've found that quants do not follow software best practices. They do not produce production ready code and it isn't because they aren't using the right language. It's because they aren't production software developers (and I don't want them to be, I want them out there doing analysis). Further, I've never encountered a model that didn't over simplify operations/execution requirements. They do this so that they don't get bogged down in details when they haven't figured out the big picture yet, and that's a good thing.

What drives success is having a good set of quants who can communicate with production capable software engineers. At the end of the day, the hard part of a quants job is usually finding concepts. Once they are found translating them into something actionable is usually reasonably easy.

</comment></comment></comment><comment><USER8> While I want to cheer on esoteric languages and functional programming, this seems like just more smart people wasting their brains on zero-sum detrimental finance games. At least for them, they'll probably make a lot of money.

<comment><USER9> "zero-sum detrimental finance games"

That depends on the market, doesn't it? They didn't say they were explicitly building systems for Forex, right?

And who are you to tell people what they should "waste their brains on"? A lot of programmers I know in research labs/academia speak condescendingly towards really intelligent SV programmers who "waste their brains" on moving pixels around a screen in order to make people click more ads.

<comment><USER10> Fwiw, that line actually came from someone in the tech industry, though no doubt some academics also like it. The oft-paraphrased quote is from Jeff Hammberbache, an early Facebook employee, who at the time of the comment was at Cloudera: "The best minds of my generation are thinking about how to make people click ads. That sucks."

<comment><USER11> So far, no one seems to have come up with an economic system that's more effective in harnessing the collective skills of the human race to improve the world (on balance) for everyone than the one we have at the moment.

It has the regrettable feature that it strongly incentivizes some very smart people to spend their careers encouraging people to click on advertisements, and some other very smart people to spend their careers arranging for the profits from exploiting subtle equity mispricings to flow to one random set of rich people rather than another. But the net effect is pretty good, or more precisely less depressingly wretched than that of any other system found to date.

(And some of those very smart people get rich by encouraging ad-clicking or exploiting equity mispricings, and then use their money and/or freedom to do neat things from which everyone benefits. Is that such a bad way for things to work?)

<comment><USER10> I guess I have some doubt that the American economic system in particular is a local optimum. Something radically different carries risks, yes. But the American system is a bit of an extreme in its encouragement to do _anything_ that makes a profit, even within the local space of variation of vaguely market-based mixed economies. In Denmark, we have a bit more "managed" economy, perhaps even "socialist" in a certain weak sense (there used to be more of a socialist ethos, alas). The country is a bit less focused on VC returns, big paydays, and "exits", and frowns a bit more on people doing mercenary nonsense for profit. You get paid to go to university, there is extensive arts funding, an industrial/scientific policy, etc., among other things that try to redirect energies elsewhere. And that historical "approximate equality for all, big profits for none, put your energy into something worthwhile" approach to an economy has really not been disastrous, quite the opposite.

<comment><USER11> I didn't actually mean the American system specifically. (I'm in the UK, for what it's worth.) My own preferences are quite leftish and I would prefer the UK to be more like Denmark than it is. But, still, the US seems to be quite effective in producing new technological things, and maybe that's partly the entrepreneurial mercenary culture as well as the mere fact of being a rich country.

Anyway, the "system" I had in mind was the (not necessarily well defined) global one of which the US, the UK and Denmark are all parts.

<comment><USER12> >But, still, the US seems to be quite effective in producing new technological things, and maybe that's partly the entrepreneurial mercenary culture as well as the mere fact of being a rich country.

Speaking as a born USAian, I honestly believe it's more that the USA can and does brain-drain the entire rest of the world. When you actually _raise_ people in an environment of mercenary capitalism, what you mostly get is poor people. When you let social-democratic states across the world raise and educate people, let them fund their research or their early attempts at businesses, and then steal those people when they get successful enough to be an easy bet and put them in a ruthless entrepreneurial environment, _then_ you get a seemingly high concentration of high-talent, high-productivity businesses.

It's kind of like how people outside Israel say we've become a high-tech powerhouse through the discipline of our military training, but actually the Israeli army is one of the world's worst bloated, effort-wasting bureaucracies for every soldier outside a tiny elite.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> IPython + Pandas[0] + (sklearn/cvxopt/etc.) are an amazing combination and as far as I can see gaining share. I would love to work in Haskell but I'm always scared the library support / interactivity won't be there. Pandas has 8600 commits at the time of writing, unassailable?

[0] [http://pandas.pydata.org/](http://pandas.pydata.org/)

<comment><USER14> This stack gets a LOT of use in HFT. (Including us)

Honestly, the three things I'd most love to have are: \- more wrappers, support, documentation on PyMC -- a LOT could be done here and this could replace HUGE amounts of code in all sorts of place \- libraries/models on top of cvxopt \- more polished ipython notebook -> pdf or d3.js html -- I do this a fair amount for auto eod reports etc

And maybe a fourth...a good open source alternative to kx...preferably one that can accept .h5 files.

<comment><USER15> what group are you with? we're working on some relevant stuff

[http://continuum.io/](http://continuum.io/)

I can be reached at firstname.lastname@example.com if you want to chat about it

</comment></comment></comment><comment><USER16> I would like to read details about the model -> production code that the IAP product uses.

I've been developing an interest in statistical modeling and moving those models to production code (and of course, quantitative finance is an "obvious" place where this happens). But I find, even in the statistical genomics world, that the default process still seems to be:

      (1) specialized tools for data cleaning and initial crunching (maybe hadoop, maybe HPC clusters
      (2) consumption of data from (1) in R or Stata/SAS for model generation
      (3) only vague, research-y things where the model from (2) goes to production.

The vague part of (3) is probably just due to my simply not knowing what people are doing with the generated models in (2).

Specifically regarding quantitative finance, it would seem that trumpeting your implementation programming language would mainly be met with blank stares, Jane Street excepted . . .

</comment><comment><USER17> Growing up and moving into the finance industry? Excellent! Please fix the typo in the 'FP Haskell Center (TM) Overview' section: "... The personal edition aslo includes Emacs support ..."

<comment><USER18> Thank you for pointing that out.

</comment></comment><comment><USER19> I think quantitative finance is interesting, but for personal purposes I'd really only want to trade once a month or so, as opposed to multiple times a day. I'm not sure what kind of software libraries/languages are suited for that kind of approach, when everything seems tuned for HFT.

<comment><USER20> For that kind, you don't really need any specific software. You can do it in Ruby/Python/Haskell/Whatever. As long as you can communicate with an API (Yahoo Finance to download the data for example and one broker that allows you API access to issue orders) any language will do. You can run your software once a month or week, analyse the data and issue the orders. If you are keen, you can even use Google News/NLP/Sentiment Analysis in your model, again, in any languages you want.

Take a look at: quantstart.com He has some tutorials with Python to do so, and he is releasing a book (hopefully soon) that should give you a good overview of it all. Also, I recommend you read Options, Futures and Other Derivatives to understand how most of this financial instruments work. There is a lot of good information there.

<comment><USER19> Thank you - that is very good information. I have done some perl scripting using "Finance::Quote" and "Finance::QuoteHist" but I guess I have been looking for the next step up. Particularly historical financial statement information, like EPS and Sales data quarterly history. Historical fundamentals as a data feed. I don't know where to find that. I'll check quantstart and see what they offer.

</comment></comment></comment><comment><USER21> Is there a difference between quantitative finance and HFT? I imagine it's a square-rectangle relationship.

I'm a big fan of new tools to make mathematical models for traditional investing, but I am fairly against the idea and practice of HFT.

<comment><USER11> If you hope to make money from trading (beyond the quite respectable gains you can get just from buying index funds or whatever), you basically have two ways to do it. (1) Make better predictions (or better adjustments for risk, or better hedging of one asset against another, etc.; these are all closely related) than others. (2) Buy and sell without any attempt at predicting the future; be willing to take the other side of any trade anyone wants to make, in return for which you get to buy a little low and sell a little high.

For #1 you need quantitative finance. #2 is the activity known as "market making" and HFT is what you get when you automate it and then let the people doing it compete. The algorithms in HFT are pretty simple-minded; the goal is to offer as thin a spread between buying and selling prices as you can while still making a profit, and to offer it faster (when someone comes looking to trade) than anyone else. The latter is genuinely useful when it's the difference between (say) 5 minutes and 5 seconds. Unfortunately the same incentives that make it worth while for high-frequency traders to offer sub- second response times then make it worth while for them to keep chasing faster and faster times, until the most important asset a HFT shop has is a bunch of computers positioned slightly closer to a big exchange than anyone else's.

There's not much of what people mostly mean by "quantitative finance" in a typical HFT system, I think.

</comment></comment><comment><USER22> this is not a good industry to move into

</comment><comment><USER23> Can someone help me understand how hedge funds, trading desks use this type of software?

<comment><USER24> Haskell has been used to model financial contracts by a few firms with an eye towards type-level correctness guaranteed by the compiler (that you cannot get with "mundane" type systems found in C++ / C / Java / etc...) That, coupled with Haskell's speed, concurrency features, and other amazing features makes it an attractive platform.

Alpha Heavy Industries is a small(er) SV based firm using Haskell a lot.

<comment><USER25> Hi ixmatus,

Can you give a more specific example? Are you saying that instead of in Java/C++ where you have:

GenericSecurity > GenericOption > EuropeanOption, BarrierOption, AmericanOption

You can have more mutable types/classes at run-time and more injections instead of the concrete ones defined at compiled time?

Also, can you give any concurrency examples in terms of concurrency features? Is it similar to Actor model in Scala? Or based more on concurrent data structures as in java.util.concurrent.*?

<comment><USER26> Take a look at [1] for details on the contract language they built. Instead of modeling things in a taxonomy, they build the logic of contracts up from primitives using a combinator library.

Concurrency in Haskell is a big thing. At the lowest level, purity means there's a lot of opportunity for parallelization. Atop that Haskell has a really great green threads system and new GHC has a very, very performant IO manager for running them. It's GC'd so you do have thread-local pauses and they're not as nice as Erlang's actor-local GC. Atop that you've got a nice channel system, the best implementation of Software Transactional Memory around, and neat new libraries like LVish for doing eventual consistency in a very reasonable fashion.

[1] [http://research.microsoft.com/en- us/um/people/simonpj/Papers...](http://research.microsoft.com/en- us/um/people/simonpj/Papers/financial-contracts/contracts-icfp.htm)

<comment><USER25> Thanks tel for the helpful example, I scanned through [1] briefly and will be attempting to grok the details later. But very interesting paper on using Haskell combinators as opposed to the ugly Java single-inheritance model to make up more and more complicated securities piecewise. Tbh, I'm quite envious of using functional languages and will use the examples to try to learn it (since I'm familiar with the domain area of financial contracts only in imperative lang though).

I also like to learn concurrency in Haskell and don't know a thing about it (currently, I'm trying to go over Clojure concurrency features). So what you have mentioned regarding the LVish framework and Erlang's actor-local GC, green threading will give me a good starting point to poke around. Thanks again for your note!

<comment><USER26> Simon Marlow wrote a book recently on Concurrency and Parallelism in Haskell [1]. It's a good read for learning more about this kind of stuff as well.

[1][http://chimera.labs.oreilly.com/books/1230000000929](http://chimera.labs.oreilly.com/books/1230000000929)</comment></comment></comment></comment></comment></comment>


LTE Has Slowed by 50% in the US This Year - <AUTHOR> http://twinprime.com/lte-has-slowed-by-50-in-the-us/ <comment><USER2> A quick reminder that 4G != LTE. The 4G specification requires a minimum speed [1] so LTE was launched to avoid exactly this minimum. It seems that the companies did it right by launching LTE instead of 4G as they could have lost their 4G status, while now they could drop as low as 3G speeds and still be called LTE (which is ironic on itself).

This wasn't commented at all in the article, using 4G and LTE interchangeably which I find troubling.

[1] 100Mbit/s for high-speed transit areas and 1GBit/s for low-speed transit areas, [https://en.wikipedia.org/wiki/4G#Technical_understanding](https://en.wikipedia.org/wiki/4G#Technical_understanding)

<comment><USER3> My go-to reference on the situation is [https://blogs.oracle.com/ksplice/entry/essay_3g_and_me](https://blogs.oracle.com/ksplice/entry/essay_3g_and_me).

Like Keith says, more important than whether you have 3G, 4G, or LTE is:

""How much spectrum has the carrier licensed in my city, and how much is allocated to this kind of modulation?

How many other people am I sharing the local tower with? In other words, how big is my cell, and how many towers has the carrier built or contracted with?

How much throughput are my cellmates trying to consume?

How much throughput has the carrier built in its back-end network connecting to the tower?

You might notice that all of these meat-and-potatoes factors involve the carrier spending money, and they all involve gradual improvement in behind- the-scenes infrastructure that's hard to get customers excited. Persuading you to buy a new cell phone with a sophisticated modem and sign up for a two-year contract is a different story. So they don't sell you something measurable where they could be held accountable; they sell how sweet it feels to be using a sophisticated radio modem protocol to talk to them.

…

If the carrier sold you "384 kbps Internet access anywhere in the coverage area, outdoors," that would be something you could hold them accountable for. The carrier might even have to put a brake on signing up new customers until it could build new towers or license more spectrum for everybody to share, if it made that guarantee.""

<comment><USER4> I don't buy it. My carrier (AT&T) is almost certainly rate-limiting bandwidth to phones in my area, doing deeper inspection on their transparent proxies, or both.

In 2014, as measured by the Ookla app on an iPhone 6, I was routinely 50/17 and 60/20 speedtest to various servers in the region during business hours at home and work. I know this because I took a screenshot in disbelief.

Today, service varies from 1.5/1 to 10/3 during the day, and 10-15/3 at 5AM. I don't buy that usage has increased that much.

<comment><USER5> Which market?

In the case of the NYC market, AT&T had the worst spectrum planning of any major carrier. They are suffering because they chose to rely on low-band spectrum rather than densifying their network, and are now trying to band-aid the solution by using carrier aggregation of oddball downlink bands. It doesn't change the core problem of having too many people on each sector.

The reason they have to stake 2G dead this early is because they are spectrum starved and already only running it in HSPA guard bands. They need every resource they can get since they haven't been spending money at throwing towers in every possible place in the city for years. They've been using it to buy a satellite company, a Mexican carrier, and WCS spectrum that's worthless without densification. Priorities.

<comment> at-fates-hands >> In the case of the NYC market, AT&T had the worst spectrum planning of any major carrier.

They've been having a hard time since the late 1990's when they introduced the "one rate" plans and basically oversold their coverage area in NYC.

I distinctly remembering long articles talking about how the networks were so saturated, dealers were still activating phones on their network knowing the customers wouldn't get a signal and would have zero reception in NYC, even after being told by several courts to stop signing up customers.

Here is the text of the class action lawsuit that made it all the way the NYC Supreme Court: [http://www.whafh.com/modules/case/docs/2556_cid_3_AT&T%20Cel...](http://www.whafh.com/modules/case/docs/2556_cid_3_AT&T%20Cellular.PDF)

EDIT: some of the articles I alluded to are listed in the class action starting on page 9.

<comment><USER6> "all the way the NYC Supreme Court"

In New York, the "Supreme Court" is the trial-level court. Above that is the "Supreme Court, Appellate Division" and above that is the "Court of Appeals".

</comment></comment></comment></comment></comment></comment><comment><USER7> Traditionally the way that carriers deal with bandwidth congestion is to wait until people start screaming (and networks start breaking) before they invest in innovation. There are a bunch of technologies that could ease congestion and deliver significantly better wireless performance but they would require an investment that doesn't make sense for carriers (it's not like carriers can extract more money from you if the network is better...).

That is to say, subscriber ARPU does not increase with network investment, so why invest in the network until it becomes a drag on subscriber growth?

Source: I was a manager at ATT when the network in San Francisco basically died with the introduction of the iPhone 3G. It stayed that way until ATT added new towers and upgraded the software on the towers for better spectrum utilization.

</comment><comment><USER8> Living in SF, I haven't really noticed this, which the article bears out. I was actually just commenting in one of our Slack channels at $work that it's still kinda weird to me that the internets are, on average, at least 4x faster (throughput, not latency) on my phone vs my home internet service (bonded DSL).

EDIT: Out of curiosity, I just checked again, first on LTE and then on WiFi:

      LTE:   30ms ping  64mbit/s down  23mbit/s up
      WiFi:  24ms ping  6mbit/s down   2mbit/s up

<comment><USER9> DSL sucks. I'm sure our local ATT has lost the vast majority of it's DSL users in the past few years because of rollout problems. Their fast connection is around 20mbit/s download and around 2mbit/s up. Our cable company is offering 50mbit/s down 5mbit/s up for the same price. The cable company is also offering 100mbit, 200mbit, 500mbit, and 1gbit connections too. On top of that they offer phone service at half the price.

I think ATT is trying to go out of business here.

<comment><USER10> ATT also has data caps (now 1TB and $10 per 150GB), compared with the cable companies (in my area) and google which don't. That doesn't seem to stop about 1/2 of my neighbors from using them though (you can usually tell those people because they leave the default ATT SSIDs on their wifi APs).

Once a year or so, it seems they hire some kids to come through the neighborhood selling service door to door. Every time I ask them, do you still have caps? Usually they stare at me blankly, but I then politely tell them I'm not even going to consider their service as long as I'm going to have to worry about a internet bill that could be larger in a single month than what I pay all year for my cable subscription (which literally got 10x better within a couple months of google announcing they were going to target my city).

<comment><USER11> Comcast just implemented 1TB bandwidth caps in most of the U.S., including where I am, starting on Nov 1.

</comment></comment></comment></comment><comment><USER12> Mobile networks in a way are seemingly destined to be victims of their own success. I find that no matter what mobile bandwidth I'm getting, I can always use more. For example, considering adding a dedicated hotspot to my existing plan, just for my car. The better it works, the more I want to use it. And by "it", we are talking about a fixed physical infrastructure, otherwise known as a capital investment.

<comment><USER13> If the US made any sense, this would be a public works infrastructure project rather than private enterprise. The tower density and spectrum that will be needed for effective substitution of traditional wired internet services with wireless towers will be prohibitive for any reasonable company to simply invest their way into, and big teleco has proven historically to love charging more for the same now than competing to make the service better once it starts looking expensive to keep up.

<comment><USER14> > If the US made any sense, this would be a public works infrastructure > project rather than private enterprise.

No thank you. My Verizon plan is expensive, but it works pretty damn well, unlike most of the public services here. My wife and I took Amtrak every day between Wilmington-Baltimore and Baltimore-DC for about two years. It was regularly late (often very late). Trains broke down in-between Wilmington and Baltimore regularly, and my wife would be stuck in the train for hours waiting for a replacement engine to arrive. Many of the tunnels along the route are decades past their design life.

Before that, I lived in Chicago, where ancient lead water pipes poison kids. Before that I lived in Atlanta, where ancient sewer systems dump untreated sewage into the river whenever it rains. I also lived in Wilmington, DE, where bus drivers would just randomly decide to end their route 15-30 minutes early. Now I live in D.C., and even though I'm within 0.3 miles of a metro station both at work and at home, I take Uber because Metro trains keep breaking down and/or catching on fire.

I'm not a libertarian nutjob, but I don't want the government running my cell service. Our roads are awful (I just came back from Munich), our transit is awful, etc. There are a tiny handful of competent public infrastructure organizations in the country (e.g. New York's water system, Metro North), but most are a disaster. Verizon may be evil, but unlike say WMATA it doesn't have to regularly shut down major sections of its network because it spent decades neglecting its infrastructure.

<comment><USER15> Amtrak does not work not because it's a public service. Many railways in Europe are public and the work great.

<comment><USER14> Many public services in Europe work great. But I'm talking about the US.

</comment></comment></comment></comment></comment><comment><USER16> Excellent timing considering the HN thread [1] about T-Mobile being fined for network management.

"There is no doubt that the US will need to set up the infrastructure to keep pace with the rapid changes in usage and content expected in the future. Like any instance of supply and demand, we will continue to see a give and take in this market. As operators catch up to the current demand and LTE becomes faster, users will opt to use it over others – thus creating greater demand, supply scarcity, and decreased performance. At which point the cycle will begin again."

TL;DR Expect more network management in the future due to heavy demand of a constrained resource.

[1] [https://news.ycombinator.com/item?id=12745255](https://news.ycombinator.com/item?id=12745255)

<comment><USER17> *fined for misleading customers about network management

<comment><USER16> Your average user doesn't care, as long as they're not charged extra for exceeding their quota.

<comment><USER18> The quotas on wireless ISPs are already very low and people exceed them very regularly. What can be done to actually improve the situation? What choice do consumers have?

<comment><USER19> Voting for representatives that actually represent people and not corporations.

<comment><USER20> Which means voting for people supporting election financing reform.

<comment><USER19> I had this thought earlier: how about just electing people who don't give in to corporate lobbying. Keep corporate donations legal, I don't care, just actually look at the disclosure forms of where their money is coming from and don't vote for them if you disagree with conflicts of interest. Or if they have PACs that aren't transparent, don't vote for them.

People are unable to make their voting decisions outside of the TV commercials and news articles they read, so I don't have any real hope for this tactic.

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> I think that control of content is one of the major reasons for this. If users were more able to readily (and for zero cost to them) cache content when connected to local networks then we would see less content transferred over 'higher cost' networks.

Of course streaming services (I'm thinking more of Twitch than Netflix) for live content production are 'rather difficult to cache' in their prime viewing time.

<comment><USER22> The thing most difficult to cache is the thing that all the providers most want: advertising.

If you removed the advertising from the web, caching gets really easy except for something like Twitch.

</comment></comment><comment><USER23> Anecdotally, I've been incredibly disappointed in LTE speeds for NYC lately. It's almost a joke how slow LTE is. Browsing the web feels like using ancient DSL.

There's definitely a material difference between providers. I'm on Verizon now, but T-Mobile and AT&T were both _much_ better when I had them (and I'll be switching back as soon as I can).

<comment><USER24> Last Friday I couldn't even get a page to load on my iPhone with "full bars" on Verizon. Where does all the money go towards? Not fios, that's for sure (Verizon defaulted on a deal with the city to roll out fiber to all households[0]).

[0][http://arstechnica.com/tech-policy/2016/09/nyc-threatens- to-...](http://arstechnica.com/tech-policy/2016/09/nyc-threatens-to-sue- verizon-over-fios-shortfalls/)

<comment><USER23> Since joining Verizon I've realized that bars are more or less meaningless. There are many times when I can't even make a phone call with "full bars."

Sadly, I've also been very disappointed with FiOS speeds lately.

<comment><USER25> Verizon's claims are pure BS. When I did some work for a company called CrunchButton, I figured out (using my fiance's phone) that Verizon had towers that weren't connected to anything. They were just there to provide you with 'full signal' (your phone never connected to these towers) so they could claim coverage in that area. You couldn't make a phone call from that area on the Verizon network. Meanwhile, my T-Mobile phone showed three bars and worked flawlessly.

Don't trust Verizon. They're a sham company.

</comment></comment></comment></comment><comment><USER26> I work at a quite large telecom company and one of the most repeated topics is that mobile traffic has been doubling every year for the last years. The trend is going to keep growing even more.

The nature of mobile networks is being a shared resource, as opposed to traditional DSL or Fiber which have a generally more dedicated bandwith.

This obviously implies quite a challenge for telcos, as expanding the network comes at a massive cost.

</comment><comment><USER27> > With the onset of functionality like 4K video streaming, this number is set > to increase to as much as 22GB/month.

Oh god why would anyone want to watch 4K on a cellphone. Go for 60fps instead, you'll get _some_ value out of that on your 5" screen.

<comment><USER28> That's what I thought too. 4K doesn't make any sense on that small a screen.

I think streaming VR content is what is going to contribute to a much larger data usage.

</comment></comment><comment><USER29> I've noticed it big time in the northeast. I live on the road and work via a Verizon connection. Over the last 6 months over 7 or 8 locations I get a full Verizon signal (with a booster) and very low speeds compared to a year ago. And speeds increasing at off peak times (it's fast in the middle of the night) point to overloaded towers.

I know people love to hate on cell companies but it must be hell to try and keep up with demand that changes so rapidly.

<comment><USER30> I suspect it's securing the rights to build towers, and the rights to install fiber to those towers. Actually building the thing shouldn't be much of a big deal. getting a permit to dig up a mile of street, that sounds like a pain.

</comment></comment><comment><USER13> Hey look, another example of why trying to sell the rights to light sucks.

We are going to see AT&T / Verizon / etc go the way of Comcast soon. The cost to improve service will be high enough and the overhead of trying to get more spectrum when they hit physical limits annoying enough and their revenues large enough and the demand insane enough they are going to constantly try to buy each other out than actually invest anything until we have one big corrupt mess like Comcast is for physical wire service.

It seems like the inevitable outcome of having infrastructure services that should be public utilities instead be provided by private companies competing over who can exploit the state to get more unfair advantage, be it land access rights for wire carriers or FCC bribing for spectrum.

<comment><USER31> Soon? They're already at it

[https://en.wikipedia.org/wiki/Attempted_purchase_of_T- Mobile...](https://en.wikipedia.org/wiki/Attempted_purchase_of_T- Mobile_USA_by_AT%26T)

[http://www.bloomberg.com/news/articles/2016-08-17/sprint- own...](http://www.bloomberg.com/news/articles/2016-08-17/sprint-owner-is- said-to-still-hold-out-hope-for-a-t-mobile-deal)

</comment></comment><comment><USER32> "From early 2015 to early 2016 there was a 56% increase in data usage according to Cisco."

And there you see the problem with data caps (common among mobile carriers but swiftly coming to cable). We have plenty of bandwidth today and are squeezed for more money in a few years.

<comment><USER29> We don't have plenty of mobile bandwidth though. 56% increase resulted in 50% degradation of speed. What happens next year to speeds with continued growth in usage?

<comment><USER32> Good point that we need to think about. I'm more worried about caps in landlines. A similar problem exists there, however. Here's a good article on it.

[https://www.nngroup.com/articles/law-of- bandwidth/](https://www.nngroup.com/articles/law-of-bandwidth/)

</comment></comment></comment><comment><USER33> What I don't get is: why can't I as an app developer specify what kind of data transfer rate I need and have the phone choose which connection type it needs depending on the currently running software?

Like, if I'm doing push notifications or IRC, I'd tell the phone that I only need 2G speeds, and the phone only connects to something faster than 2G if I open the web browser.

Right now, my phone books into LTE as soon as it's in coverage mode - and it stays there, eating power like nothing else, instead of dropping into the relatively quiet and strong-signal 2G/3G/HSxPA cells and saving power.

<comment><USER34> Your phone is actually far more battery-efficient when it's able to only use LTE (i.e., if your carrier supports Voice over LTE). It's having to have both radios on (one for voice and one for data) that is hard on the battery.

<comment><USER5> Not exactly. When it's on LTE and doesn't support voLTE, the signaling is used here to search, connect, and handoff to HSPA or GSM (or CDMA). It increases the call setup time, but it isn't actually a major factor in battery life.

GSM will win most in battery efficiency due to it being a TDMA based standard that pulses the radio off and on. But LTE has improved a long way since the early days.

<comment><USER35> UMTS and HSPA were fine on battery life and they were CDMA technologies. The big difference is the extra work basebands have to do to handle new modulation technologies as well as the extra CPU time it takes to handle more data. More efficient CMOS processes, baseband designs as well as ARM core designs have been the main cause behind power efficiency in LTE-enabled devices.

<comment><USER5> Maybe you remember a different history than I do. WCDMA/HSPA was poorly designed early on to tackle smartphones and had terrible battery life and performance.

To summarize pre-2012 HSPA:

\- Basically, HSPA phones until around 2011 or so stayed in a higher power state much longer than they should have.

\- People got pissy about having crap battery life.

\- Manufacturers responded by doing proprietary hacks to send modem into lower power state.

\- Cell networks essentially got DDOS'd as phones sent nonstop signaling to negotiate different power states.

\- Phones now not only got poor battery life, but also barely operated on the now congested network.. remember the at&t iphone monopoly days before 2012 in major cities, it was a bad time.

3GPP Rel8 came about to fix the issue for good by moving power state control to the towers. Here's an article explaining the technicals of it: [http://blog.3g4g.co.uk/2010/10/fast-dormancy-in- release-8.ht...](http://blog.3g4g.co.uk/2010/10/fast-dormancy-in- release-8.html) Easier read: [http://www.3glteinfo.com/fast-dormancy- in-3gpp/](http://www.3glteinfo.com/fast-dormancy-in-3gpp/)

Would agree though that process size and baseband optimization is helping the LTE situation. Differences are very small and Apple actually quotes better LTE life on the SE than 3G. LTE really came into its own in just the past 2 years.

</comment></comment></comment></comment></comment><comment><USER36> I remember getting on VZW LTE reasonably early, with the HTC Thunderbolt (don't even get me started; that device was trash) and I consistently got 60-80Mb down. Now I'm the same location, same carrier, infinitely faster LTE modem, I get maybe 5-10Mb if I'm lucky. Such a shame, could've been transformative.

<comment><USER37> I just tested my T-Mobile LTE using Ookla. I'm in suburban Boston. The local time was about 00:30.

Results: 69.39 down, 20.70 up, 36 ms ping (to Norwood). The test used about 170 megabytes of my 3-gigabyte monthly quota.

</comment></comment><comment><USER38> I went to a wedding in upstate New York last weekend, and I on the drive up, there were some areas where I had no 4G (or LTE, or whatever my phone gets), but anywhere that it _was_ available, it was substantially faster than what I'm used to from the densely-populated areas where I spend most of my time. I assume this was because there were simply fewer people sharing approximately the same bandwidth.

<comment><USER39> Many people mistake the Gb/s numbers for these modem protocols as Gb/s per subscriber, when in reality it's more so the total throughput of a tower modem shared among subscribers.

Outrage of course, ensues.

</comment></comment><comment><USER40> This is an interesting read, but the comparisons to other countries/regions omits any mention of population density. It's much easier to roll out public utilities in dense areas than sparsely populated ones, and western Europe and Korea are more densely populated than the US.

Not that this excuses the big drop in speeds, but it makes the comparative piece a bit less relevant/accurate.

<comment><USER41> More population density means smaller cells, more towers, more infrastructure, higher level of wired network throughput surface density required, more money.

It might be economically unfeasible to service remote areas, but covering a given area is much harder as population density increases, not less hard.

Yet other countries can do while charging the consumer less.

<comment><USER40> I agree that there are different challenges to serving high-density areas, but I don't agree that these challenges are necessarily harder than creating a far-flung network. These articles [1] [2] indicate that for wired high-speed internet, population density is a good thing for cost savings.

To the extent that high-speed wired internet is part of the infrastructure needed for high-speed cellular networks, the cost benefit would similarly favor dense populations.

Tower density would have to be higher, of course, and interference could be an issue, but I've not seen anything indicating that these challenges outweigh the cost savings from having a dense population. I'd be interested in seeing an analysis!

1: [http://www.fool.com/investing/general/2014/11/30/why-cant- th...](http://www.fool.com/investing/general/2014/11/30/why-cant-the-us-have- south-koreas-blazing-fast-int.aspx)

2: [http://www.cnn.com/2010/TECH/03/31/broadband.south.korea/](http://www.cnn.com/2010/TECH/03/31/broadband.south.korea/)

</comment></comment></comment><comment><USER42> Meanwhile here in Tokyo my mobile data connection is faster than the wifi running off of my 1 Gb/s internet connection...

</comment><comment><USER43> I switched to tmobile $30 plan a year ago and regularly got 25mbps around Manhattan, now days I get around 10, often 5.

<comment><USER44> Yeah, their bandwidth decreased noticeably.

<comment><USER35> With their massive subscriber growth I'm not surprised, it seems a lot of the network investment they've been pushing has been extending coverage and in- building service with their Band 12 licensing. With them looking at deploying a "5G" network by 2020 I'm not sure if there are plans to add new cells right now, they have plenty of backhaul but the physics of shared RF spectrum is biting them now that they've had so many consecutive quarters of net subscriber adds.

Here's hoping they do invest in some more cells for my dense metro bretheren, because I enjoy 60Mbps at least day-to-day here in Boise :/

</comment></comment></comment><comment><USER45> 22gb per month expected with 4K? Lawl I was doing ~40gb per month when I first got an iPhone 5s on att. Good times.

<comment><USER46> Thanks for ruining unlimited data.

<comment><USER47> There is no purpose of marketing unlimited data if it can get "ruined" by people who use lots of data.

Anyway, why do you need unlimited data if you don't use a lot of data?

</comment></comment></comment><comment><USER48> Des the actual report cover whether there are any differences across carriers? I know in the 3G era there used to be fairly significant variations for the companies which installed newer base stations without upgrading their back- haul capacity to match.

</comment><comment><USER49> Just did a test on my iPhone 7 showing 4G over EE in the UK... 18 Mbps down / 1 Mbps up

</comment><comment><USER50> I've bet pretty big on this development (and its continuation) by building [http://www.anyfinetworks.com](http://www.anyfinetworks.com). Gonna be very interesting how it plays out! :P

</comment><comment><USER51> Yes the more people that use it slower it goes since people have to share the same bandwidth. However given all the datacaps the faster the speed the faster you hit the datacap so I guess you can look at the positive side.

</comment><comment><USER52> Oh yeah! I was visiting NYC from Canada and I kept complaining to my wife that the LTE speeds were so slow in the city. I just couldn't understand it!

<comment><USER53> Downtown Montreal here, speed right now: 83 mbit/s down 13 mbit/s up

Quite good, almost as fast as my home connection.

</comment></comment><comment><USER25> "Network speeds are not what they advertise or what you see in the Bay Area"

So why are the companies in San Francisco not getting sued for false advertising?

<comment><USER54> This is a comment directly from the author to his technical audience. Worded awkwardly and combining two thoughts, he is saying, just because your app works well in SF, does not mean it works well everywhere.

</comment></comment><comment><USER55> It seems that the companies did it right by launching LTE instead of 4G as they could have lost their 4G status

</comment><comment><USER11> I have Sprint LTE in Denver and the latency and bandwidth are horrible. I often get 1mbps with really high latency.

<comment><USER56> Have they deployed band 41 in the area yet? I see band 26 being saturated more then band 25, but they both are slow at times.

</comment></comment><comment><USER57> > Verizon has the broadest LTE coverage at 95.3%, followed by T-Mobile with > 91.7%.

higher than in Germany, great!

</comment><comment><USER58> "Kill the Snapchat"

</comment><comment><USER59> So as more people start using LTE, 3G becomes faster?

</comment><comment><USER60> gimme a good ol hard line</comment>


The Throughput Problem: Recharging Electric Cars Requires the Patience of Job - <AUTHOR> https://spectator.org/the-throughput-problem-recharging-electric-cars-requires-the-patience-of-job/ <comment><USER3> Article misses out that in all but the smallest/tightest parking lots (which I guess are more common in tighter downtown areas), gas stations typically have additional parking already that could also be converted to charging stations. Article also brings up the specter of extra carbon emissions for extra charging infrastructure, but doesn't provide even a basic analysis.

There are certainly some logistical issues that electrical has to work out. But this is straight up a fear piece. Yes, gas is transportable by hand if required, but I bet most North American drivers (or at least urban ones which this piece is targetting) just go with roadside assistance anyways, so the charger will come to them.

And finally, with the potential of charging at home/work (which I know can't include everyone... but I think can cover a reasonable percentage of people), you don't NEED to charge up even to 80% all the time. Needing a full charge all the time is a hold over of gas mentality and logistics.

The one bit that is reasonable here and noting that our current laws probably need a tune up in recognition of the changing nature of driving.

<comment><USER4> Treating charging like we treat fuelling is the problem. The reason we have gas stations is because we have to store and dispense the fuel safely. We don't have a safe, effective system to transport gasoline to all of our homes and offices. Natural gas cars would be one option, with "pumps" at our homes to fill up our cars, but gasoline is always going to be in underground tanks at a filling station.

Electricity is easily and safely delivered to our homes and offices and indeed, most EV owners probably do the majority of their charging at their own homes.

The issue of EV charging is actually tied to the range of the cars. If you get the range to where a car can be driven longer than the driver can safely drive (say 16-18 hours) then the time spent charging is basically moot...you can charge while the driver sleeps. Hotels become a logical spot for chargers.

<comment><USER5> _most EV owners probably do the majority of their charging at their own homes_

Owning a house is pretty much a prerequisite of electric cars for personal use in the US. 100 million Americans live in rental housing. [https://www.citylab.com/life/2018/08/who-rents-their-home- he...](https://www.citylab.com/life/2018/08/who-rents-their-home-heres-what- the-data-says/566933/)

<comment><USER6> In cold areas, every rental unit's parking spot comes with a power outlet so that you can plug in your car's block heater. So it's possible.

<comment><USER7> I've lived in all types of rental housing across Michigan, and have never seen this. I don't think it covers even a small fraction of that 100 million.

<comment><USER6> I'm talking about places where -40 is common. And I'm not saying that many of the 100 million have block heater plugs, I'm saying that they could -- the cold places are a proof of viability.

</comment></comment></comment></comment></comment></comment><comment><USER8> Most electric cars won't be charged at fast chargers most of the time. Because unlike fossil cars you can refuel them pretty much anywhere where there is electricity. At first this is only true for people with garages (or employers with a garage), but eventually most parking spots will have a slow charger installed. Since the typical car is parked for about 23h a day, charging time becomes a non issue as soon as charger availability is good enough. Fast charging is really only necessary for long roadtrips that exceed whatever range the car has.

<comment><USER9> As someone living in a very old and rustic street, I don't see my municipality placing an aesthetically unpleasing charging point every 6 meters. We need better solutions than what we have now. Induction charging, connection points underneath the car, pantograph.

<comment><USER10> > _I don 't see my municipality placing an aesthetically unpleasing charging > point every 6 meters._

I'm sure people used to say the same thing about fire hydrants, above ground electricity poles and wires, and fibre hanging from utility poles.

I think you're underestimating what happens when there is a genuine need for a thing.

<comment><USER11> I think you're underestimating the inertia of deploying beefier electrical grids with even more charging points, and the nuances of billing and metering.

It isn't as easy as just making an outlet or inductive charger every 6m. That infrastructure has to be owned, installed, upkept, maintained, and subsidized by someone. Unless you think that all that power grid interfacing is just going to be paid for by someone else.

The flippant optimism that things will all just happen and ignoring of the potential for underlying complications beyond those immediately apparent is incredibly grating to those who have to actually trouble themselves with working through them. The idea of a single charging point per 6m doesn't even account for the sudden logistic complexity where the entire extended family all piles into the place and realizes that oops, we all have to charge here, but the local node is already saturated most of the time by locals because the engineers didn't foresee the need to provision for that type of surge in demand.

In comparison, gasoline dispensing is a relatively straight forward affair that doesn't put any excessive new loading on already heavily loaded infrastructure systems responsible for running everything else in our lives in the same way battery charging does.

Unlike software, settling for "good enough" isn't trivially solved by an OTA update. Hell, software isn't always that great about that either once the level of safety-criticality gets high-enough. The joke that is self-driving system development aside.

<comment><USER10> I understand that it's going to be very difficult, and it's going to take years, but that's no reason to not do it.

Gasoline dispensing is extremely complicated - what you really mean is that the complexity is just hidden from you and has been optimized on for decades.

Next time you fill your car with ~15 gallons (60L), have a think about how many gallons of diesel must have been burnt to get that gas you're pumping. Have a think about all the machinery involved in making it, transporting it and then you pumping it. Trucks, oil tankers, more trucks, pumps, etc.

Have a think about how differently we would think if we had to physically carry our own 15 gallons of carcinogenic explosive liquid every time we wanted to enable us to drive ~350 (550km) miles.

The system we have works very well, but it's terrible in every way.

<comment><USER11> I have put quite a lot of thought into that in fact It's a bit of a labor of love to be quite honest. I call it Project Regression,and I've been spending many of my adult years filling out my understandings of the technologies and infrastructures that make modern life possible, why they were developed, why in the order they were, and what would need to be retained and elucidated to a human being to allow that development to be able to bootstrap from nothing within a lifetime.

And yes, I get annoyed every time someone ends up trying to pull a piece of that structure out without making clear they've thought through _all_ the consequences. Something I'm not confident many do, but I've spent my life doing, because I've not run into anyone else who could be bothered to.

My very existence as a thinking, contributing member of society is predicated on the smooth operation of modern infrastructure, so I do get rather aggressive when people start advocating for sweeping change without showing that they've done all the work. Unrealistic expectations on the rate of infrastructure upgrades and propogation gets us nowhere.

I've not even got a financial stake in any company in particular's outcome; and I've been sitting through saga after saga of waste, moral grandstanding, outright lies, negligent corporate behavior, and a complete bloody breakdown in any semblance of sanity in the world as I recognize it.

I wish I had your optimism; or was still naive enough to be able to stoke the fires of my own. This bloody year has just bloody obliterated it though.

Ya know. I'm sorry. Forget I said anything. I'm in a bit of a bad headspace at the moment; and I just don't seem like I can keep things coherent enough to meaningfully contribute anymore right now. Ended up rewriting this about 5 times, and still not able to articulate anything I'm really satisfied with.

<comment><USER10> Don't sweat it, and thanks for the reply.

I know exactly how you feel, and I think I've just 'given up' and gone the other way. I try to accept that our lives will have to get less convenient, and the economy will have to take a bit of a hit as we move to things that are better for us, and better for the planet.

So we'll take a couple of steps backwards in order to take many forwards, and I'm OK with that.

I've also spent a lot of time in Latin America and Africa, and I hope that they can just go straight to the 'right' solutions because they are not so entrenched as we are with what we already have.

Who knows though, right. Certainly nothing is perfect.

I hope you have a good day, I'd buy you a coffee/beer if I could.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Somehow this article misses the fact that electric cars are charged every day when parked at home. In the typical scenario of a car used to get into the city and back, it will not need to ever hook up anywhere in the city and will not run out of charge for the day.

When the article in the end complains that it will waste so much time I just wonder how the daily hookup at home compares to the weekly gas station visit. I'd say it pretty much evens out.

<comment><USER13> Doesn't this assume that everyone owns a house? How do you propose to do this in an apartment building? Sometimes you don't even have enough parking for an apartment building and need to park elsewhere. That sounds to me like charging would be rather difficult at home. We're also not talking about an insignificant amount of people - 42% of Europeans live in an apartment. In some countries it's over 60%.[0]

[0] [https://ec.europa.eu/eurostat/statistics- explained/index.php...](https://ec.europa.eu/eurostat/statistics- explained/index.php/Housing_statistics#Type_of_dwelling)

<comment><USER12> Apartments often come with parking spaces. They will need to be fitted with charging sockets but I don't see any difficulties beyond the small investment this takes.

<comment><USER13> _Often_ , but not always. In my city most apartment buildings don't even have enough normal parking spaces for the cars. People park in places like the parking lots of supermarkets.

</comment></comment></comment></comment><comment><USER14> A gas station costs millions of dollars, an environmental impact assessment, regular safety checks, staff to run it, etc, etc. A fast charging station needs a machine. A gas station requires you to transport the gasoline to the gas station. A fast charging station can be put practically anywhere in a city now.

I don't even have a charger at home. I recharge at a fast charger every time. Usually I go shopping, or do some programming or play a game. Not for everybody perhaps, but seriously not as bad as portrayed by this article.

<comment><USER15> The companies that build gas stations have processes in place to do all of the above, so it is just a known cost of doing business. It is easy to schedule a truck to get gas to your new station - you don't even need to own it.

One correction though, staff is optional. I've used a few unattended stations. You need staff to sell the "junk" that most gas stations also sell, if it is just gas pay at the pump just needs someone to fill the tanks and inspect things once in a while.

A charger is actually harder. Processes are not in place (yet!) to roll them out in mass (Tesla might be an exception?). The biggest problem though is fast chargers need enough power that you need to ask the utility where you can put your chargers. Many otherwise ideal places for a fast charger don't have enough enough wires for the load a fast charger adds. If the wires don't already exist you can expect to pay millions to get them there (hundred thousand per mile is a quote someone I know got for a different load he wanted to run)

</comment></comment><comment><USER16> Someone please explain to me why we have built electric cars so that the battery is fixed to the car and gets recharged rather than making the batteries swappable for an instant "recharge".

Sure, it moves the cost of wear and tear on batteries to the car owner rather than the fuel supplier, but since it seems it would makes such a big difference in the user experience of electric car ownership can this really be the whole explanation?

<comment><USER17> Actually for a while there vehicles _were_ designed to swap out the entire motive unit as well as the energy supply. You could even use different motive units for different purposes, such as long distance, larger loads, small journey etc.

This technology was called the 'horse and carriage'.

:-)

But joking aside I do wonder whether exactly this would be practical with non- living motive units. With modern tech it wouldn't be hard to control a separate traction unit, with its own wheels, at the front of your vehicle, and you could swap an electric one for a fossil fuel (or rented larger battery one) for long journeys in exactly the same way. I guess it would just be hard to design in such a way that it fulfilled all the things we expect from a modern vehicle, such as high stability, low drag, maneuverability, etc.

<comment><USER18> > _" With modern tech it wouldn't be hard to control a separate traction unit, > with its own wheels, at the front of your vehicle"_

What you are describing is the tractor-trailer (aka semi-trailer) truck. It would indeed make practical sense to swap tractor units when moving important cargo over long distances where fast charging facilities are unavailable. It's already done today with fossil-fuelled trucks for various reasons.

But for private automobiles, the advantages are very niche/narrow and wouldn't be enough to outweigh the impracticalities and disadvantages that you mention.

</comment></comment></comment><comment><USER19> Recharging doesn't require any patience at all if done correctly (ie. overnight at home, or while you're stopping for a meal). Complaining that you can't run your EV to empty then drop in to a gas station for 10 minutes to refill it is like saying cars are useless because they can't eat the grass on the side of the road.

This isn't an article, it's a hit piece.

</comment><comment><USER20> I personally think that EV charging infrastructure is not ready for mass adoption of electric cars. (This is, migration from internal combustion engines.)

But this article tries to seem "more than fair" without stopping to mention the one great advantage of charging - that some can do so at home, every night. So that should greatly reduce the infrastructure needs.

Peak charging in the public can and will be a problem, but I don't think the scale can be quantified without factoring in home charging.

<comment><USER13> > _But this article tries to seem "more than fair" without stopping to mention > the one great advantage of charging - that some can do so at home, every > night. So that should greatly reduce the infrastructure needs._

I think _some_ is the operative word here. Looking at the EU: 41.9% of people live in apartments.[0] In some of those countries it's over 60% even. I don't think even all houses are appropriate to charge your EV.

I didn't think this was as much of a problem until this article. I never considered the jerry can point. This does make me wonder if hybrids just make more sense after all.

[0] [https://ec.europa.eu/eurostat/statistics- explained/index.php...](https://ec.europa.eu/eurostat/statistics- explained/index.php/Housing_statistics#Type_of_dwelling)

<comment><USER21> Even the jerry-can point is bullshit. I already have a portable battery pack in my garage for jump starting a car with a dead battery (because it's not possible to get another car onto the drive to jump start one that way). The tech to do the equivalent for a battery powered car is achievable, and I doubt it'll be terribly long before the roadside assistance companies are fitting the equivalent to a number of their vehicles.

<comment><USER13> I suppose that is an option. Perhaps a 2nd electric car could charge the first one. That actually sounds like it should already be possible. Is it? I tried googling but couldn't find an answer.

</comment></comment></comment></comment><comment><USER22> 1\. When the powers out, gas pumps are out too unless there are generators. Even in Florida where this is expected after storms, we still have 95%+ of stations offline during power outages.

2\. Typical fast charging times are < 20 minutes and you don't typically aim for full. The first half of the battery charges in less than 15 minutes, nearly matching a typical gas station stop on a road trip. You can get 75 miles of charge in just 5 minutes at peak with a Tesla.

3\. Most users charge at home or work keeping them topped up ready for up to 180 miles typical miles of driving that day as long as they return to base and don't want to extend into the lower or higher reservations in the battery for long term health.

<comment><USER23> That works fine for daily trips. It fails for long trips (6+ hours).

Renting a car just for those trips simply costs too much, so your daily driver also needs to be able to perform that task.

For me, I'd need at least 200 miles of range in 10 minutes. Long trips already take too long, waiting longer than 10 minutes is a non-starter.

(And before you ask, I eat in the car. It's 10 minutes for bathroom, refuel, and back on the road.)

The only way I could buy an electric car is if I had two cars.

<comment><USER24> There's always someone posting a comment like this in every EV thread -- I'm hoping someday it will be a guy who pees in a bottle in order to minimize stops.

<comment><USER23> Bizarre comment. Have you ever taken a 6+ hour trip in a car?

If you don't control stops very carefully you can add hours to the already long journey.

And for the record I think a hybrid with a 50 mile battery is the sweet spot: Drive it electrically almost every day, but you can go farther if you need to.

</comment></comment></comment></comment><comment><USER25> Recharging electric cars requires plugging it in and walking away to do something else instead.

Electric car fuelling is a parallel operation, not a serial one.

Rapid charging happens on the longer journeys that require it while you're using the restroom, or grabbing a bite to eat or drink, or simply improving your safety by having a snooze

And if you get an efficient electric car with a high miles/kWh rating - <USER2> than a status symbol electron guzzler - then there is less time required anyway.

There's a mental paradigm shift required when you have an electric car to one where you have a fully fuelled car every morning by default. Once you've made that switch you'll wonder why you didn't do it sooner.

<comment><USER23> 10 minutes. That's the longest I'm willing to wait at stops. Maybe 15 minutes if I had to.

And stop no more often than every 3 hours.

So I'd need about 200 miles of range in 10 minutes of charging. Can they do that?

<comment><USER25> The recommended safety advice is to stop every two hours or so and rest for fifteen minutes each time. Otherwise you increase your chances of having an accident due to fatigue.

The EU rules for driving HGV allow you to drive 2 hours, have a 15 minute break, drive a further 2.5 hours and have a 30 minute break. Those are enforced by law and tachographs

</comment></comment></comment><comment><USER26> I don't think EVs can be exact replacement of traditional vehicles in all instances yet, for this very reason. But in many cases they fit a use case perfectly. In my case I have 4 kids and a wife, and we have 2 cars. One is a mini-van and fits everyone with room to spare. The other one only seats 5 (uncomfortably) but I only use it to drive myself to work. So my next car may very well be an EV of some sort, but we cannot replace the mini-van with an EV due to the range and requirement that we need to drive farther than that (which means quick fueling at gas stations).

<comment><USER27> The Pacifica plug-in hybrid is a fantastic minivan that can go up to 30 miles all electric before needing to engage the ICE, and in hybrid mode it still gets significantly better milage than a conventional ICE minivan.

</comment></comment><comment><USER28> Isn't this missing the point that you can put an EV charger ANYWHERE. There's no need to regularly deliver gas to it. You can have it in you home and charge overnight. There's no need to cluster them together.

</comment><comment><USER29> I think this article went a little too far and overstated the point.

I wouldn't be worried about charging my electric car in the city where I live. That's a nonissue, just charge at home.

I'd be worried about going longer distances. You roll up to the supercharger in the middle of nowhere, no ability to go anywhere else since you're out of battery, and every charging slot is full. There's a line of tesla's to get a spot. Sitting around in your car for a half hour as you wait for owners to leave to even start charging. This would be a legitimate fear of mine.

</comment><comment><USER30> It's true, cars are big and require a ton of energy. That's not a huge problem though, because with the correct land use policies you can pretty much replace them with bikes.

</comment><comment><USER31> As somebody who has owned 3 different EVs (LEAF, Model X, and now I-PACE), I find this article a bit hyperbolic. Okay, it's a rather poorly-researched fluff piece that wouldn't pass muster in any of the subreddits I frequent. I'd expect something with more substance here at HN.

That said, I no longer drive an EV when I do road trips over 150 miles. I replaced one of my EVs with a plug-in hybrid (PHEV), so my household has one BEV and one PHEV.

The reason for having plug-in capability in both cars is because the "full tank every morning" part is amazing. The reason for having gas capability in one car is because the convenience of using gasoline on longer road trips is amazing. With a PHEV, you don't have to compromise in either case (around-town or road trip).

Individual situations can be highly varying, and so for some people all-BEV can work. In my family's case, we have one 150-mile trip that we do about 8 times a year where we can charge at the destination. The BEV can make that trip direct in pretty much any weather conditions without a problem. There's another trip we do to see family in another state that's 230 miles away, and we can't charge at their house. Can't do that one comfortably in the BEV, so we usually just take the PHEV for that one.

However with the BEV it's possible to do the 230-mile trip since there are Electrify America (EA) rapid charging stations both along the way and at the destination. Along the 150-mile trip there are in fact four EA locations, so if something weird or unexpected happens with the distance driven or the destination charging, there's no problem getting a quick charge at one of those stations. In any case it's been working out to just an extra 30 minutes of charging maybe 2 or 3 times a year, during which we can grab a bite to eat or get some shopping done. Really no big deal at all.

All that said, I would never attempt to drive a Tesla on a trip where I'd need to rapid charge frequently during times like spring break, the 4th of July, Thanksgiving, or Christmas. You're beholden to a single proprietary rapid charging infrastructure, and that's very likely to suffer "hot spots" that are difficult to predict and that can ruin your day. The unpredictability, I would imagine, is due to Tesla being a victim of its own success. Having more cars on the road means that there ends up being more "tail-end" situations in the population.

</comment><comment><USER32> If you can afford a $40k+ car, you can afford one of those "clean" and quite running honda generators...

<comment><USER5> If Honda engineers were smart, they'd build a car with a built in generator. They are smart. Hence the Prius.

<comment><USER33> Except that the Prius is made by Toyota :)

</comment></comment></comment><comment><USER9> These are problems associated with personal car ownership, not EV's themselves. In a utopia with fully autonomous affordable electric taxi cabs this is not an issue, as they can charge by themselves in a cheap parking field outside cities, combined with a large solar array.

</comment><comment><USER34> Article fails to note that most EVs are charged at home most of the time.

</comment><comment><USER35> Just need to make the battery packs removable - then the car can be "recharged" fully in less than 5 minutes.

</comment><comment><USER36> It's a short term problem. Self-driving cars will drive themselves to a charger.

<comment><USER15> That doesn't do any good when I want to keep driving. Not a problem for 99% of trips, but the rare cross country trip liquid fuel is a lot quicker to get back going with.

<comment><USER37> Then you can rent a war, a perfectly viable solution for a problem people might have one every few years.

<comment><USER15> More like a couple times a year for me. It sound viable, but it really isn't because the cost is so high - it is cheaper to have a (used) car that works for everything than to spending $800 to rent a car for a week. I visit family out of range of an electric car for many holidays - cheaper to buy a car just for those trips and park it than rent a car for those trips!

I'm not against renting a car, but it is far too expensive in practice to do for a regular vacation.</comment></comment></comment></comment>


Systemd: The Biggest Fallacies - <AUTHOR> http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html <comment><USER2> First of all, thanks for linking to uselessd.

The writeup was quite nice. I was actually in the process of writing my own notes to respond to Poettering's "The Biggest Myths", but your approach is better. I'll definitely use it as a reference to link to in discussions.

That said, I have a little caveat for #9. Though systemd violating KISS is virtually undeniable, you should reword it so as to point it out on systemd's own merits, not in relation to sysvinit, which systemd explicitly intends to be more complex than.

<comment><USER3> I have absolutely no idea why this comment has been voted to the bottom of the page. Friendly, innocuous, and thoughtful.

<comment><USER4> The systemd promotion brigade has invaded hacker news.

</comment></comment></comment><comment><USER5> He's missing the point about socket activation. The problem it solves is different: if you have daemon B that depends on daemon A, you want to express that dependency in the init system, so that it starts A before B. But just starting process A isn't enough to ensure that A is actually listening on the socket that B wants to connect to, since it takes some time to load the binary and do initialization. There's a race condition there, where B can try to connect before A binds to the socket. To fix the race, the init system needs to either monitor for the availability of the socket, or do it systemd-style where it opens the socket itself.

<comment><USER6> As a bit of a disinterested observer (I'm mostly in the "just make it work" camp), I can't help but feel that if you pile up the problems that systemd seems to solve on one side, and pile up the enormous piles of code that are apparently necessary to solve the problem on the other, that systemd does not come out looking too good.

(Writing this in C was probably a silly idea.)

<comment><USER7> what language do you think systemd should have been written in?

</comment></comment></comment><comment><USER8> Some of these are arguments I'm glad to see getting more attention, such as Fallacy #1: "Systemd is multiple binaries, therefore it is not monolithic".

Others strike me as a stretch. For example, Fallacy #4.1: "Unit files reduce complexity". No, I don't want the least complex init system init system possible. I think it's obvious to people who have written both system v init scripts and systemd or upstart configurations that the latter are dramatic improvements. The chance that I will write a buggy init script is, unfortunately, high. The chance that I will need to debug systemd when writing a unit file is very low.

<comment><USER9> >I think it's obvious to people who have written both system v init scripts and systemd or upstart configurations that the latter are dramatic improvements

Except that is a false dilemma, which he points out. Sysv init takes more work because nobody has bothered to fix it. You don't need a massive complex set of software like systemd to make this easy, see the BSDs init scripts like he suggests.

<comment><USER10> That doesn't really invalidate the argument. Upstart and systemd units are dramatically easier and less bug prone than the existing sysv alternative. If it was nontrivial to fix they would have.

The missing beef here is actual bugs and problems with systemd. Post some zero days... Nobody challenges that businesses with paying customers all indepdently came up with the need for smf, launchd, upstart, and systemd. Are they just adding shit to add it or do the see value and need?

<comment><USER9> > If it was nontrivial to fix they would have.

There is no basis for that assertion. It is trivial to fix, again, see BSDs. Just because nobody bothers (or people bother and their effort is rejected due to politics) doesn't mean it is nontrivial.

</comment></comment></comment></comment><comment><USER11> There is a lot to digest, but so far this this looks like an excellent example of critical thinking, regardless of one's feelings or intuition regarding systemd. Both proponents and detractors have much to be thankful for in this article.

</comment><comment><USER12> Some of his arguments look a little bit botched.

For example: > Fallacy #1: "Systemd is multiple binaries, therefore it is not monolithic"

Well following Wikipedia ([http://en.wikipedia.org/wiki/Monolithic_application](http://en.wikipedia.org/wiki/Monolithic_application)) means either a non-modular application, or a self-contained application. In this sense either his counter-argument is simply wrong, or the examples list he gives at the and is wrong.

> Fallacy #4.1: "Unit files reduce complexity"

Here he compares the ca. 275.000 LoC of systemd with the 10.000 LoC of shell scripts used as initscripts on Debian. Lets ignore that the 275.000 LoC contains much more than the unit management in the systemd daemon. But why are the bugs always in the scripts and never in the shell as he claims? And sorry, I don't take his word that C is always more error prone than the shell. This is true when the shell is used for its intended purpose: to start commands, pipe btw them and having a little bit of flow control. For everything else you surely want to have a general purpose language.

> Fallacy #7: "Systemd gives you socket activation!"

Well, according to boot charts, socket activation is not only a marketing gimmick.

EDIT: Add Fallacy 7

<comment><USER13> I think we need a separate term for "internal modularity" (Linux, Systemd) and "external modularity" (Unix, the Internet).

The former depends on internal interfaces, where individual modules help separating concerns but can't be swapped out or reused in other contexts, whereas the latter relies on formal interfaces, allow components to be swapped, and promote reusability. (Also, the former can be monolithic or not, but the latter can never be monolithic.)

"Unixy" is sometimes used, but it's not a great term.

</comment></comment><comment><USER14> "shell scripts are not inherently buggy" not the week to argue that point.

<comment><USER15> It's not shell scripts, it's /bin/bash -- the guy fieri of shells.

<comment><USER16> Which also happens to be the default or expected shell in the majority of sysv installs on Linux. '/bin/sh' symlinks to bash, shell scripts specify '/bin/sh' So it's another example of a distinction without a difference to single out bash. Most sysadmins cannot just switch to ZSH to to write their init scripts.

<comment><USER17> Debian and its many derivatives (including Ubunutu) use Dash, and the BSDs tend to use some form of Ash. I don't have the statistics but, if it's true that a majority of distros still use Bash for noninteractive use, it's a tiny majority.

<comment><USER16> Well, a lot of them then... I know that Arch and Gentoo at least use Bash and I'd be surprised if they were the only ones.

<comment><USER18> Arch is using systemd and openrc comitted to using POSIX sh in their init scripts some time ago. So you can use dash or whatever posix compatible shell you want with it.

</comment></comment></comment></comment></comment></comment><comment><USER19> > Fallacy #2: "Lots of people use systemd, therefore you should too" > This is > a classic example of the bandwagon fallacy.

On the other hand, network effects are real. You'll have an easier time finding help if the system you use is used by many others.

<comment><USER20> ... and in this case systemd is popular not because _users_ decided to use it, but because _distributions_ decided to use it, which means that systemd is going to have a stronger support network and more developer attention than a system which is not popular.

Good support and active development are pretty big advantages.

</comment></comment><comment><USER16> "For Internet socket activation, all you have to do is start your daemon the old way, have it bind on the port, and let it sit there idly. If the kernel needs the RAM, it will swap the (idle) daemon to disk. If the kernel receives an incoming connection, it will swap the daemon back into RAM so it can handle it. Systemd doesn't need to be involved at all here."

So you want me to patch my Postgres instance to implement this? Or should I just do it in the init script? I guess that's possible, but it requires your sysadmin also be a programmer.

<comment><USER21> That's how daemons normally work. The author is obliquely pointing out that socket activation isn't that much of a benefit. Historically, "socket activation" using inetd was common but as hardware got cheaper people gradually dropped inetd in favor of just starting all their daemons at startup.

<comment><USER16> I understand the author's point; he's not being oblique at all. I just disagree. He explicitly claims that the kernel providing socket functionality is enough. But it's not. The example using mkfifo for example, is terrible for instance. It provides no lifecycle management and you'll end up launch multiple versions of a daemon if you accidentally send multiple signals to the pipe. There is a huge difference between "this is technically possible," and this is doable in a way that doesn't have many unforeseen pitfalls. Systemd asks much less of professionals than sysv and that's it's chief selling point.

</comment></comment></comment><comment><USER22> I am getting so sick of these blogs for or against systemd.

It is free software. If you do not want to use it, use a distro without it. And vice versa if you want it. And if you don't _like_ that Debian or Canonical or Arch a few years back or OpenSuse have switched to using it... too bad, you are not the maintainer of the repos, and if you were an active member of the community with voting power, you were outvoted. That means a majority of people with stake in these distros wanted systemd, and it is _their_ project.

Make your own distro without it if you don't want it. Or use one of the dozens of distros that don't use systemd, or one of the forks that have been made to remove systemd already.

<comment><USER2> It's obvious you didn't even read the article.

EDIT: I don't know the motivation for the downvotes. I replied like this because the commenter posted a canned cookie-cutter reply that is addressed in the article as Fallacy #6.1.

<comment><USER23> >I don't know the motivation for the downvotes

It's pro-systemd brigading. The cancer is spreading.</comment></comment></comment>


Facebook defends against claims that advertising on the site doesn't work - <AUTHOR> http://online.wsj.com/article/SB10001424052702303768104577462393468083290.html?mod=WSJ_hpp_LEFTTopStories

<comment><AUTHOR> "In the study, which follows up on another report done last year by comScore called the Power of Like, the research firm found that being a fan of a brand on Facebook causes people to purchase that brand more frequently.

For example, comScore tracked people who were Starbucks fans on Facebook against a control group of people who weren't exposed to those messages. ComScore found that over a four-week period, fans and their friends bought 38% more frequently at Starbucks than people who weren't exposed to the Facebook marketing."

</comment><comment><USER2> Paywall?</comment>


Ask HN: What screen sharing software do you use and recommend? - <AUTHOR> <comment><USER2> I've found that AnyDesk meets many of my personal and professional needs. It's prime selling point is that it's super lightweight, unlike TeamViewer.

</comment><comment><USER3> at work we ( are forced to ) use cisco webex. But i would _not_ recommend it, too brittle, crashes a lot ( sometimes it´s the sound, sometimes it´s the video, sometimes it´s something else... ).

</comment><comment><USER4> As always, it depends on what you are needing.

Do you only need console? Then SSH and tmux work great.

Do you need to take control over the other person's desktop? Transfer files?

In this case, there are lots of options. VNC, GoToAssist, TeamViewer, LogMeIn... etc.

</comment><comment><USER5> I like appear.in

</comment><comment><USER6> Nomachine is a good one.

</comment><comment><USER7> teamviewer</comment>


Mass grave may belong to Viking Great Army - <AUTHOR> https://www.cnn.com/2018/02/02/health/viking-graves-repton/index.html <comment><USER2> Better source

[https://www.eurekalert.org/pub_releases/2018-02/uob- rdr02011...](https://www.eurekalert.org/pub_releases/2018-02/uob- rdr020118.php)

with link to the paper

[https://doi.org/10.15184/aqy.2017.196](https://doi.org/10.15184/aqy.2017.196)

</comment><comment><USER3> > "Where sex could be determined, around 20% were women, and this is in > contrast to previous assumptions that the Viking raiders were solely male. > Of course, we can't know if these women (or men, for that matter) were > 'warriors' but it demonstrates that the group was made up of both genders.

Well, from Wikipedia:

> When Leif Erikson's pregnant half-sister Freydís Eiríksdóttir was in > Vinland, she is reported to have taken up a sword, and, bare-breasted, > scared away the attacking Skrælings. The fight is recounted in the Greenland > saga, though Freydís is not explicitly referred to as a shieldmaiden in the > text.[0]

I love the shieldmaidens in _Mongoliad_ and _D.O.D.O._ by Stephenson et alia.

0) [https://en.wikipedia.org/wiki/Shield- maiden](https://en.wikipedia.org/wiki/Shield-maiden)

<comment><USER4> Germanic and Celtic tribes often took the whole family with them when raiding or fighting. Quoting wikipedia "Armies also often consisted of more than 50 percent noncombatants."

This could result in worse defeats - the fighting men could get pinned in between the wagons behind and the enemy in front. As happend a few times when fighting the Romans.

In fact, in the late middle ages, during the pre-Protestant religious wars, a German ancestor of mine left his castle with an armored wagon, a cannon, and his family. They lost the battle and never returned to castle. The family fled and changed their name.

[https://en.wikipedia.org/wiki/War_wagon](https://en.wikipedia.org/wiki/War_wagon)

[https://en.wikipedia.org/wiki/Wagon_fort](https://en.wikipedia.org/wiki/Wagon_fort)

The presence of women and children with a northern European army is not very conclusive evidence that they were there as warriors

<comment><USER3> Noncombatants don't typically wield swords bare-breasted, however.

<comment><USER5> A single instance of a remarkable individual highlights how odd that one person was, however.

<comment><USER6> There are other examples, including physical evidence (grave of a female warrior)

[https://en.m.wikipedia.org/wiki/Shield- maiden](https://en.m.wikipedia.org/wiki/Shield-maiden)

</comment></comment></comment></comment></comment><comment><USER7> I'm interested in how this affects dating for any species with a diet of fish</comment>


Ask HN: Prescription glasses which optimize function over fashion - <AUTHOR> Traditional glasses appear to prioritize looks over function. I am not a professional optician, but I imagine a pair of glasses which optimize function over form to meet at least some of the following criteria:

  - Large lens to maximize field-of-view
  - Cup-shaped lens to optimize distance from eye at all angles
  - Thin shafts to enable lying in bed and using headphones
  - Minimal sized frame (although should be mostly outside of field-of-view anyway)
  - <USER2>
 Price and design are irrelevant. Contacts is, unfortunately, not an option.
Are there are any such glasses available? Is my assessment wrong? <comment><USER3> Your biggest challenge might be not the frames but the lens curvature. Lenses these days are ordered from a catalog of standard prescriptions.

Unusually strong prescriptions sometimes have to be special-ordered because they aren't kept in stock, but AFAIK they're still not custom-ground. Or at least they're still machine-ground from standard blanks.

If you want a lens with unusual curvature, you'd need to start with a blank that supports that curvature - which may not exist. And the grinding machines may also be unable to work with that curvature (hand-grinding, besides being immensely more expensive, will be less consistent in its result).

And then you'll have the problem of fitting the lens securely into a frame that's designed for one with lesser curvature. Heck, even my (moderate prescription) sunglasses suffer from poor lens fit.

I'm not saying it can't be done; just that there are a lot of obstacles to what you're looking for.

</comment><comment><USER4> You have to balance one thing against another.

I like a large lens in that I get a wide field of view. I have a very strong prescription, thus large lenses curve through a lot of solid angle, thus no matter what angle you look at me from there is a strong reflection that obscures my eyes. It makes me feel like I am one of those anime characters whose eyes are hidden behind spiral lines. I think it is more than cosmetic, because it impairs people reading my emotional expressions.

When I go hiking with thin glasses, however, I end up craning my neck down so I can see what is going on in front of my feet. That makes my neck hurt.

<comment><AUTHOR> In my head, I can easily imagine a model combining all of the above (except, perhaps, weight and a very large lens). Which criteria do think are incompatible?

</comment></comment><comment><AUTHOR> Large lenses ("pilot" glasses) are usually not especially curved, I believe that is suboptimal and mostly done for looks for historical reasons. (At some point, an optician told me that was the case and that the optimal shape would be spherical to optimize distance from the eye.)

</comment><comment><USER5> drill-mount frames.

<comment><AUTHOR> Is there a difference between 'drill-mount' and 'rimless'? These fulfill some of the criteria, but I fail to find such with a nice, large, preferably cup- shaped, lens.

<comment><USER5> it's the same thing, but lens shape is not dictated by the frame. you're likely to find pictures of rimless glasses with small lenses because small lenses are popular now, but you can choose any shape you want.

<comment><AUTHOR> I'll see what I can dig up, thank you.</comment></comment></comment></comment>


Ask HN: How much does it cost to run HN? - <AUTHOR> Would be interested in seeing a cost breakdown of running this site. <comment><USER2> I would be surprised if it is more than $100-200 a month

<comment><USER3> You're forgetting the cost of a full-time moderator.</comment></comment>


Signs of the bubble: monetize your startup waitlist. - <AUTHOR> http://www.hacktheline.com/

<comment><USER2> Main piece of feedback is: MISSING CALLS TO ACTION!

I thought the only call to action which is confusingly enough linked with an image "Connect to stripe" was just a sample image, it took me going back to your landing page three times to realize it was not until I saw the URL it linked to. Definitely not clear enough!

</comment><comment><USER2> Another issue is the main issue with the idea itself, it might be wrong, but who would use this? If an application has enough buzz (like mailbox) trying to monetize the waiting list might seem tacky, and they probably (and do) have enough resources to not care about the money they could take for waiting in line.</comment>


Coding Horror: Pressing the Software Turbo Button - <AUTHOR> http://www.codinghorror.com/blog/archives/001173.html

<comment><USER3> What an utterly pointless article.

<comment><USER4> No joke - totally missed the point and went off on an unrelated tangent - <USER2> broken record stuff.

</comment></comment><comment><USER5> "Developers need fast machines to be productive"

Possibly. But one of the advantages of giving developers comparatively slow machines is that it gives them a personal incentive to produce fast software.

Of course that's painful when bloaty IDEs come into play, but for web software I'd have to suggest using an under-specced deployment test platform to get some of this benefit.

<comment><USER6> No. A slow machine is just _aggravating_. If I have to wait very long for a compile, the IDE, anything, there's a good chance I am going to get distracted and do something else. I'll typically have tons of things open at once, already slowing things down a bit; having old hardware is just too much on top.

It is important to check for performance on slow machines, but that can be done on a virtual machine.

<comment><USER7> Seconded, its extremely aggravating, I remember clearly when I had the horror of working with an old version of .NET C# with a big project on a SHARED slow server, which took roughly 1-2mins to compile, can you imagine trying to learn and debug C# code under this environment? Right, not a good idea.

<comment><USER5> Sure, it's annoying. But I didn't say it was nice, I said it was a good incentive for the developer to create software that was snappy.

Those suggesting the use of a separate slow test environment are, I submit, being unrealistic about real-world practices in testing.</comment></comment></comment></comment>