New two-stroke engine design could help keep internal combustion around longer - <AUTHOR> https://www.roadandtrack.com/new-cars/car-technology/a32612802/entry-ignition-two-stroke-engine-design-explained/ <comment><USER2> Even with the increased electrification of transport, there's still a very strong case for liquid fuel - it just offers an energy density so much higher than batteries, especially in off-grid or remote situations.

Electric drivetrains open up an interesting potential for range-extenders which charge the batteries. The constraints are different than conventional engines - lower peak power, more-or-less continuous power output operation, no sudden torque changes. Different constraints generally mean a different optimal solution.

<comment><USER3> There is not a huge gap at all.

Li-metal batteries [edit: still an immature tech] are at around 14 MJ / kg, and gasoline is at 47.5 MJ / kg.

Moreover, suppose that you are _really_ "off-grid". Meaning, you are off any fuel supply network!! In this case precisely, you would be saved by electric- related techs, such as photovoltaic.

<comment><USER4> I have driven through parts of the western US where it is 100 miles to the next gas/petrol station. There are farms and ranches in these areas but they are connected to the electrical grid with wires. It seems like having an electric tractor and charging at the farm would be more convenient than transporting hundreds of gallons of diesel fuel from 100 miles away.

<comment><USER5> Tractors are bursty. They are heavily used at planting and harvesting. Farmers can't spend long periods of time recharging in the middle of planting season. And it would be too expensive to buy 12 hours of battery capacity for a couple times a year.

Gas still wins with a short refuel time.

<comment><USER6> Actually, batteries win on refuel time. Swapping batteries is much faster than filling a tank. Gas wins on meantime between refuels and in other categories. Farmers can and happily will spend super long periods of time recharging if they can operate during the recharge.

My own initial experiences have been mixed. Overall advantage still goes to gas. But I think we're very close to getting this battery thing figured out. Just a few years away. When we look back it will seem like it happened overnight.

<comment><USER7> >>Actually, batteries win on refuel time. Swapping batteries is much faster than filling a tank

By that logic, you could say that there is absolutely no difference, because if you can imagine a car where the battery can be swapped, you should be able to imagine a car where the entire fuel tank is swapped. A tractor arrives at a station, and instead of filling up 500 litres of diesel, the entire tank is simply replaced with a full one. It wins again since fuel tanks are cheap - they are just metal and plastic after all, you can have several just sitting there, full or empty.

The fact that no one has done it yet suggests that this really isn't an issue - commercial diesel filling stations usually run at much higher pressure than your regular pumps, a truck/tractor tank fills in minutes because of a much higher flow rate.

<comment><USER8> That is very silly and disingenuous argument to make and a total straw man.

Swapping gas tanks provides no advantage and you conveniently ignore the whole point of the batteries which is that you don't need any fuel infrastructure to fill your tanks!

<comment><USER5> > you don't need any fuel infrastructure to fill your tanks!

A fuel infrastructure costs magnitudes less than just one battery pack. You just need a large tank and pump.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> All of the skeptical comments I've read here are talking about how ICE are already obsolete, since electric cars are cleaner, quieter, and simpler. I'm picturing this engine being used in other applications (even though the website, and the journal the engine is publushed in, are automotive).

Stationary generators and marine drivetrains come to mind. Those are less sensitive to the greater size and weight that this engine might have, and they benefit greatly from the ability to load fuel, store it, burn it as needed, and be refueled at any time, even while running.

As an example, my local university's datacenter has two rooms full of batteries for power backup. They instantly switch on, but can only power the datacenter for a short time. To protect against extended blackouts, there are two redundant diesel generators in the sub-basement, and enough fuel to run the datacenter for several months. Battery technology seems to have a ways to go before it'll be worthwhile to just have a basement full of batteries as long-term backup power.

People with those sorts of use cases are probably going to be relying on ICEs for a long time to come. In the meanwhile, efficiency improvements can make them less harmful to own and operate. And even after 150 years of developing ICEs, engineers are still coming up with ideas, maybe even practical ones, to gain those improvements.

<comment><USER10> Flow batteries are a possible solution. Energy density is substantially less though, so they may not be practical for applications where the battery is only rarely used.

<comment><USER11> Whats the advantage of a flow battery over a fuel cell which has higher energy density?

<comment><USER10> I think that the main thing is that in general the "fuel" for a flow battery can be stored at ambient temperature and pressure, and so the tankage is cheaper.

In their basic function though I agree they are very similar.

</comment></comment></comment></comment><comment><USER12> Right before jet engines took over the military aviation market, you saw some very complex, high efficiency piston engines. Mechanical marvels they were, only now are automotive engines catching up in performance. Ultimately they were all commercial failures, the jet engine had a lot more headroom for improvement and was mechanically much simpler.

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

<comment><USER13> I've noticed a very general principle here. Things which are 'before their time' obviously tend to fail, but the interesting bit IMO is that 'before their time' often means "the problem isn't yet constrained such that the efficiencies afforded by the design are economically significant". I think this explains why so much software (my branch of engineering) is miserably inefficient and bug-ridden despite the fact that we have technology to improve efficiency and quality by several orders of magnitude (at a relatively modest cost)--the economic context simply doesn't place a very high value on efficiency and quality, presumably because the market is comparing software against the many, many orders of magnitude worse performance afforded by humans.

Perhaps all of this is obvious to many others; it's interesting and novel to me, anyway.

</comment></comment><comment><USER14> History is littered with the corpses of 'better' IC engine designs... the basic problem is you need to retool your entire factory and re-design your vehicles. If you are doing that today, why not just jump straight to electric motors?

<comment><USER15> Because battery efficiency is still only 10% of liquid fuel efficiency, in kwh/kg.

<comment><USER16> This is correct, but this is density not efficiency.

<comment><USER15> For transportation that's the pivotal interesting measure. Efficiency is for grids etc. For moving energy around, the weight is critical.

<comment><USER16> I agree the weight is critical but kWh/kg is still not efficiency. Efficiency = "power discharged by"/"power delivered to" battery

<comment><USER15> Yes thanks everybody knows what efficiency is. It factors into transportation, only in the effect it has on fuel weight. Essentially, on how it effects kWh(delivered)/kg.

</comment></comment></comment></comment></comment></comment><comment><USER17> Investment into productionizing these kind of advances has pretty much stopped.

It's a bit like hard drives... As soon as the SSD arrived, everyone saw that hard drives would eventually die out, so manufacturers pretty much stopped new technology development. Sure, there have been a few small advances, but seek times and data read speeds haven't gone up for a decade, and capacities have only crept up.

IC engines are the same. It might take them 30 years to die out, but in those 30 years there won't be any significant tech advances, because every company that makes them is only optimizing for cost in a shrinking market.

<comment><USER18> That's not even remotely true. Increasing emissions standards and economy standards means that ICE development continues apace. Nissan, for instance, recently put into production a variable compression engine, and all manufacturers are pairing ICE advances with electric for even larger gains.

Honda has a nicely sized sedan that gets 55 MPG city out of a drivetrain unit that is amply powerful.

Most of them produce small 4-cylinder engines that are as powerful as the V-6's that proceeded them, all while producing less emissions and offering greater fuel economy. Even Ford, Chevy, and RAM are putting gas 4-cylinder engines in their mid-size trucks are just as capable at 8-cylinder engines used to be just not very long ago.

Emissions and fuel economy standards will continue to tighten, which means that ICE development will continue for a long time.

<comment><USER17> Most of those improvements are not really new technology, but instead technology from European cars (where gas taxes are high) just imported into the USA (where previously people didn't care about MPG much because gas is much cheaper).

<comment><USER18> It is a global effort, and not one limited to the US. Besides, the biggest improvements in ICE fuel economy and power are from Japan, not Europe. Europe hitched its wagon to the diesel engine, and we all know how that turned out.

Sure, turbochargers and hybrid tech aren't new in an of themselves, but that doesn't matter because there's still a lot of room for development left in them.

Even just 5 years ago, the idea of getting a roomy, nicely configured sedan that gets 55MPG city was a silly notion. Now, Honda sells them all day for $24k USD.

<comment><USER19> >Even just 5 years ago, the idea of getting a roomy, nicely configured sedan that gets 55MPG city was a silly notion

VW diesels from the 90s were doing 5 or 6 l/100km

<comment><USER18> Those were neither roomy nor nicely configured.

</comment></comment></comment></comment></comment></comment><comment><USER20> The theoretical efficiency gain appears to be greater than the stated 14%. The article cites a video [1] which in turn cites 49% vs 63% maximum theoretical thermal efficiency for a traditional engine and for the Entry Ignition engine, respectively. That makes it a 14 percentage point increase which is 29% increase in efficiency.

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

<comment><USER21> Thank You I had the exact same question in mind. ~30% increase is a lot.

I wonder how much more efficiency can we continue to squeeze out from ICE?

</comment></comment><comment><USER22> Link to the video: [https://www.youtube.com/watch?v=oiUnqlGzLw8](https://www.youtube.com/watch?v=oiUnqlGzLw8)

</comment><comment><USER23> I just watched the video. Can anyone answer these questions?

What prevents the burning from getting into the mixing chamber? It seems like the sliding valve is open while it's burning. And there's higher pressure in the cylinder.

What prevents the mixing chamber gas from getting into the compression reservoir?

<comment><USER24> I can't answer the second question, but as to the first my understanding from the video is that the ignition cylinder starts out as much lower pressure that the fuel/air chamber, and as the slide valves open the mixture naturally moves from high to low pressure. The heat contained within the cylinder starts the ignition of the mixture upon entry (hence the name of the engine).

I don't understand how the heat differential between the injection and ignition phases is so great that ignition happens as the slide valve opens, but so little that ignition doesn't happen within the fuel injection chamber. Perhaps the pressure differential regulates that as well?

</comment></comment><comment><USER25> It is basically a split cycle engine and the "New" is a bit overblown by more than 100 years. Even similar non-spark based hot ignition was used back then:

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

"The Backus Water Motor Company of Newark, New Jersey was producing an early example of a split cycle engine as far back as 1891. The engine, of "a modified A form, with the crank-shaft at the top", was water-cooled and consisted of one working cylinder and one compressing cylinder of equal size and utilized a hot-tube ignitor system."

<comment><USER26> "Fuel injection has been tried for 50yr, there's no way it will be commercially successful now"

-some guy in 1980.

History is littered with inventions that didn't gain widespread use initially then some little advancement(s) came along that make the inventions workable when revisited and tweaked. Repeating firearms and electric lightbulbs are two good examples.

I don't pretend to know which bucket this "new" engine advancement will fit into but I think your judgement is premature.

<comment><USER27> Bosch fuel injection was commercialized in 1967.

<comment><USER26> You're not wrong but to imply that Boch fuel injection was successful would be to wear some really rose colored glasses. Boch fuel injection was such a small improvement over contemporary cabruerators and such a downgrade in terms of maintenance and cost of ownership that it was more or less universally reviled by everyone who was not into technology for technology's sake. It never really achieved widespread use. If you wanted a glass half full perspective you could say it gave 1st generation throttle body based injector systems a low bar to exceed. Bosch mechanical fuel injection is almost a perfect example of an implementation of a technology not ready for mass market adoption that later became ready for mass market with the advent of new technology (cheap digital electronics in this case).

<comment><USER27> Volvo, Citroen and many others besides extensively adopted the Bosch fuel injection system and those cars performed better and were more fuel efficient than their equivalents without. Quite a few of them still run today, the big difference in price is what held back faster adoption more than anything else.

I've worked on those systems, they were clearly a game changer, incremental improvements got us to where we are today. Almost no single technology hits the ground running, especially not in inherently conservative domains such as automotive. Interesting implementation details made the Citroen one much harder to work on.

Electronics aren't perfect either, they make it a lot harder to keep such older vehicles functioning whereas the purely mechanical ones from an earlier era will quite likely last practically for ever.

Note that Diesel has had mechanical fuel injection for much, much longer and that it wasn't exactly new technology to begin with. It's just that the conditions in a gasoline engine are a bit different which needed a re-thinking of the concept.

The jetronic is now 50 years old:

[https://www.bosch.com/stories/50-years-of-bosch-gasoline- inj...](https://www.bosch.com/stories/50-years-of-bosch-gasoline-injection- jetronic/)

To suggest that fuel injection had to wait until the 80's before it was commercialized is a ridiculous attempt to rewrite history.

</comment></comment></comment></comment></comment><comment><USER28> Well... If we cut too much carbon emissions it's a relief we can count on such engines to fill in the void. ;-)

</comment><comment><USER29> I am relatively certain that people will be rebuilding old Detroit and Cummins diesel engines in heavy equipment for at least the next 50 years, if not 100.

I have been surprised at how much 40V/80V electric systems are cutting into what was traditionally two-stroke light engines for string trimmers and mowers. The batteries are expensive though, and I don't know how many you'd need to have in rotation to be able to keep one fully charged and ready to go under continuous usage.

<comment><USER30> For the weed trimmer and lawn mower I purchased at U. S. chain Lowes, the magic number of batteries is 3. The mower came with 2, and the trimmer with 1. The charger can charge a battery _almost_ as fast as the mower can consume them, so the third is needed for a little slack. You could get by with only two if you're content to get a beverage between batteries.

Theoretically, anyway; with our tiny yard this is seldom tested. Which why I'm annoyed by neighbors that buy a new gas-powered mower. There is not a yard within at least a 3 mile radius of me that can't be mowed by a modern, lithium-battery push mower.

</comment></comment><comment><USER31> A 2-stroke engine has one ignition per revolution per cylinder. A 4 stroke engine has half an ignition per revolution per cylinder (or two revolutions per ignition).

This engine has only one combustion chamber for every four cylinders, which means that it experiences one quarter of an ignition per revolution per cylinder.

It's not a 4-stroke, clearly, but I don't see how you can get away with calling it a 2-stroke either. The strokes kind of become beside the point, but if I had to I might want to call this an 8-stroke engine.

I see them pilfering ideas from this for 'simpler' engines. That valve design feels like it could be used for about anything. I've seen other engine designs that use a single intake chamber, so that part has in fact already been done before.

That recuperation chamber trick I think could be applied to a traditional 4-stroke engine, which you would need every other cycle and therefore could share with another cylinder (opposed by a full revolution, which I hear at least a few 4 cylinders do). And something similar could be applied on the intake side (although you might have to use the ignition cylinder for the second compression) and then fully half of your cylinders fire.

</comment><comment><USER32> I'm not sure which is worse, YouTube videos where all they do is summarize a written news article, or a written news article summarizing a YouTube video...

<comment><USER9> I'm pleased with a YouTube video that visually, verbally, and efficiently explains the contents of a paper that costs $33 to read.

</comment></comment><comment><USER33> All this debate of electric vs internal combustion when the article is about a theoretical design that has yet to be proven.

<comment><USER34> Only Consumer Reports can tell us which car is better: One with batteries that don't exist, or one with a gas engine that doesn't exist

</comment></comment><comment><USER35> Between this, camless motors, motors that can switch between different combustion cycles and variable compression ratios there is technically still a lot of improvement to be had. Whether or not the political climate will allow those improvements to come forth is unfortunately uncertain

<comment><USER36> I think it's less a matter of political climate and more just that these improvements are "too little, too late" when electrics are already taking over markets.

How long would I need to wait for these theoretical improvements to go from lab to reliable, mass market cars? Why aren't they here already, why would I wait a decade or two (for what, a 10%-20% improvement?) if I can buy a full electric car tomorrow?

I don't object to improvements, but it's a race, and it seems like ICEs are losing that race unless they can do something impressive on a very short timescale.

<comment><USER35> ICE motors have been evolving for over a century now so the improvements will become ever smaller. Despite that slowdown in progress, the energy density advantage of fuel over batteries still vast. Regulation should, in my opinion, be be aggressively pushing towards reducing vehicle size and weight instead of focusing on the fuel. Having a 2 ton car to move a 60kg person from stop light to stop light is just insane

<comment><USER37> _Having a 2 ton car to move a 60kg person from stop light to stop light is just insane_

That is solely determined by the energy required. And there is, where the electric car excels. A Tesla uses less than the equivalent of 2l of fuel for 100km or in other units achieves 120mpg. In situations you describe, it fares even better, as 60% of the kinetic energy built up is gained back when braking using the electric motors. So mass is much less a problem with electric cars than with combustion engines, which can't recuperate the kinetic energy.

<comment><USER9> Electrics are great for low-speed stop-and-go. They're not as good on a highway, though. 0% of the energy spent displacing air at 70mph is recovered.

<comment><USER37> They are still better than any car with a combustion engine at highway speeds. They don't recuperate while driving at constant speed of course, but still they have the greater efficiency of the electric motor vs. the combustion engine. Usually they have better aerodynamics too. But the weight doesn't play a role there, only making the cars physically smaller - less air resistance - would improve the energy consumption at highway speeds.

</comment></comment></comment></comment></comment></comment><comment><USER38> Would a 14% increase in thermal efficiency translate into a meaningful reduction in carbon emitted per mile driven? This is interesting technology, but I'm not sure it will prolong the internal combustion engine, at least as far as mass market consumer transportation is concerned.

<comment><USER39> I'm thinking this might have interesting applications as a range extender of EVs, like e.g. available for the BMW i30. A vehicle with 150-200km electric range and an optional extender could be quite compelling for lots of usecases.

<comment><USER40> Yes, hybrids are definitely a viable use-case. There are also other applications where a combustion engine makes much more sense, especially if this design can be used for smaller engines like chainsaw engines and lawnmower engines.

The article doesn't mention what kind of fuel this new engine uses, but if it can run on ethanol, or synthesized hydrocarbons like E-diesel then this could definitely be a good thing.

<comment><USER3> Chainsaws and lawnmowers _do_ _need_ to go electric now.

They are the ones that ought to go electric first. The easier ones.

<comment><USER3> > Thankfully electricity is not available everywhere, e.g. in the middle of a > forest.

Well, do you easily find a refueling station in the middle of the forest? If you brought spare fuel containers, why wouldn't you bring all-the-same spare batteries?

<comment><USER39> Energy density is probably quite important for something handheld like a chainsaw. I doubt batteries are able to replace that except for some light garden use.

<comment><USER41> 40 volt electric chainsaws are fine for anything under 6 inches in diameter. That covers almost all household use cases as well as many trail thinning situations.

<comment><USER40> Yeah, the current offerings just won't cut it for professional use though, which I suspect account for much of chainsaw emissions.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER42> > _" Of course, it's not like we're going to be seeing entry ignition engines > popping up in road cars any time soon. The method is unproven, and carries a > bunch of unknowns regarding cooling, balancing, and reliability. Still, it's > a sign not all is lost in the world of fuel-powered engines."_

Electric cars are well on their way to proving themselves. This new technology is too late to slow down the electric takeover. Its only use is to make those vehicles that are unable to switch to electric (probably because of fuel density or a need for rapid refueling) cleaner. Which is still useful, I guess. Though I'm hoping they won't be necessary at all.

</comment><comment><USER31> I recall years ago when someone had rediscovered sleeve valves and was going to apply them to small displacement 4 cycles in order to get the weight down to be more competitive with 2 cycle engines.

It wasn't clear that the article author was aware of them either (and in fact I don't think I'd heard of them until the movie Sahara)

</comment><comment><USER43> Jason Fenske's _Engineering Explained_ is an excellent YT channel. I especially enjoy his physics for gearheads.

</comment><comment><USER44> So a multi-chamber diesel. Why should more chambers be more efficient than the single chamber diesel engine? Because per revolution you get double self- ignitions, at the cost of more room and more gas moving around. Hmm, not bad. Bad reminds me on the Wankel. Only better in theory.

<comment><USER45> I'm not sure this [1] is what you're talking about but it reminded me of reading about pre-combustion chambers in diesel cylinders. Interesting stuff.

[1] [https://en.wikipedia.org/wiki/Indirect_injection#Classificat...](https://en.wikipedia.org/wiki/Indirect_injection#Classification_of_indirect_combustion_chambers)

<comment><USER44> Not really interesting. That's from the pre-BOSCH direct injection area. Modern diesel engines are far more efficient than that.

</comment></comment></comment><comment><USER46> It looks like the slider valve is surrounded on all sides by hot air-fuel mixture and combustion gas. Will the fingers of the slider valve need to be lubricated? Might they be lubricated without consuming (burning) excessive oil (with consequent increase of emissions)?

</comment><comment><USER47> Boring. Even an IC engine operating at the Carnot limit would still emit carbon. Convert every IC on earth to a one with theoretically perfect efficiency and we still blast past 1.5deg warming in a few decades.

<comment><USER48> Plus the cognitive impacts of higher CO2, plus ocean acidification, plus the noise and pollution being exhausted at ground level inside cities, plus supporting barbaric regimes that mine the oil.

Just scrap it all and go full electric. Coming out of COVID lockdown is a great time to invest and mandate.

</comment></comment><comment><USER49> Isn't this much like how Diesel engines work? They compress air first to heat it to the point that when mixed with fuel it spontaneously ignites. Maybe glow plugs can make a comeback.

<comment><USER50> It sounds somewhat similar to a supercharged two-stroke design like the formerly very popular Detroit Diesels (8V71, 6V92TA, for example). None of those engines were very efficient though.

Also, glow plugs are only used for starting.

</comment></comment><comment><USER23> So how does this efficiency compare to gas turbines? Should gas power plants switch to this if it pans out? Or it might be good for portable generators.

Does two stroke mean it won't need oil changes?

<comment><USER51> > Does two stroke mean it won't need oil changes?

This is not the same kind of two-stroke engine. The one you're thinking of pumps the fuel air mixture through the crankcase, which is why it cannot use the same oiling system that a typical four-stroke engine does. The oil would be diluted with fuel pretty quickly, and also carried into the combustion chamber and burned off. So adding the oil to the fuel is how you get around that, but then you're constantly burning oil.

</comment></comment><comment><USER52> How would the ignition piston be preheated from a cold start?

<comment><USER53> Glowplug?

</comment></comment><comment><USER54> Is this patented?

</comment><comment><USER55> How dare you!

</comment><comment><USER56> Clutching at straws to make dead dinosaurs go boom!

<comment><USER57> Oil isn't from dinosaurs that's a myth.

[https://www.thoughtco.com/does-oil-come-from- dinosaurs-10920...](https://www.thoughtco.com/does-oil-come-from- dinosaurs-1092003)

</comment></comment><comment><USER3> \- Hi, I've found an improved NP primality test algorithm!!

\- Uh, but, years ago, a P algorithm has been found...

\- Yes, but if you want to stay in NP, I have a better one!!

This is the way I feel...

We have a 0 emission motor -- electric engine--

and people telling us that, if ever we would not like to use 0 emission, then they have a better IC engine...

<comment><USER9> ICEs have a lot of life left in them yet. Hydrocarbon fuels are energy-dense and easily transported, stored, and transferred. It will be a long time before every use case can be practically and economically covered by electric motors.

<comment><USER3> Electrons are energy-dense and easily transported, stored, and transferred. That's probably what a lot of people have missed about the technological revolution that just happened.

> ICEs have a lot of life left in them yet.

> [...]

> It will be a long time before every use case can be practically and > economically covered by electric motors.

Let the near-future prove you wrong on both statements ;)

The maximum density of Li-metal batteries [edit: still an immature tech] is around 14 MJ / kg, whereas gasoline is the highest energy-density fossil fuel at 47.5 MJ / kg. This is not a huge gap at all.

<comment><USER58> Wikipedia says energy density of Li ion batteries is around 0.5 MJ/kg, which is about 100 times less than hydrocarbon fuels.

And no, electricity isn't easily stored nor transmitted compared to hydrocarbons. Electricity, of course, does have a number of major advantages which is why we use it.

<comment><USER3> Yes electricity is more easily transmitted than fuel. Compare: pipeline vs electric line.

And no I'm not speaking of Li-ion. Sorry but I was speaking about Li-metal, a still immature technology.

So that weakens my argument. On the other hand, that shows that the path to improvement is huge, and could why not surprise us by becoming better density than fuel.

<comment><USER58> > Yes electricity is more easily transmitted than fuel. Compare: pipeline vs > electric line.

Lets do that. High voltage electricity transmission has losses about 4% per 1000 km (HVDC somewhat less, but is a point-to-point system so less flexible than the common AC transmission). By comparison the pumping power required for transporting liquid hydrocarbons is less than 1/10th of that. Also, a high voltage transmission line is an eyesore requiring about 50m wide right of way, whereas a pipeline of equivalent capacity needs a much narrower corridor.

I'm not saying we shouldn't go for electricity, but we need to be frank about the upsides and downsides. (Most experts seem to agree that in order to decarbonize our societies the basic recipe is to 1) Clean up electricity generation. 2) Electrify everything.)

I used Li-ion for the battery comparison, since that is the best rechargeable battery technology that actually exists. I'm highly skeptical that a new battery technology with two orders of magnitude better energy density is possible. It's very hard to get anywhere close to the energy density stored in the chemical bonds in fuels. Or, well, yes we do know of fuels with better energy density than chemical fuels, namely nuclear fuels.

<comment><USER3> I could be wrong, but seems like a pipeline is extremely hard to build, with lots of volume of material, concrete or steel. It seems lighter and easier to build an HV electric line. I see HV lines everywhere, but very few pipelines.

Also, pipeline operations (leakage etc) seem a PITA.

That was my idea behind thinking electricity is easier.

However, the sheer ratio {transport energy} / {transported energy} is indeed in favor of pipeline, as you mentionned.

\--

I found that you can bury HV lines: [https://retasite.wordpress.com/burying- high-voltage-lines/](https://retasite.wordpress.com/burying-high-voltage- lines/)

I found that it costs between $2.9 million and $13 million per mile to build a new pipeline, whereas it costs $285,000 per mile for a HV line and $1.5 million per mile if you build it underground.

</comment></comment></comment></comment></comment></comment></comment><comment><USER59> Our climate doesn't care if the engine is 14% more efficient. That is still vastly too much carbon emission for people or goods to move from A to B. Consider every time any ICE engine moves anything, those emissions will warm the planet for millennia. We can not afford to use these destructive engines, even though fossil fuel interests make them slightly less damaging.

We must have a sustainable transport system, which ultimately means using non- fossil derived fuel. That means way way better batteries, fuel cells, or other up and coming solutions. Any iteration on ICE is just kicking the can down the road.

</comment><comment><USER60> Why is this not a welcome change even considering the supply chain difficulties ? The thing is combustion engine fumes make up for a tiny fraction of carbon emissions. The major part is from industrial production (like cement factories, steel plants etc.) In fact, electric vehicles will only help if the electricity powering it was generated from renewable sources which is a significant fraction in certain countries but not most. Considering these facts I guess good combustion is still a welcome change.

<comment><USER61> >In fact, electric vehicles will only help if the electricity powering it was generated from renewable sources which is a significant fraction in certain countries but not most.

That statement is false. If an EV is run on electricity generated from coal only, the overall emissions output is close to that of a comparable ICE car [0]. Introduce some friendlier methods into the mix and your beating ICE by quite a margin.

The main source of emissions from an EV come from the manufacturing process. Even those can be significantly reduced when proper methods are applied.

[0] [https://www.forbes.com/sites/jamesellsmoor/2019/05/20/are- el...](https://www.forbes.com/sites/jamesellsmoor/2019/05/20/are-electric- vehicles-really-better-for-the-environment/#48b8b99776d2)</comment></comment>


Show HN: Listen to an NP-Complete Problem - <AUTHOR> https://github.com/howonlee/audible-cos <comment><USER2> Really cool idea, any other uses of converting to sound besides its novelty? Don't mean offense, just genuinely curious.

<comment><AUTHOR> Absolutely no use that I've found so far

</comment></comment><comment><USER3> It's funny the sample outputs sound like laundry machines. Have you tried other portions of the input space so far?

</comment><comment><USER4> What does the pi-like symbol on the left mean?

<comment><USER5> It's a capital pi, used to denote a product: [https://en.wikipedia.org/wiki/Product_(mathematics)#Product_...](https://en.wikipedia.org/wiki/Product_\(mathematics\)#Product_of_sequences)

</comment></comment><comment><USER6> It sounds solvable in polynomial time. In all seriousness, cool idea!

<comment><AUTHOR> Number partition, if you present it to someone who isn't familiar with it, is probably the easiest sounding NP-complete problem. In practice, it's definitely one of the easiest ones for practical applications. There' a paper entitled "The Easiest Hard Problem: Number Partitioning"([https://arxiv.org/pdf/cond- mat/0310317.pdf](https://arxiv.org/pdf/cond-mat/0310317.pdf)). But it reduces to subset sum, so it's not easy.

<comment><USER6> Thanks for the link.</comment></comment></comment>


10 'Harmless' Habits to Drop If You Want to Be Successful - <AUTHOR> http://dozzyblog.com <comment><USER2> Actual link to the article: [http://www.dozzyblog.com/2017/04/13/10-harmless- habits-drop-...](http://www.dozzyblog.com/2017/04/13/10-harmless-habits-drop- want-successful/)</comment>


The new quantum reality - <AUTHOR> https://www.wired.com/2014/06/the-new-quantum-reality/ <comment><USER2> 2014</comment>


The Elements Of Style: Unix As Literature (1998) - <AUTHOR> http://theody.net/elements.html

<comment><USER2> My personal experience as a UNIX convert - straight from a Liberal Arts background - forged by years of intuited computer know-how seems to bear this out.

I haven't had much use of this yet, but supposing others aren't aware of it, people like to share their cli gems here: [http://www.commandlinefu.com/commands/browse](http://www.commandlinefu.com/commands/browse)</comment>


From C# on Mono, to Clojure on the JVM - <AUTHOR> http://blog.agilehead.com/content/from-c-on-mono-to-clojure-on-the-jvm/ <comment><USER3> His opinions about the merits of python vs lisp vs clojure seem based more on rumour and the current lisp/clojure kool-aid than on hard-earned hands-on experience. I love Lisp when coding by myself and Clojure sounds really interesting, but Python is currently rock solid and a better fit for real- world team based development. And it's fine for functional programming, contrary to the strange opinion in the article that Guido is well-known to be 'against' functional programming !?

<comment><USER4> Is there a significant reason, other than preference, that Python is a "better fit for real-world team based development" than Clojure or any Lisp dialect?

Python supports functions as objects that can be passed around, but that does not make it a FP language. Functional programming is about constraining mutability and declaring what you want, now how. Python does not lend itself to that style of programming.

Guido has spoken out against map/reduce/filter, lambda, and TCO in Python so many people interpret that as him disliking FP. I think it has more to do with Guido's aesthetic and Python's design principles than anything else.

<comment><USER5> I'll give one reason why Python may be better for _team_ development than clojure/lisp: powerful macros. They do make it harder to reason about code you didn't write. In Python, you can look at the _inside_ of a function and have some idea what it is doing.

"It's doing kwyjibo(i,v) to all the i in zqmfgb. Now, lets see what v and zqmfgb are."

In clojure, that isn't always the case. An example: recently, I was trying to write an OpenGL app in Clojure. I found the following code on the net (pretend it was written by a team member):

        (doto obj
            (.glBegin ...)
            (.methods ...)
            (.glEnd))

I decided I wanted to factor out the (.glBegin ...) and (.glEnd). Aha, this is a job for macros!

        (gl-begin-end body) ; this should macro expand to:

        (do
            (.glBegin ...)
            body
            (.glEnd))

This would just fit inside the the doto, and be exactly what we need. The problem is that doto significantly modifies it's contents:

        (doto obj
            (.method x)
            (.method y))

        (clojure.core/let [G__1206 obj]
            (.method G__1206 x)
            (.method G__1206 y) G__1206)

So I got this: (doto obj (gl-begin-end body))

        ;macroexpand once
        (clojure.core/let [G_1725 obj]
            (gl-begin-end obj body))

        ;macroexpand twice
        (clojure.core/let [G_1725 obj]
            (do
                 (.glBegin ...)
                 G_1725
                 body
                 (.glEnd)))

Obviously this didn't work.

In this case, the problem is me: `(doto obj body)` is idiomatic clojure, and I should have known about it. On the other hand, `(kwyjibo obj obj2 body)` could be very hard to figure out and modify.

I should, however, raise the caveat that I'm not a good enough lisp programmer to know if this is really a problem in practice.

<comment><USER6> _[Macros] make it harder to reason about code you didn't write._

No, actually, they don't. Given the usual high quality of your comments, I'm surprised you would repeat this canard.

 _you can look at the inside of a function and have some idea what it is doing._

This is just as true of a macro. In fact it's more true: you can expand a macro in place on your code and see what it is doing, a maneuver there is no exact analog to in functionland. The macroexpansions in your example make it immediately apparent what the problem was.

Macros are different from functions. That's why they're useful. I'd encourage you to stick with the learning process. The key difference with what you were expecting is that macros control the evaluation of their arguments.

<comment><USER5> Macros do more than just control evaluation of their arguments (although that is often their primary use). If you simply want to control evaluation, you can do that with controlled laziness and functions. Macros can rewrite your code.

To understand a line of code, you must understand enclosing sexps before you can understand what the line of code does. In a macro-less language, that is not necessary. It is something extra you need to think about (and I agree that C-x C-m helps), and that makes it harder to reason about.

I never said they aren't useful (and I'd strongly disagree with someone who did). It doesn't change the fact that they can make understanding code harder.

<comment><USER6> _Macros do more than just control evaluation of their arguments_

Yes, but I was commenting on your example: it was what the macro was doing to control evaluation that caused it to depart from your function-centric intuition.

As for the general point - that macros "can make understanding code harder" - I haven't heard any argument that doesn't apply just as much to functions _mutatis mutandis_. A function adds complexity too. You have to understand its name. You have to know what each of its arguments is there for. To truly understand a function, you may have to look at its source code. Therefore functions can make understanding code harder!

Except, of course, that they make it _easier_ , assuming they're used properly to organize a program, and people who have experience with them consider them indispensable. Same for macros. Most of the objections people bring up are exactly this sort of pseudo-argument that, if it were true, would in fact be a reason to avoid higher-level languages.

If you're really making a general claim to the contrary, please come up with more than a single trivial example that is confusing only at the beginning of the learning curve.

<comment><USER5> My specific argument is about _locality_ , not abstraction.

A function call (in a lexically scoped) language without side effects can be completely understood only by looking _only_ at the function definition.

A function call with side effects now requires extra knowledge: you need to know the state of the world (or some subset) before it is called. Side effects make a program harder to reason about, and can pose a problem in a team.

Similarly, a function or macro call (ignore side effects) also requires extra knowledge: you need to know not only the definition of your function/macro, but also the definition of all macros enclosing the current one. This also makes it harder to reason about.

So my argument "favors" Haskell over Python and Python over Lisp. It also favors Haskell over Liskell, and Clojure over Elisp (due to lexical vs dynamic scoping).

Regardless, I'm not trying to advocate against lisp use. I'm just making a point that the non-locality of macros can make it harder to reason about, and that could be a problem in a team environment.

<comment><USER6> I have to correct something I said earlier:

 _it was what the macro was doing to control evaluation that caused it to depart from your function-centric intuition_

I took a closer look at the example and now see that it had nothing to do with evaluation. Sorry about that. Clearly, the problem was that doto was transforming _(gl-begin-end body)_ into _(gl-begin-end obj body)_ because of an assumption that the forms passed to doto are always OO method calls.

Yuck! Now I understand your complaint about the enclosing form transforming the enclosed form in an unexpected way. What doto is doing there strikes me as just wack from a Lisp point of view. I can't think offhand of many (any) macros that modify the forms they enclose while still evaluating them. Obviously this is completely non-composable. No kidding it leads to unexpected behavior.

What's going on here doesn't have so much to do with macros in general, but rather an impedance mismatch in Clojure between the Lisp side and the Java side (and perhaps ultimately between FP and OO). It's a non-issue in CL - <USER2> much so that I completely missed the point until the third time I read your example. It makes me wonder how many other such mismatches Clojure must inevitably be afflicted with.

I'd still argue, though, that you're drawing a false conclusion about macros in general. The problem with _(doto obj (gl-begin-end body))_ is very much with the definition of DOTO. It has a weird side-effect, true, but one which is still local: it affects the form it encloses, not one which encloses it. The cognitive burden here is analogous to functionland: in order to understand f(g(x)) you have to understand both f and g. f might do something weird that violates the intention of the author of g, but understanding this is incumbent upon the author of f(g(x)), not the author of g. Of course the real culprit may well be the author of f for writing something prone to unwelcome surprises.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I must have missed something about this platform transition.

First and foremost, where are his customers in all of this? Languages are tools to reach goals for humans. What goals did he not accomplish because of using Mono and C#? What specific business objectives were impaired? How would these goals be more easily achieved now?

Secondly, I find it odd that a position on patents would work it's way into a tools choice without there being some kind of firm evidence of trouble. Did Microsoft's decision change the technical environment? Were there problems with building or maintaining code? Or did Microsoft just tick off the open source community and that made him decide to change? Perhaps I missed something, but it was sounding like he was making platform decisions based on some kind of popularity contest or imagined threat. Like I said, I'm ignorant here. Perhaps Microsoft's move has real-world ramifications? If so, I didn't see them in the article.

Finally -- what about F# on mono? You've got all the functional programming you can throw a stick at. And you've got objects as well if you want them. I didn't see that come into consideration at any point, although it seemed relevant -- if his interest was functional languages.

I also found the comment about the .exe and .dll file extensions weird. So people think they're strange? So what? Once again, what does this practically mean to developers or maintainers? Did it cause real problems? Or does it just look bad?

Language and platform discussions always come down to defining criteria: you determine what criteria are important to you and make your decision around that. Sometimes it's speed or conciseness. Sometimes it's availability of programmers. Sometimes it's ability to grow and maintain large code bases.

Whatever the criteria, you have to establish them and the stick to them. I prefer "ability to provide value to customers as quickly as possible" over things like "ability to run in parallel" or "ability to easily find programmers", but to each his own. There are great arguments to be made for all kinds of criteria.

What I didn't see was what exact criteria was being used. Sounded more like somebody just chasing whatever was trendy at the time.

<comment><USER8> "How would these goals be more easily achieved now?"

I feel the guy's pain. Of all technologies we use at our company, the Java folks are the ones that take the longest to deliver a functioning product. I wouldn't be surprised if productivity under Mono/.NET was similarly problematic.

"Or did Microsoft just tick off the open source community and that made him decide to change?"

It's very unlikely Microsoft holds patents that threaten MySQL, PHP, Django, Rails or Clojure users. I would guess their patent-space overlaps quite nicely with Mono.

"F# on mono"

If Microsoft's empty threats scare you or your costumers, F# is not an option.

"I also found the comment about the .exe and .dll file extensions weird."

It _is_ weird. Only Windows uses such an odd convention. I think VMS used something like it. OS/2 too, but it is every bit as dead as we joke BSD is (it is not - I use it - calm down, *BSD people).

"Whatever the criteria, you have to establish them and the stick to them", "Sounded more like somebody just chasing whatever was trendy at the time"

Criteria can change. Rails and Django may be "trendy", but that "trendiness" happened because those who use them can deliver applications very quickly, faster than, say, JSF or ASP.NET MVC - It's derived from real-world results. "ability to easily find programmers" is nice, but if you can't train programmers in a language to make them functional in a week, you are probably training the wrong ones.

</comment></comment><comment><USER9> Thanks. Having actually used Mono on Linux, he shared some interesting observations. Clojure surely looks promising, but Python or Scala can be equally fine choices as of the moment.

</comment><comment><USER10> If I need to run my programming language to run on top of the infrastructure of another program language to use its services, the designers made something wrong. Today larger applications are based on layers communicating with each other over all kinds of ways. Deeply embedding is just one way.

I also think that developers should do more than read books to evaluate a technology. Reading Lisp books is surely not sufficient - eventually the author now was able to use a Lisp dialect and not only read about it. The author is also mostly guessing that 'Clojure has all the benefits of LISP' without having used other Lisps.

<comment><USER11> I've used other Lisps to write production code, and I'll say that Clojure has all the benefits of the Lisp family. Certainly, specific other Lisps have their own advantages. I miss Common Lisp's method combination whenever I use _any_ other language.

<comment><USER10> can Clojure now save images?

does it have CLOS? I thought a huge different to many Lisp dialects is that Clojure is not especially object-oriented. In contrast to most CL implementations (and other Lisp dialects like ISLisp, many Scheme implementations, ...), which are very object-oriented - using many CLOS-based libraries.

can it compile to C?

can I use it without the JVM?

does it start up in less than ten ms?

programmable reader?

more powerful exception handling for interactive software?

tail calls?

etc. etc.

I'm not saying that you need all that, but saying that Clojure has all that a typical CL implementation or what some of the more advanced Scheme implementation offer would surprise me...

<comment><USER11> None of the features you cite are general features of the Lisp family of languages; they are features of specific Lisps. Clojure has its own unique features that are absent from other languages, including Common Lisp. To be specific:

Clojure has multimethods with arbitrary dispatch functions as well as user- defined hierarchies that provide more flexibility than CLOS in many situations. There's no inheritance, but you can copy a structmap.

I do miss method combination and the programmable reader from CL, but I love that the standard library is largely defined in terms of generic functions, that lazy sequences are assumed by default, that every data structure is immutable, but still reasonably fast.

The perfect Lisp has not been written and probably never will be, but I certainly feel like I'm writing Lisp, and not some other language with Clojure.

<comment><USER10> if you say:

       Clojure is a member of the family of Lisp languages

       x is the set of features that all the members of the Lisp family share

       Clojure has all features in x

then this is trivially true and not surprising.

But if you compare the specific language and implementation called Clojure with, say, the specific implementation Clozure CL (CCL), then I would say that there are quite a few features (and their benefits) of CCL that are both available in a lot of other Lisps (for example direct support for object- oriented programming or the ability to save and restart the state) that Clojure lacks. Also true, Clojure has a few features (especially features that are not widely shared among Lisps like STM) that CCL lacks.

</comment></comment></comment></comment></comment><comment><USER12>
      "Although I was unable to use LISP in any production code"

Does he refer to LISP 1.5?</comment>


Announcing AeroPython - <AUTHOR> http://lorenabarba.com/blog/announcing-aeropython/

<comment><USER2> What's interesting is that Python makes the learning process more interactive, you can easily move points, change parameter values, create multiple sources and sinks, etc. and instantly see the results.</comment>


HTree Upto 57% faster data indexing - <AUTHOR> Hi there
I am Hemen, I discovered a patentable algorithm called hTree (http://htree.space). It provides upto 57% faster data retrieval compared to binary search tree. Faster data retrieval means cost time saving. As estimated it can save computational energy by one nuclear power station per year. I believe this is big change.
Looking for the funds in my venture. It will be great if anyone can connect me with someone who is interest in this field.
Here is my contact detail for detailed business plan and funds requirements.
Hemen Ashodia Inventor/founder hTree email@example.com
Thank you <comment><USER2> This is just free advice. Build a disk based index then compare with industry standard database storage engines under real world conditions. Compare your work to others in the field such as Tokutek's fractal tree. If a certain index is faster in one specific way most likely it is worse in others, such as creation time, resource requirements, etc.

<comment><AUTHOR> Thanks for the advice. Complexity is not much different than bTree for creation of hTree. interestingly there is more than 95% probability that the index is going to be faster than the existing btree.</comment></comment>


PayPal to lay off 325 employees and 120 contractors - <AUTHOR> http://www.businesswire.com/news/home/20121029005442/en/eBay-Plans-Q4-Restructuring-Charge-Related-PayPal

<comment><USER2> What exactly were all those people doing? I've been using PayPal for years and it looks, feels, and works exactly the same now as it did five years ago. The process to setup Buy Now buttons hasn't changed. The complexity of setting up the advanced payment system hasn't changed.

So what exactly were those guys working on to actually improve the business for their customers?

<comment><USER3> My thoughts as well.

Other than the recent front end redesign, PayPal's interface and overall product has not changed since I started using it 5 or 6 years ago.

<comment><USER4> Has that made it any less usable?

<comment><USER3> In my opinion (and experience), it was barely usable the first day I started using it. I'd think by now they'd have thought about making it any amount of slightly more usable.

</comment></comment></comment></comment><comment><USER5> Serious question: How does laying off 325 product and technology employees get presented as speeding up how products are developed? Is there a kernel of truth hiding there, or is that just a polite complete lie?

<comment><USER6> Cutting back on bloated tech staff could absolutely help speed up new product development for all the usual Mythical Man Month reasons.... in theory.

I've never seen it work in practice. In practice, in my experience, layoffs never target exactly the right set of dead weight. Company politics always come into play and you end up with a situation where some of the right people got axed, but not enough and worse sometimes the layoffs hit people who are actually great producers but who weren't visible enough to upper management to be spared. And once this event occurs it tends to have a ripple effect among the survivors -- nobody really feels safe and so everyone starts considering other opportunities and naturally your best talent has the easiest time of landing new jobs so they're among the first out the door, and now you're on a downward spiral of fucked.

<comment><USER7> I experienced this exact situation a few weeks ago. Fortunately, I wasn't laid off but it did spark incentive for me to find a new employer. I landed a great position at a new company a couple weeks later and feel much happier now. I've heard through the grapevine that the megacorp I worked for is now in the downward spiral of 'fucked'.

<comment><USER8> Yea I did a similar thing, but once I got the new job with an awesome raise, it made me think - "should I have applied and interviewed at a lot more places if it was that easy?"

</comment></comment></comment></comment><comment><USER9> another anonymous video yet to be published?

</comment><comment><USER10> My first reaction: PayPal employed more than 450 people?

Apparently, yes. According to Wikipedia in 2007 they employed 2000 people.

<comment><USER11> I think not 450 it is about 10% of the company. Don`t forget that they employ worldwide and it is interesting where they will lay off in the US or abroad.

</comment></comment><comment><USER11> dear PayPal, please improve the UI design of your site. :)

</comment><comment><USER12> I believe (although I have no inside info to support the theory) that this is part of a push at Paypal to respond to the challenges presented by smaller, younger, more agile competitors like those at Stripe and Square.

Add to the fray Apple's Passbook and I think that Paypal is scrambling to secure their ecommerce throne.

</comment><comment><USER13> Nothing against these employees, but PayPal is a bad company and needs to die</comment>


- - <AUTHOR> - <comment><USER2> Just take your dog to a nearby park. You'll meet tons of dog owners in person...best social network... does everything useful have to have another useless "social network" ? His about one for cat or parrot owners? At least they won't go to a park with their pets.</comment>


Show HN: My first Android App - Audio Bookmark - <AUTHOR> https://play.google.com/store/apps/details?id=com.gatekeeper.audiobookmark <comment><AUTHOR> HN newbie here, a friend suggested that I post my new app here for critiques/comments.

It's an audio book player, focusing on being simple and intuitive instead of feature-rich and customizable, for less technologically adept users. It remembers the last played location for each album, and also allows the user to create bookmarks for any location in an album.

Thanks!

</comment><comment><USER2> I use audible on my phone, and for the most part ti works just fine. What added value are you building with this app?

<comment><AUTHOR> As far as I can tell, audible only works with audio downloaded from Amazon, as my app will work with any audio file that is playable by the device. Also, I have met a few people who own Android devices but are a bit overwhelmed by apps that have a lot of customization features. I actually made the app initially for my fiancee who has a lot of audio books in mp3 format, and wanted something as simple as possible.</comment></comment>


How To Keep Your Startup Healthy - <AUTHOR> http://thinkspace.com/how-to-keep-your-startup-healthy/

<comment><USER2> Great article. Something I think is missing is regular 1 on 1 sessions between managers and employees, as well as between co-founders. As the article points out, stress has a big impact on health, and one great way to relieve stress, solve problems in the workplace and help your employees grow is to provide a regular forum for feedback, coaching and airing of grievances.</comment>


Redux can be this easy - <AUTHOR> https://github.com/anish000kumar/redux-box <comment><AUTHOR> If Redux boilerplate and the overwhelming ecosystem around it has not been clicking for you, you would love the expressive and clean approach provided by Redux-box, which let's you manage state expressively, without any noise</comment>


LinkedIn, Twitter announce partnership - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2009/11/11/BU911AI6K0.DTL <comment><USER2> More details on the LinkedIn blog: [http://blog.linkedin.com/2009/11/09/allen- blue-twitter-and-l...](http://blog.linkedin.com/2009/11/09/allen-blue-twitter- and-linkedin-go-together-like-peanut-butter-and-chocolate/)

Basically:

On LinkedIn, there will be a "Tweet this" button.

On Twitter, add #li or #in to your tweets

</comment><comment><USER2> The partnership doesn't make much sense to me. On the scale of business to personal, the two sites couldn't be much farther apart.

<comment><USER3> Reid Hoffman says that the Internet version of "Location, Location, Location" is "Distribution, Distribution, Distribution". And Twitter gets distribution right.

</comment></comment><comment><USER4> Maybe I'm missing something, but couldn't LinkedIn add this functionality using the API anyway. Why the partnership?

<comment><USER3> Many LinkedIn users know what a "partnership" is. Fewer of them know what an "API" is.</comment></comment>


A two minute tour of Airfoil: A/B tested landing pages built on Backlift - <AUTHOR> https://blog-colevscode.backliftapp.com/entry/airfoil-launch

<comment><USER2> Just a heads up: Airfoil is a popular application for playing music on Airplay devices by indie dev Rogue Amoeba. Not sure if you/they were aware

</comment><comment><USER3> This is cool. However a few points:

1 - Most small variations on A/B landing pages do not show conclusive uptick. You usually need to do drastic changes to see a big difference. I wonder if the managing one code it would be messy or is there a way to have two or more different files?

2 - Many organizations have a problem understanding how much better one form is performing if they have low volumes. Is there statistical presentations that with C confidence can tell A is better than B.

3 - Sometimes is great to do A/B/A or A/B/C does your tool provide that?

<comment><AUTHOR> 1) One of the advantages of Airfoil is that you can significantly change the design and structure of your page, rather than just superficial changes to copy, colors etc. In my opinion it's much easier to make drastic changes directly to the HTML rather then messing around with an in-browser WYSIWYG HTML editor. Of course you can also use our variant tags to change what javascript is loaded, drastically effecting the content of single page apps.

2) We rolled out two variants for the headline copy on airfoil.io, and even in our relatively small sample set (less than 2k uniques so far) we've seen a dramatic difference in conversion (25% vs 10%)

3) You can add additional test cases, and change probabilities, by editing the app's config.yml file. The relevant configuration might look like this:

      variants:
        a: 0.2
        b: 0.2
        c: 0.6

<comment><USER3> >3) You can add additional test cases, and change probabilities, by editing the app's config.yml file.

Nice! Will your dashboard take the ratios to account when helping the user see which design is performing better and also show the confidence interval?

<comment><AUTHOR> Backlift's analytics dashboard is simple and useful for quick analysis and tuning during a launch. In addition all the code for the dashboard is in the /admin folder, so it can be extended if needed.

<comment><USER3> So I guess the answer is no?

</comment></comment></comment></comment></comment><comment><USER4> Pricing? Can't find the pricing on airfoil.io or backlift.io.

If it's free, say so. If it's not, you better definitely say so.

<comment><AUTHOR> Currently you can sign up to be part of our premium plan beta. We'll be rolling out pricing soon.

<comment><USER4> Cool. Thanks for the clarification. Nothing stinks more than finding a cool service that surprises you with pricing after you've linked your accounts. It feels like you've been duped. :)

<comment><USER5> I had the same question - there was no mention at all of pricing, current or future, on the website. This was very disconcerting. I need an idea of pricing because that says a lot about the service - such as whether I'm in their target demographic now, or whether the app I have in the back of my mind would be a good fit later, etc.

As it is now, I don't even have enough information to decide whether it's worth bookmarking or not.

</comment></comment></comment></comment><comment><USER6> You guys have a typo on your main page: <http://www.airfoil.io>

"Track with Dasboard"</comment>


New 'chameleon' botnet could be causing advertisers up to 6 mn per month - <AUTHOR> http://www.techcrunch.com/2013/03/19/new-chameleon-botnet-could-be-costing-advertisers-up-to-6-million-a-month/

<comment><USER2> Discussion: <https://news.ycombinator.com/item?id=5400573></comment>


Why JavaScript web applications should embrace traditional URLs - <AUTHOR> http://9elements.com/io/index.php/hybrid-javascript-apps/ <comment><USER2> The fundamental problem with attempting to transparently support querystrings on the client-side -- touched on a bit in this article, but not explained completely, is this:

Querystrings are a server-side convention for URLs containing parameters -- the browser doesn't traditionally parse them. If you ask for document.location.search, you'll get back an opaque string containing the query part that you'll have to parse yourself.

The point of Backbone's router is to be able to transparently support both pushState-based routing, with real URLs, as well as onhashchange-based routing, for older browsers that can't do real URLs via JavaScript. So, if you add querystring generation and parsing support to Backbone's router (as some plugins do), and use pushState, everything starts off looking peachy. But as soon as you run into an older browser, and try to fall back to the hash-based URL equivalent, you run into trouble:

        /app?query=string#home?query=other

... now you have the possibility to have to merge two different sources of query string, and still keep transparent redirects working back and forth between the two schemes.

I'd be more than happy to merge an implementation that supports them -- but that implementation needs to solve this particular problem, and have a relatively bulletproof way of supporting the querystring logic parsed out of real URLs and transferred to the fragment, and vice-versa ... and also has to have a strategy for dealing with URLs of the above breed. The devil, as always, is in the details.

<comment><USER3> > now you have the possibility to have to merge two different sources of query > string

Not really:

      if hashMode and queryStringInHash
        parseQueryStringFromHash
      else
        parseRealQueryString

You don't have to merge. Just if you modify the query string and are in "hashMode" then just push the "real querystring" elements you parsed first into the "hashquery string".

<comment><USER4> The thing is that it has to work cross-browser. If an IE user copies an URL with both a fragment query string and a real query string and then shares it with a Firefox user, the URL should resolve to the same thing (and the same thing the other way around).

Not impossible by any means, but, as Jeremy points out, it involves subtle details :)

<comment><USER2> Right-o. PushState-supporting users copying URLs and sending them to IE8 and IE9 folks is one thing, as is the opposite direction.

In addition, some folks currently like to mount their Backbone.js applications at a root URL that contains a query string, for example:

        todolist.com/app?org=nsa#location

<comment><USER5> > some folks currently like to mount their Backbone.js applications at a root > URL that contains a query string

That seems like the root of the problem. It seems like querystrings could otherwise be solved, but this case would certainly introduce a problem for pushState-incompatible browsers.

Is there a reason this kind of app root URL isn't considered bad practice that doesn't need to be supported? Everything about it seems wrong - now you're trying to put part of the path after the querystring.

<comment><USER6> "Doctor, it hurts when I do this."

"Then _don 't do that._"

</comment></comment></comment></comment></comment></comment><comment><USER7> This article about "Javascript web applications" quickly turns into an article about how Backbone's URL handling is bad. The content is really interesting but it feels kind of passive-aggressive.

</comment><comment><USER8> A problem I have with JS web apps, is that "cool URIs don't change" [1]. While querystrings are a server-side convention, the ability to convert a server- side site into JS without having to rewrite all the old URLs is much more important to me than inventing new URL schemes just for JS apps...

[1] [http://www.w3.org/Provider/Style/URI.html](http://www.w3.org/Provider/Style/URI.html)

</comment><comment><USER9> I'm getting rank sick of the growing number of websites killing the functionality of the back button. That, combined with Chromes senseless refusal to implement opening clicked urls that are on another domain in a new tab, means I'm often forced to click-and-hold the back button to get somewhere. Incredibly annoying.

<comment><USER10> I don't understand at all what you mean. To open pages in a new tab you middle click the link. Pages that automatically open in new tab are annoying. If Chrome has something that stops this, I'm extremely happy. The user should control whether a page opens in a new tab or not, and indeed the user can do that -- left click or middle click.

<comment><USER9> I'm on a Mac, I don't have a middle mouse button.

<comment><USER11> Cmd-click. On a Macbook trackpad or magic mouse you can also set three-finger tap to middle click (with third-party tweaks like BetterTouchTool).

<comment><USER9> > On a Macbook trackpad or magic mouse you can also set three-finger tap to > middle click (with third-party tweaks like BetterTouchTool).

Ick. I hate doing two-finger taps as it is. I don't believe one should need anything other than a pointing device with one button to browse the web effectively. Needing to hack in ways to simulate extra buttons is bad design. Why not use a keyboard then?

<comment><USER12> No, people not using target="_blank" is bad design. It's not Chrome's fault people can't code external links right.

<comment><USER9> > It's not Chrome's fault people can't code external links right.

People shouldn't have to specify which links are external and which aren't, it should be inferred from the URL being accessed. In the rarer cases where the server is saying to open an external link in the current tab or an internal link in a new tab, that should be specified in the HTML. For the people that want specific global behavior. i.e. all new tabs to be opened in current tab, that should be a configuration option in the browser.

<comment><USER13> > all new tabs to be opened in current tab

I think you're confusing links and tabs. I think you're trying to throw a lot of extra logic into the browser that doesn't belong there.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> I wrote a library to help you get there:

[http://epona.karmanetics.com/](http://epona.karmanetics.com/)

</comment><comment><USER15> I like some of Jeremy Ashkenas work (in fact I use some of it daily), but he has jumped the shark with this one.

Another bad sign is that he also removed lo-dash (a better underscore.js clone, that fixes several issues, is faster, passes all the same tests AND also strives to support Backbone.js) from the backbone docs.

<comment><USER2> To try and nip this particular thread in the bud -- I think that forks in general, and Lodash in particular, are great. As CoffeeScript has Coco, Redux, Kaffeine, and LiveScript; as Backbone has Spine; Underscore has Lodash. They're fertile ground for exploring different approaches.

My problem isn't with the Lodash project, just with the unfortunate fact that the maintainer has had some incredibly toxic behavior with respect to cooperating around open-source. Without getting into details, as soon as he's ready to collaborate in a pleasant and productive fashion, he's welcome to have his commit access back to Underscore, and merge in whatever he likes.

<comment><USER16> Hi, creator of Lo-Dash here. Jeremy's comments are off base. I've gladly contributed to Underscore and am responsible for many of the fixes/features in the last few releases. I voluntarily revoked my commit rights to Underscore, without prompting, several months ago because it was awkward trying to move Underscore in a better direction while trying to work with Jeremy, who seemed distracted, lacking the patience to grok issues/comments, often losing his temper in issue/commit comments or trashing me on Twitter/HN. I'd still be contributing via bug reports and feedback if he hadn't recently blocked me.

It's unfortunate he's chosen to spread FUD instead of going head to head on features, compat, perf, dev needs/concerns, or any other relevant area of project comparison :/

</comment></comment></comment><comment><USER17> Bravo. jashkenas's reticence to fully support pushState is really frustrating.

</comment><comment><USER18> This is the third or fourth post I've seen lately on "use the architeture of the web, don't fight it with client-side JS apps." I consider it a welcome swing of the pendulum.

</comment><comment><USER19> Having bashed my head against Backbone's router over the past few months, I've come to the conclusion that pattern based routing is just the wrong approach for picking a view to render the page. Instead, choose a view based on some property of the JSON returned by that URL (I'm using '@type' as our API will expose linked data through JSON-LD.) Now route information only needs to be specified once, server side.

</comment><comment><USER20> For an example web app that works just fine with hashtags, see [https://WakaTi.me](https://WakaTi.me)

Built using patterns from this Backbone.js example:

[http://ahamlett.com/Backbone.localStorage/](http://ahamlett.com/Backbone.localStorage/)

</comment><comment><USER21> I think this a good time to mention URI.js: [http://medialize.github.io/URI.js/](http://medialize.github.io/URI.js/)</comment>


Grass-Mud Horse Lexicon Classics - <AUTHOR> http://languagelog.ldc.upenn.edu/nll/?p=6538

<comment><USER2> For readers not familiar with the background of this post, I should explain that this linguistics blog post links to some Chinese-English glossaries of the punning expressions (often very crude) used to express politically dissident thoughts on the heavily censored microblogging services in China. The "grass-mud horse" is a famous character in a video that was actually publicly released on Chinese-language video-sharing services for a while (because the censors didn't recognize the pun and the political content of the video). The video went viral in China, and now "草泥马" ("grass-mud horse," a pun for "f___ your mother") is a term symbolic of all the puns used on China's microblogging services to express dissent.</comment>


How We Got into Y Combinator - <AUTHOR> http://lloyd.tc/how-we-hacked-the-y-combinator-application-process/ <comment><USER2> There's a lot of great material in this post, but as a recent YC alum myself, I have a number of problems with it.

1) "If you're writing your Y Comb application and it takes you less than a month of work, you're not trying hard enough."

No. You should not be spending that much effort on your application to YC -- or any accelerator. Should you have a few people read it over? Yes. Should you spellcheck? Yes. But not much more than that. Focus on building your product and building your business.

2) "no one's video is under a minute."

Ours was. 50 seconds, to be exact.

3) "But my point is, if your company and team is solid, than you will get in."

This is the most dangerous statement in the post. This is simply not the case. Every successful entrepreneur was told "no" and turned down time and time again on their path to greatness. Facebook got "no's" from VCs. Airbnb's founders were told they were crazy. Many people outright laughed at Elon Musk's dream to build rocket ships. SendGrid was rejected from YC. If you believe in your team, and you believe in your idea, trek on. The YC partners are some of the smartest people I've ever met, but they're not infallible.

YC has been absolutely amazing for my team and my company, and we're very grateful for having gone through the program. But we likely wouldn't have been accepted and wouldn't have benefitted so much from the program if we weren't focused intensely on what matters -- building our product, talking to our customers, and staying healthy. Apply, hope you get in, but if you don't, carry on.

<comment><USER3> As a data point, I was rejected by YC 3 times. Once after the interview, once at the application, and amusingly enough the first time we applied for the last batch. We got in after applying again late with LightTable.

There is certainly no guarantee that with a "solid" team you'll get in. At the end of the day, it's all a matter of serendipity.

<comment><AUTHOR> You were rejected three times for the same company?

<comment><USER3> Nope, they were all different ideas/companies.

Typewire - disqus for liveblogging

Attend.me - conference management software

Prospector - medical chart review

and finally LightTable. Oddly enough we had/have domain expertise for all of them :D

<comment><AUTHOR> If you switched projects four times, I can only assume that the last company, the one that YC accepted, has the most potential... otherwise, you would have continued working on the other projects.

I think it's way more than serendipity. I think the YC staff is extremely good at identifying where good teams and good products meet.

<comment><USER3> This was over a series of years. There are lots of reasons why we stopped working on the different projects, but I'm not sure I believe there was any less potential in them - especially Prospector.

While I agree that they've gotten very good at identifying potential good team/product pairings, that just means they have relatively few false positives. It makes no claim to how many people they pass over who may in fact have an amazing team and product. As the noise in the process increases, you're bound to end up with more and more people who for completely random reasons didn't end up being what they wanted that day. This isn't a purely objective process (thank goodness).

All other things being equal, anything that relies on the judgement of a few people has an element of serendipity to it.

<comment><USER4> I think Prospector sounds very interesting, even only from a three word description. I know three friends running startups in the healthcare market and it's a tough one (with a lot of entrenched interests).

 _"All other things being equal, anything that relies on the judgement of a few people has an element of serendipity to it."_

Also recall that the judgement is made on the basis of a 10minute interview. Ask any of these startups if they'd ever hire a group of strangers into their company based on a 10 minute interview. (I'm aware that's not really a fair comparison, but it should still make people think).

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> I went back and looked at their application to see what we liked about it. What we liked is that they really understood their domain. This was not random undergrads making up some idea about social shopping. These people clearly understood local newspapers.

<comment><USER6> Out of curiousity, do you find that a lot of people applying under RFS don't understand their domain? It seems to me that a lot of those things are things that are both clearly broken, and not yet fixed, which means you get a lot of people from the sidelines saying "Oh all you need to do to fix that is ..." not knowing that the exact thing has been tried and failed dozens of times.

<comment><USER5> A lot of people who apply don't understand their domain, but I've never looked at whether this is more or less true for applications that mention a specific RFS.

</comment></comment></comment><comment><USER7> Looks like they put a lot of effort in here and are excited about what they're doing. Congrats.

But, as an aside, can we please kill the abusage of the word "hacked" because, as far as I can tell, it's being used as a synonym for "did a lot of research and spent a bunch of time on".

<comment><USER4> I've noticed that too. Alas, everybody wants a shortcut -- and the word 'hacked' implies that someone found one (for stories like these).

<comment> brown9-2 I think it also makes the link that much more attractive to readers:

"How we Did A Very Good Job on the Y Combinator Application Process and Got in"

versus

"How we Hacked the Y Combinator Application Process and Got in"

<comment><USER7> There's a word for when you choose a snappier title that doesn't reflect reality to get more clicks.

It's called linkbait.

<comment><USER8> "How we got into YC: by storming the building with assault rifles and smoke grenades!"

<comment><USER9> Now that article I would read.

<comment><USER10> For once "Pics or it didn't happen," might actually be on-topic!

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I'm not sure if this is something good to admit or not, but I only spent about 2 hours writing my YC application, and we spent about 15 minutes planning and filming the video, no editing. The video got 2 views. We got asked to do an interview.

Seems like every "YC Application Advice" blog is about spending hundreds of hours doing an APPLICATION. To me this sounds absurd. If you're really using the time to figure out the direction you want to head, or where your product focus is, then fine. But then it's not really for your YC application, its for your company.

In the end we didn't get in. We didn't have a sound business strategy; our focus was on the product. Nieve, yes, but lesson learned. It was one hell of an experience.

</comment><comment><USER12> Who knew, all this time you just had to add &accept=1 to the end of the URL.

<comment><USER13> Our company is called "DropTable".

</comment></comment><comment><USER14> I'm curious, why did you apply to YC if you were already bootstrapped and bringing in revenue? For the connections?

Unrelated, I like your "Tweet this quote" sidebars...clever idea. :)

<comment><AUTHOR> Because when you start a company, everything is against you. Being a YC company, for the knowledge base and the connections, removes a lot of barriers and opens a lot of doors.

Plus, being two guys from the Midwest, we really didn't know what we were doing. After YC, our path was much clearer.

<comment><USER14> Cool, thanks for the honest response. :)

</comment></comment></comment><comment><USER15> "Y Combinator is the most exclusive thing in the world that you can openly apply to."

I hope you don't actually believe that... if you do, start-up groupthink is definitely getting to you.

<comment><USER16> What's more exclusive that you can openly apply to?

<comment><USER15> There are admittedly a few ways to measure exclusivity and define openness.

If you account for applicant quality in how you measure exclusivity: NSF fellowships, top medical schools, top JD programs, top science PhD programs, many jobs, some country clubs,

The Rhodes and Marshall scholarships come to mind as "most exclusive." They're arguably not "open application" due to age requirements. I suspect YC has an age requirement too, but it is less restrictive (and less explicit.)

If you don't control for applicant quality, then even entry-level jobs are more exclusive than YC. I've been in charge of hiring for a jobs where we made job offers to less than 0.5% of applicants. Which is just to say that acceptance rate alone isn't the right metric.

I think I'm touching on a small sliver of the "most exclusive things" list. The fact that most of the world hasn't heard of YC would also suggest that there are also exclusive programs in other fields that we aren't familiar with.

<comment><AUTHOR> There are literally no requirements to apply to YC, except wanting to be in YC (which implies you want to build something).

Rhodes and Marshall have specific requirements, even your job hire probably had requirements (high-school education, must be able to lift 30 lbs).

That's what makes YC so amazing... anyone, anywhere, can apply.

<comment><USER15> I agree that YC's requirements are more flexible than most jobs.

If you don't have the skills to do statistical modeling, we wouldn't hire you. We gave guidance in the job posting about who was a good candidate. But we didn't prevent anyone from applying.

YC is the same in all those dimensions. If you don't have the skills necessary to build a successful startup, they won't accept you. YC gives guidance on their web page about who was a good candidate. But they don't prevent anyone from applying.

I'm not sure how you define "open" so that one of those qualifies and the other does not. If "open" just means that they have more flexible requirements, that is a difference of degree, not kind.

YC is an unusual combination of selective and eclectic. But claims about "the most selective open application in the world" suggests a lack of perspective.

</comment></comment></comment></comment></comment><comment><USER17> Is 27 really considered that old in the YC circle? Does it actually put you at a significant disadvantage in the application process?

<comment><USER18> I'm 29. Since I finished my undergrad I've gone to grad school, done work for huge companies, small companies, universities, and worked at a startup. I think all of these first hand experiences will prove to be very valuable in my future entrepreneurial endeavors. As always, YMMV.

</comment></comment><comment><USER19> "Besides, getting in Y Combinator is easy: just be wicked smart, create a beautiful product, get millions of users, and build a revenue stream that grows 20% each month."

If your company's revenue stream is growing 20% each month on the backs of millions of users, why are you applying to Y-Combinator?

<comment><USER20> I think they were being flippant.

</comment></comment><comment><USER21> This is not 'hacking' the application process in the slightest. You prepared yourselves well; there's a difference.

But then again, the title got you on the frontpage of HN, which was almost certainly the goal.

</comment><comment><USER22> Insightful article that would have benefited from a less sensationalist headline. "Hacking the Y Combinator Application Process" makes a promise that you fail to deliver on.

<comment><AUTHOR> To be fair, I said "How We..." Did it. Also, I made sure to clarify the point of the post with the beginning disclaimer.

Apologies if you felt mislead. LMK a better title and ill change it. Also, I hope there's plenty of stuff in there that demonstrates how to write a good application.

<comment><USER23> Re: Article Title Suggestion: "Why YC Made Sense for Our Business and How We Got In" or "How I Was Almost Eaten by a Shark (or something equally absurd), but Got into YC Combinator Anyway"

Humor may really help the article to gain acceptance and readership.

</comment></comment></comment><comment><USER24> I know this is Hacker news, but hacking, bootstrapping or kickstarting are slowly becoming meaningless buzzwords.

Please please stop using them for anything.

</comment><comment><USER25> YCombinator is just like college now. Its all about getting in and not about what you're supposed to do when you're there.

lame.

</comment><comment><USER26> I can't imagine spending over a month writing your YC application is something PG would recommend, but I do love the idea of having a few random people explain your application back to you. That's great advice about being sure you're writing is clear in general.

I can't imagine "we're already making money" and the fact that you were doing it monetization journalism (an RFS and a tough one) didn't help you get in more than the clarity of your application though. That seems to be a proof point beyond anything you could have written, to me.

</comment><comment><USER27> Congrats on the win, but:

"...we basically don't have an accent..."

You do. It's called "American". :P

</comment><comment><USER28> The word hacked gets thrown around way too much.

</comment><comment><USER29> This is a good read. You really know what you want, and what to do. Concrete plan. Midwest is still in the US right. It's funny, I just read earlier here in YC an accepted application but failed in the interview.

This is a good example of a YC application but I'm more intrigue with applications outside America, or in Asia. And dealing with what you said as language barriers, culture differences, and also the visa problem.

</comment><comment><USER30> Regarding spellcheck: I noticed the application contains the typo "bolierplate".

<comment><AUTHOR> Ha.. nice!

</comment></comment><comment><USER31> 403 lol jk but seriously.

<comment><AUTHOR> caching error. apologies. up now.

</comment></comment><comment><USER32> I found this useful. Even if the terms are being abused, it always helps to have others perspectives on how they succeeded. Regardless if it doesn't apply to your system/experience, it is still a valid (and successful) method of getting in. Do you need to work for 1 month to submit the YC application? Nope. Did it work for them: Yep. So, as with anything, YMMV but getting as many different perspectives as possible can only help. Hack a bootstrap to get kickstarted.

</comment><comment><USER33> It looks like you, guys, are embarassed by your age. "We're too old - we are already 27". Damn, I thought that you were at least 50 when I read it. As far as I remember, PG told about 26 to be average age for applicants. I'm 27 right now but I'm not going to retire tomorrow - hell, I'm still to young and will be even when I be 40. :)

</comment><comment><USER34> The most interesting part of this, I think, is the tweet buttons with the quotes everywhere. Does that make an appreciable change in terms of people sharing? Or does it just take up a bunch of space?

</comment><comment><USER35> Useful piece. I started breaking down our YC application and rewriting answers and I realised that I could write much of what I've put in a much shorter manor that is to the point.

</comment><comment><USER36> > _even if we don't get in, this trip has convinced us that we're moving out > to the valley to do this full time._

Simply curious, why did you decide to build the company in Austin, TX?

<comment><USER37> Hi, I can't speak for Lloyd. But, as someone else who's building a funded startup here in Austin--and who sits about 10 feet away from Lloyd and OwnLocal every day!--I can answer it for me/my startup.

I ran my last company in the Valley and did really well--I exited for 7 figures. I am building my current company in Austin because I see here what the Valley was in 2002-2004. Growing fast, retooling itself as a startup hub, and building real businesses with real revenue.

Developers are (somewhat) easier to hire here. Salaries and cost of living are lower. No state income tax saves you some good money, too (matters more once you get acquired and/or start pulling down a larger salary.)

Weather is less great, but you do have seasons here, which I can appreciate, having lived in California most of my adult life.

Funding is available, though not quite as easy to get as in the Bay Area. However, I will say, once you figure out who the investors are in Austin, they _love_ to invest in local companies with traction and revenue. And there are venture funds here, as well. In addition to local funds, 500 Startups makes several trips through Austin a year and funds the most promising startups here.

Plus, Austin is a fun city that has a lot of fresh, young energy. Thriving culture, bike- and scooter-friendly, and did I mention you can actually afford to buy a house here? I suppose that's more important for us "old fogies" who are already in our 30's. ;) Oh, yeah, and you can drink beer at the movies thanks to Alamo Drafthouse. Also, if you're a foodie, Austin is epic. I still can't believe the Bay Area doesn't have an equivalent to Central Market.

I wrote a more in-depth blog post before I left for Austin: <http://www.erica.biz/2011/california-im-leaving-you/> And I can safely say that moving here to run a high-growth, B2B tech startup was one of the best decisions I've ever made.

</comment></comment><comment><USER38> > just be wicked smart, create a beautiful product, get millions of users, and > build a revenue stream that grows 20% each month.

If you did this, why would you need YC?

</comment><comment><USER39> _Children are useless until around the age of three. I never thought it would take them thatlong to become real people._

Love this answer.

</comment><comment><USER40> Why does the YC app form ask you to not password protect the demo site?</comment>


Show HN: Spatial data analysis and visualization in Excel - <AUTHOR> http://gisxl.com <comment><USER2> I have a list of ~3000 lat/lng values. Can this plugin create a map out of these?

<comment><AUTHOR> Yes. Without any problem. I use this tool at work with > 15 000 point data- set. Only in the case of KML file export (for Google Earth) it may take longer.</comment></comment>


Ask HN: If programming were an instrument, how would you practice? - <AUTHOR> I'm currently taking piano lessons and I realized that getting better at piano doesn't seem anything at all like getting better at programming. I was wondering what you considered to be the "scales" (constant, methodical, technique practice) and "repertoire" (memorization, themes, progressions) of programming, and how someone could practice these to get better? <comment><USER2> There are a number of articles on this topic coming from the perspective of martial arts rather than music. Start at [http://codekata.com](http://codekata.com) and you'll find good articles. (Note - I am not associated with codekata; just find the idea neat.)

<comment><USER3> And of course (irony warning), the first line on codekata.com says "How do you get to be a great musician?"... sorry, just poking fun.</comment></comment>