Repairing My Tesla Model S Has Been a Nightmare - <AUTHOR> https://www.fool.com/investing/2017/03/07/repairing-my-tesla-model-s-has-been-an-utter-night.aspx <comment><USER2> A few observations:

1\. This is precisely why it's important to legislate right-to-repair. This is why auto manufacturers are required, by law, to continue to manufacture replacement parts for their cars, long after they have stopped being sold. Hopefully, Tesla can get this figured out.

2\. Soviet auto manufacturers had this exact same problem. They were incentivized to sell cars, not spare parts - so finding parts for repairing your broken Lada (Which was just as likely as not to be broken as it rolled off the assembly line) took a breads-and-fishes miracle.

3\. What does this have to do with stock picks... Oh.

<comment><USER3> Why didn't people just make a business of buying ladas and and selling the parts?

<comment><USER4> Soviet Russia didn't exactly support the entrepreneurial spirit.

<comment><USER5> Maybe not in a traditional sense, but they did have a pretty robust black market

<comment><USER6> And as I hear the stories, this _did_ happen. Cars are tough because you can't do a mechanic's job without tools and some obvious space, but there are at least stories of people getting cars and parting them out at a profit. (Similarly, there are stories of tank "repair" in WWII happening by taking finished tanks meant for service and stripping them for parts to repair multiple other tanks.)

<comment><USER4> One of my favorite anecdotes is from an old episode of Car Talk. A woman called in to ask if the following was ok (I'm paraphrasing from memory):

"So my neighbor, who's from a former Soviet Bloc country is a great guy who helps me out when my car breaks down. One time my battery is dead, so he offers to jump start my car. While I look on baffled, then shocked, he unscrews his car's battery from the mounting, then flips it over and presses the contacts _directly to my car 's battery_. It started though! So is that safe?"

To further paraphrase the guys' responses... "Oh god no!!!" They further went on to point out though, that at some point when your life is dangerous and hard as a kind of background state, the little things stop even grabbing your notice.

The degree of black marketeering in the USSR was just... staggering. Systemic. Understood to be "how the system works". Sometimes though you get tragedies like Vladimir Komarov.

 _The space vehicle is shoddily constructed, running dangerously low on fuel; its parachutes — though no one knows this — won 't work and the cosmonaut, Vladimir Komarov, is about to, literally, crash full speed into Earth, his body turning molten on impact. As he heads to his doom, U.S. listening posts in Turkey hear him crying in rage, "cursing the people who had put him inside a botched spaceship."_

[http://www.npr.org/sections/krulwich/2011/05/02/134597833/co...](http://www.npr.org/sections/krulwich/2011/05/02/134597833/cosmonaut- crashed-into-earth-crying-in-rage)

<comment><USER7>
      he unscrews his car's battery from the mounting, then flips it
      over and presses the contacts directly to my car's battery.
      is that safe?

Electrically, it's not all that different from using jump leads - there's the same risk of sparks, the same voltage and load involved.

There is a risk of battery acid leakage from flipping the source battery, but that depends on the type of battery - a sealed unit is unlikely to leak.

There's also a risk of injury from being so close to the engine bay when it's started - say, if your hand came into contact with a moving part like a belt or a fan - but again, that's dependent on the layout of the engine bay, and those risks are generally clearly visible and obvious.

It's certainly not "normal" practice for the western world, but there isn't really all that much risk in it. And it turns out Americans do it too! [https://www.youtube.com/watch?v=dcYjJcEZuOA](https://www.youtube.com/watch?v=dcYjJcEZuOA)

<comment><USER8> Also there's some potential for damage to electronic components like the ECU by connecting terminals in the wrong order (i.e. not +ves first). And sparking. Lots of chance of that, more than jump leads which (unless you're incompetent) aren't going to be making and breaking contact several times while you wiggle the battery around trying to make it fit.

<comment><USER9> The order in which you connect the terminals has nothing to do with preventing electrical damage. The reason why you're supposed to connect jumper cables in a particular order is for safety. When you connect just the positive, it doesn't matter if you accidentally brush the other end of the cable against the body or ground of the other car. Then the only thing left to connect is ground and if you accidentally brush the ground lead up against the body then it isn't going to matter as you're trying to connect that lead to ground. Also, the reason why you connect the last lead to a well grounded part of the engine away from the battery on the god car is because that's the only connection that creates sparks. Sparks around a bad battery are a bad idea. Batteries regularly create some Hydrogen and Oxygen gas, normally it doesn't produce that much at all and it gets vented out of the battery but with a bad battery it might have very little electrolyte left and it might have multiple cells filled with a bit of acid and a lot of explosive gas. If that spark ignites any explosive gases in the battery it will probably crack apart the plastic casing and shower you with battery acid.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> _Copying my post from the reddit discussion:_ [https://www.reddit.com/r/teslamotors/comments/5y3fwe/a_very_...](https://www.reddit.com/r/teslamotors/comments/5y3fwe/a_very_well_written_story_on_what_i_consider_to/denafgc/)

Can confirm. I was in an accident 5 months ago [1] and _still_ don't have my car back. The body shop finally got all the parts a couple weeks ago and finished up the build, but because it's all newer revisions of those parts, the car is refusing to boot up. It's been sent up to Tesla to get it serviced by them.

Honestly, I don't know when I'll get it back at this point. Good thing I got a P90D...

I love the Tesla service folks. They're some of the best. They are just ridiculously overwhelmed.

 _And my follow up comment today:_

Actually, as a follow up, it appears Tesla Decatur (here in Georgia) has gotten to my car today. I have been getting notifications of software update failures from the app over the past few weeks. I just got some failure notifications now and the car says it's at the service center. And I just got a successful update notification, so I guess they've fixed it.

Still, it took about 4 months to go through all the hardware work and end up with this software problem. Tesla Parts was the big choke point in the whole process.

Looks like the Tesla Decatur team is down to a 1 week response time, which bodes well for Elon's claims.

[1]: [https://www.reddit.com/r/teslamotors/comments/55oibb/welp_i_...](https://www.reddit.com/r/teslamotors/comments/55oibb/welp_i_guess_im_getting_a_new_car/)

<comment><USER11> I did not know this existed until recently, but you and the article poster probably have a very good claim for diminished value and loss of use. Basically non use of your high-end car for many months.

I recently created a short online quiz for a law firm in Florida that checks to see if you have a claim. It was a completely new area of law that I did not even know about. It does email your contact info at the end - in case you want to be contacted.

Anyways if anyone is interested it is at [http://www.diminishedvalue.law/quiz/](http://www.diminishedvalue.law/quiz/) and is based on Florida law.

I am not trying to hype the firm. There are other firms that do the same thing. I just happen to know about this one.

<comment><USER12> I think you might have wanted to do some input validation: [http://imgur.com/a/510dc](http://imgur.com/a/510dc)

<comment><USER13> I prefer sites not to validate fields they have no need for programmatic use of.

Every validation has a few users who don't pass. Names longer than expected, people with no surname, phone numbers with an "extension" code, addresses with no house number, email addresses firstname.lastname@example.com, etc.

Validate only what you need to to make your service work, and when you do, use an official validation library rather than baking your own.

</comment></comment></comment></comment><comment><USER4> For me, this is just more evidence that this a highly promising technology that isn't ready for me to invest in yet, as an owner of a Tesla vehicle. That said, even this guy who's had a nightmarish experience is essentially crying out for help, and still considering another Tesla purchase so... that says something too.

I'll wait and see, as I suspect many other people will, and hopefully Tesla can work these issues out before they come to define them.

<comment><USER14> In the meantime, Toyota has plug-in hybrids.

<comment><USER15> And, while arguably not the sexiest of marques, their service organization is brilliant.

Even here (Way out in the boonies, a small island off the west coast of Norway), anything and everything I have ever needed to keep my nigh on 20 year old Toyota running has arrived the morning after ordering at 8AM.

Granted, I haven't needed any really exotic parts - but they still impress me. Heck, the body panels are even available pre-painted as they only imported a few paint codes in that model year!

I can see a number of valid reasons not to become a Toyota owner. Their service organization is not one of them!

</comment></comment></comment><comment><USER16> Not sure how often this happens, but if it is frequent, Tesla should simply offer to take the damaged vehicle as a trade-in toward a new model, and allow the owner to stop making payments until the new car is ready for delivery.

Not a scalable strategy, but surely a blog post like this one does tremendous harm to Tesla's brand reputation and so it's worth having a good (if costly) solution in place.

<comment><USER17> There was another Tesla repair story, where the guy had bought the floor model, or something. It was basically a lemon, and Tesla's solution was to offer to sell him a new car at the difference between the sales prices ($20-$30k, I think).

The people in this story also bought a discounted car. Personally, I'd be loath to spend a car's worth of money to trade "up" to another vehicle from the same manufacturer.

<comment><USER16> > Personally, I'd be loath to spend a car's worth of money to trade "up"

I completely agree. But they are put into a position where the car is completely illiquid as an asset and also offers no transportation value for an indeterminate amount of time, which limits the owner's ability to plan or pursue a reasonable plan B.

If the parts scarcity was expected to last 12 months and the cost of renting a loaner was $200/month, perhaps the owner would turn out to be better off trading it in and taking delivery of a new Tesla.

Another way to handle it would be for insurers to bake in the possibility of a year long wait for parts into the price of collision coverage loaner options. If the scenario is rare this insurance would be cheap.

</comment></comment></comment><comment><USER18> I'm in a similar situation with SolarCity. Although mine is far less dire. There's been a billing snafu on our solar panels ever since we bought our house and took over their lease. We bought it in October. It's now March and they still have not resolved the problem and have no ETA on when it will be fixed. When I researched this issue, I found other customers who said it took 10 months for SolarCity to right the problem.

I get the impression these companies aren't putting as much resources into customer service as they should.

</comment><comment><USER19> I recently had a very similar experience with my Model S, although it was a month as opposed to multiple months that the author faced. I had a front bumper issue, and by all accounts it was a minor collision (car was moving at around 4mph). Needed the bumper replaced, along with parts that sit behind the bumper. Tesla handed it over to a body-shop who (a) sat on it due to needed parts, authorized by Tesla, (b) took time to repair/assemble as only certified (by Tesla) technicians can work on the car, (c) the certification is apparently expensive and time-consuming so most body shops can only afford to have one technician at best to be certified, (d) this leads to large delays

I can't think of an easy solution here -- as an owner I'd like the car back in a shape that's as good as before, and certified by the maker. But the bottlenecks here seem to be with Tesla.

</comment><comment><USER20> This is really unpleasant for the owner, but is fairly typical of boutique cars. If you drive a rare car, parts will be delayed and repairs will be expensive and take a long time.

Only having one repair shop is a problem, but is also due to Tesla being a low volume, rare car.

With the Model E, this should be a little better, but I expect these stories for the next few years. Similar to if you owned a Fisker or Koenigsegg or something, although those are much lower volume than Tesla.

<comment><USER21> I don't know how low volume or rare they are but for about the same $$ as a Tesla I could buy a brand new Mercedes S-class. Likely best service experience one can ever have, not to mention arguably the most luxe car ever

<comment><USER22> Mercedes has also had a hundred years to build up supply lines.

<comment><USER23> From the customer viewpoint, for the same amount of money, one has superior service and one doesn't. History as a rationalization is not a factor when _my_ money is on the line.

</comment></comment></comment></comment><comment><USER24> > _After three months had passed and the body shop had still not received all > the necessary parts, we began reaching out to Tesla directly through their > customer service channels, which serves as a liaison to the internal parts > department._

That's the body shop's job (and failure), not yours. It's one downside of having "authorized" shops with only one in the author's area. In theory, the body shop should have a dedicated representative at Tesla they can talk to directly, and should escalate enough to get the parts long before the 45-day rental period available through the author's insurance limit was up.

> _There were still a few outstanding parts, including bulb rivets._

Bulb rivets are common parts. You might not be able to buy the right ones at the local hardware store, but they're readily available from McMaster, Fastenal, Grainger, etc. And I guarantee that Tesla has buckets of them on hand. Again, the body shop should have taken care of this.

> _It turns out that the 12V battery is also now in need of replacement, as it > will no longer hold a charge (perhaps related to how long the car has been > sitting idle?)._

Did the body shop not know to recharge it occasionally? As far as I know as a non-Tesla owner, this 12V battery is always on, listening for the remote fob, monitoring the main battery, and so on. Of course it would become discharged after sitting for half a year, and apparently so deeply discharged as to damage itself. And as an ICE-car owner, there are other things that must be done to any car that sits for a long time. Perhaps the body shop is better at taking care of conventional cars and lead acid batteries, and just needs a little experience and education about lithium-ion systems?

> _It also calls into question Tesla 's ability to support its existing > customer base, which is of critical relevance to whether or not Tesla can > support a massively larger customer base. The company is still targeting > 500,000 units in 2018. As many analysts and pundits point out, the > mainstream is far less forgiving for this sort of thing compared to > enthusiastic early adopters._

A massively larger customer base is probably easier to support, per customer. There are junkyards full of my exact car, and non-OEM manufacturers and parts stores with huge inventories of parts for it, and people who have repaired hundreds of cars just like mine. When thousands of mechanics have a half-used bag of Tesla panel bulb rivets in a toolbox drawer, things won't be held up waiting for the part. This is something that will probably get better with time, not worse.

<comment><USER25> _That 's the body shop's job (and failure)_

...

 _Again, the body shop should have taken care of this._

...

 _Perhaps the body shop is better at taking care of conventional cars and lead acid batteries, and just needs a little experience and education about lithium-ion systems?_

...

So the game, here, is to direct blame at the body shop and not Tesla?

The body shop Tesla certified?

It seems to me that if there are so few body shops, and Tesla must certify them (presumably to ensure the work is covered by warranty), then those body shops are in effect an extension of Tesla's business and it's perfectly valid to hold Tesla equally accountable for their failings.

<comment><USER26> You are paying the body shop. My thinking is if the body shop isn't doing the job you paid them to do you don't do it for them, you complain to Tesla about their certified body shop.

<comment><USER25> No question about that. But I'd do that _in addition_ to talking to Tesla customer service just to get the ball moving forward... after all, this isn't a crusade for this guy. He just wants his darn car back!

</comment></comment></comment></comment><comment><USER27> The "Auto Dealer Lobby" in Texas has been saying this would happen for a while: [http://www.dallasnews.com/news/politics/2016/05/20/texas- aut...](http://www.dallasnews.com/news/politics/2016/05/20/texas-auto-dealers- receive-tesla-sized-dent-from-state-gop)

I assumed it was just the usual political grandstanding to keep Tesla out. Here we have an example of this happening.

<comment><USER28> That's not quite the same. The dealers there are talking about regular maintenance and repair, not post-accident body work. Tesla already allows third parties to do body work, and in fact won't do it themselves. Getting dealers involved wouldn't help in any case, since the problem is getting parts from the manufacturer.

<comment><USER29> And what's funny is I've been to a lot of dealers that refuse to touch body work too. They might say they do but they end up passing it off to a local company behind the scenes.

<comment><USER14> My experience as well. I tend to praise Toyota as Tesla Lite, but I've had one Toyota dealer just refer me to a body shop (although another did take over some work themselves).

</comment></comment></comment></comment><comment><USER30> One would think repair-parts supply chain was a solved problem.

But, not even Daimler-Chrysler can get it right. In 2014, my then-new Jeep Wrangler was rear-ended to the tune of $10,000 damage. It took nearly 2 months for the body panels to be available. And about 3 months for the repairs to be completed.

<comment><USER31> I have a question about this. I just bought a new jeep wrangler unlimited and a coworker recommended that I remove the spare wheel on the back of the jeep and store it in the cargo space. He said that in the advent of a rear-end collision the wheel gets rammed through the back door panels causing much more damage then otherwise would occur. Did this happen in your case?

<comment><USER30> That's a great, big "Maybe?"

If the collision might have otherwise hit the bumper instead of the spare AND was slow enough to not damage the bumper, I suppose that could happen. More likely to be true if you back into a stationary object than somebody rear- ending you. Most cars are going to be below the spare wheel of a Jeep. This is definitely an issue on smaller SUVs (RAV4, etc) because they are low enough that the spare gets hit by any full size truck/SUV.

In my case, I had a bike rack installed in the hitch. The rack (and bike) got bent up into the tailgate. The collision was bad enough to push my parked Jeep a full car length, bend the frame, twist the rollcage, damage the exhaust, tailgate, floorpan, both tail-lights, left-rear quarter, spare wheel, and rear window (soft-top). I was amazed the car wasn't totaled (probably would have been had it not been well-optioned and basically new).

In addition to the car, a $5000 bicycle and $600 rack were destroyed. And I hurt my ankle.

All by a freaking Smart Car with a driver to busy checking text messages.

Grrrrr.

</comment></comment></comment><comment><USER32> "To say that this whole experience has been traumatizing would be an understatement."

"We are now questioning our Model 3 reservation."

Just "Questioning" the next product purchase?

Does this mean that Tesla is the new Apple?

</comment><comment><USER33> Without finding evidence myself, I'd like to know more about other instances of Tesla vehicle repairs. Right now I just have this sample size of 1, so it's hard to make a judgement about how Tesla deals with other customer's repair jobs. Is this just an anecdote of a rare occurrence and a customer service failure, or an example of a more pervasive problem? Would be good to know more.

<comment><USER34> I ran into someone (early Tesla, no automatic braking) and it took 6 weeks to get repaired by a 3rd party body shop. One week was wasted because the repair shop and the insurance company were failing to connect about getting the estimate approved. Two weeks were wasted with the car sitting at Tesla to get new airbags. The 3 weeks of actual body shop work could probably have been shorter, but obviously they didn't have a long wait for parts.

</comment></comment><comment><USER35> When I was 20 I owned a 1993 Toyota MR-2 that had a front clip from a foreign MR-2 Turbo. Loved that car. When the hose from hell blew and the turbo's springed rubber oil gasket needed replacing, it took me months to discover a single Toyota dealership in Australia (seriously) that had the part. When it wasn't broken it was great, though.

Owning a Tesla is all well and good while it's running. But you're limited by how you can refuel it and only one company can make the parts. Much like the exotic sports car, you simply cannot depend on being able to repair it yourself, so it should not be considered a daily driver. You should probably keep a $2,000 1998 Honda Civic in the garage just in case.

<comment><USER31> I recommend a 1990's era Honda Civic Del Sol. It's a great car and uses almost all the same parts as the Civic's and Accords of the era. It's a little 2 door sports car with a removable hard top, and the manual transmission version is supper fun to drive and gets like 33mpg. I got a 1994 with 89,000 miles on it a few years back for $2500 put another 50,000 miles on it and just sold it for $2500. Best car I have ever owned. I would be willing to bet the true carbon footprint of buying and driving an old del sol for another 100k is less then buying a new tesla and driving it for 100k.

<comment><USER35> I'm familiar with the Del Sol; I destroyed one's rear end when it stopped short in the middle of an intersection (my car's bumper was scratched) so for practical and safety reasons I recommend the 4-door Civic. But it's impressive that yours never lost value!

If I wanted a fun sporty cheap 2-seater, the only choice for me would be the Mazda MX-5. For $2.5k you can cruise over to the autocross track with the top down, beat a Corvette's lap times, and then cruise home all without breaking 30mpg. (Okay, so maybe you'll need either amazing driving skills or race tires to beat the Corvette, but it's doable ;))

</comment></comment></comment><comment><USER36> How hard is it really?

1\. Stock spare parts based on accident actuaries.

2\. When stock runs out, license parts manufacturing to 3rd party.

3\. Offer trade-in incentives for crashed cars, lowing the overall "totaling" value, and use those cars for parts.

<comment><USER37> Tesla seems to have fallen into the same trap that many software companies do: chasing new customers at the expense of those who've already bought in.

</comment></comment><comment> psy-q What kind of country is this where insurance is not mandatory for owning a vehicle? He wrote that the other driver wasn't insured. So in the US, it's legal to drive a car without having insurance? My mind is blown.

This kind of thing would have cost me a maximum of exactly zero if it had happened here (Switzerland, but I'm guessing it's similar in the EU). Insurance is mandatory and the insurer of whoever caused the accident pays. Unless they flee the scene, but that's its own crime, so most people don't.

That said: We had two larger issues with our Model S so far, one time it had to be repaired in an Italian body shop while on holiday, but that was done in less than 48 hours. It wasn't even a Tesla service center, just one of their partners. The other issue involved the drive train, it started making whining noises after two years. They fixed that for free (new motor and drive train) and gave us a free loaner for a week.

One time it didn't recover from a software update and had to be towed -- again, a free loaner, Tesla paid for the towing and even had the vehicle brought back to our door because I was sick with a high fever and couldn't go pick it up. They usually make you pick it up.

Another time I snapped off the windshield wiper by accident because I'm an idiot, it was on our way to France. The service center in Geneva made room to fix this (had to replace the whole wiper assembly) and we were back on our trip less than 30 minutes after arriving at their shop unannounced.

So I guess it all depends on what's broken and where you are.

Disclaimer (do we need to have disclaimers for this now or is that just on Motley Fool?): I have Tesla shares and used to have Solar City shares as well, but the damn thieves switched my Solar City for Tesla at USD 290, so now I'm short 50 Dollars per share. Serious first world problems, eh?

<comment><USER38> _So in the US, it 's legal to drive a car without having insurance?_

No, of course not.[1] The exact details by state. But there are many problems. Here are some off the top of my head:

1) maximum penalties for allowing insurance to lapse might be light, and if you're a bad driver insurance might be expensive to purchase. Even for much worse than a simple accident, the penalties might be light. For example, for quite a while a nearby city, Portland Oregon, was doing "catch and release" for actual car thieves (I neither know nor care if they still do it). What that meant is if they caught you driving a stolen car the police would write you a citation on the spot and then let you go. You would "promise" to appear in court some number of months later! The argument was that they didn't have enough jail space for such petty criminals.

2) you might be "judgement proof". If you have no assets, even if you are sued, then you just don't pay. People rarely if ever get put in jail if they can't pay a civil judgement. So why bother to continue to pay for insurance if you're driving a crappy car and you don't care what happens to anyone you hit?

3) You might not even have a license, or it might have been suspended for previous bad behavior. (And it's probably difficult to purchase insurance under those circumstances). So, what can the government do, suspend your already suspended license? That probably works about as well as "double secret probation" worked in Animal House.

4) I can think of many similar scenarios, but you get the point

In short, the USA is not at all as homogeneous a country as Switzerland. There are plenty of lowlifes around who just don't give a shit. And very little is ever done by the government to persuade them to change their behavior.

To protect themselves from such situations, many people add "uninsured motorist" coverage to their insurance policy. This means your insurer pays you even if the other guy doesn't have insurance.

[1] [https://en.wikipedia.org/wiki/Vehicle_insurance_in_the_Unite...](https://en.wikipedia.org/wiki/Vehicle_insurance_in_the_United_States)

<comment> psy-q Wow, thanks for the explanation. That's a ball-of-yarn-shaped collection of problems :(

Here, if you don't pay your insurance premiums, the insurance company still has to cover for any damage you cause, until you return your plates (deregister the car) and I _think_ you face a nice fine if you have unpaid premiums at that point.

This means insurance companies have a great incentive to hunt you down like hounds if you don't pay. I could see this working in the US, but I think the next part is also required for the trick to work:

Not paying is hard. If the insurance company goes to court against you, it can do things like demand that a part of your wage be seized in order to pay for your debt. There are cantonal registers of previous enforcements against someone (you get an entry there for any situation where a creditor requested and enforcement of payment). Having any entries in the register is social suicide because you'll have a much harder time finding an apartment (almost all landlords demand a copy of your entries).

So if you have no assets, you won't be driving a car for long, removing you from the pool of people who can cause damage. Plus, we don't put people in jail too easily (we only have capacity for ~7000 people nationwide, and about 6900 people out of a population of 8 million are in jail right now: [https://www.bfs.admin.ch/bfs/en/home/statistics/crime- crimin...](https://www.bfs.admin.ch/bfs/en/home/statistics/crime-criminal- justice.assetdetail.1780909.html)

I can't imagine the stereotypical American we know from bad TV to be in favor of so much government involvement, but I think the system works well. Of course it's ridiculously hard to get by in the (non-urban) parts of the US without a car, which again changes the whole perspective.

It's interesting that the two systems in place here produce such different results.

Vehicle regulations are not uniform even in Switzerland, by the way (e.g. in Zürich you don't pay tax on electric vehicles, in St. Gallen you pay by weight (!!!) for your heavy Tesla). But the insurance rules are the same for everyone.

</comment></comment></comment><comment><USER39> I was considering getting a Tesla next year when my leaf is paid off, but had reservations about not being near a service center. This more or less solidifies for me that I shouldn't get one.

</comment><comment><USER40> There will be more horror stories like this as Teslas are not maintainable by their owners, making them throw away vehicles. Last I read, Tesla service manuals are only provided as a subscription service to the public... and only in Massachusetts as the state has "right-to-repair" legislature forcing it.

<comment><USER34> What does this article about body work have to do with routine repairs?

<comment><USER41> Parts availability, right to repair, etc. A lot actually.

</comment></comment></comment><comment><USER42> My initial impression of this brand was that they take customers very seriously. Everything from the design of the vehicle to their website appears customer centric.

This article is making me reconsider a future purchase of a Tesla vehicle.

</comment><comment><USER43> Seems like a classic negligence law suit for loss of access waiting to happen.

</comment><comment><USER44> I've been waiting to hear what repair and even general maintenance is like on these cars before I'd consider buying one myself. These cars are amazing, but I can't afford to buy a luxury car that I can't work on myself. Even if it's the fault of the infrastructure needing to be built up before cost of owning goes down, I'm forced to wait.

<comment><USER45> General maintenance on my last two gasoline cars was: oil changes, windshield wiper changes, engine air filter change, oil filter change, new tires every 30K or so, new brakes every 50K or so, new shocks every 100K or so. Every 125K or so the engine mechanical thermostat went out on my GM, I needed two (lots of miles!) Every four to five years I needed a new starting battery. I can do the brakes myself its quite easy for the mechanically inclined and/or intelligent. The shocks require spring compressors and I fear failure so I went out for that. About every 100K I got tired of the old radio and got a newer one with better bluetooth or whatever, but thats a luxury hardly required. I'm about 40K into a toyota thats had nothing but oil, gas, and filters, literally nothing has broken or required unexpected service. I destroyed the oil pan on the GM around 100K by over-torqueing it, but thats not scheduled service.

So an electric needs suspension and tires and brakes and ... windshield wiper changes. So all work on an electric car would seem to happen in the wheel well, or replacing wipers. I think I can handle that. Everything else in my last two cars going back to the 90s has been IC engine related.

<comment><USER46> I just had a turbo replaced on my turbo diesel van at 225,000k (140,000 miles). Definitely not something I felt competent doing myself. Brakes, oil filters, etc I can do.

It remains to be seen if an electric motor will do half a million kilometres without maintenance, or will the insulation in the motor breakdown, bearings need replacing. There's still CV joints too, or other drive-chain related components.

I'm certainly _hoping_ electric vehicles will have reduced maintenance requirements.

<comment><USER13> The same type of motors used in EV's are already widely used in factory production lines, conveyor belts, pumps, etc.

There they run 24/7 for decades. Reliability is super high.

The controllers used in EV's have only been around in their current form for ~15 years, also used in factories for controlling big motors, but even they rarely see failures.

The new bit is the battery and associated computer system/sensors. That's where I expect possible reliability issues.

<comment><USER47> > The new bit is the battery and associated computer system/sensors. That's > where I expect possible reliability issues.

Unlike mechanical systems, electronic systems are instrumented to the max, so Tesla can usually: (a) detect systematic issues, and (b) mitigate issues by software update to reduce stresses.

</comment></comment></comment></comment></comment><comment><USER48> A little reminiscent to me of experiences at restaurants. An otherwise excellent restaurant can be completely ruined experience-wise by a bad server. Ultimately your opinion is attached to the institution even though its liaisons are (perhaps) more at fault.

It's a shame really but ultimately Tesla has to own customer experiences, especially if they are working through third-parties unfamiliar with their product. Do they have plans to create electric-specific body shops or incentives to do so? It's certainly be warranted in areas where their vehicles are widespread.

<comment><USER49> > especially if they are working through third-parties unfamiliar with their > product.

Why would Tesla say a third-party is certified if the third-party is "unfamiliar" with Tesla's product?

</comment></comment><comment><USER50> [https://syonyk.blogspot.com.au/2016/03/is-tesla-building- thr...](https://syonyk.blogspot.com.au/2016/03/is-tesla-building-throwaway- cars.html)

I read that blogpost and decided I would _never_ buy a Tesla unless there are _massive_ changes.

</comment><comment><USER51> Well, what did this guy expect? He bought a low-volume car, used, and then it was rear-ended. Getting body parts was slow. Tesla's only failure here is that they're not stocking a lot of sheet metal parts.

<comment><USER52> > Tesla's only failure here is that they're not stocking a lot of sheet metal > parts.

That's a pretty big failure for a car manufacturer. I don't really understand why you're underplaying their issues and trying to blame the victim. It's all Tesla's and the body shop's faults. Entirely.

</comment></comment><comment><USER53> This really sucks and these type of repair delays are very common as my other colleague/owners have experienced. I can't imagine going back to enduring the 1 hr stop and go commute without Autopilot.

</comment><comment><USER54> To the author, it was lawsuit time after 1 month. Sell your shares and sue immediately and cancel your Model 3 reservation.

</comment><comment><USER55> A friend in the UK has a Tesla and his front screen cracked - took Tesla over two months to replace it :-(

</comment><comment><USER56> What a royal pain in the ass.

</comment><comment><USER57> Previous discussion [https://news.ycombinator.com/item?id=11879869](https://news.ycombinator.com/item?id=11879869)

<comment><USER10> Different article.</comment></comment>


DoubleRecall (YC S11) turns paywalls into advertising dollars - <AUTHOR> http://gigaom.com/2011/08/23/doublerecall-turns-paywalls-into-advertising-dollars/

<comment><AUTHOR> Sweet, laser-targeted idea. The quality of the business concepts coming out of YC have increased even as their quantity has exploded. It could be survivorship bias, but in any case I'm impressed.</comment>


Vanity Fair Pulled a Beyoncé to Keep Caitlyn Jenner's Cover Under Wraps - <AUTHOR> http://jezebel.com/vanity-fair-pulled-a-beyonce-to-keep-caitlyn-jenners-co-1708355447

<comment><USER2> I'm going to ask why hacker news readers should care about this: I'm asking why anyone should care about this.</comment>


Chrome, multicore and embarrassing parallelism - <AUTHOR> http://blog.luckycal.com/?p=20

<comment><USER2> To take advantage of multiple cores doesn't require multiple (heavyweight) processes. A single multithreaded process would do just as well.

Not to say it's a bad idea, just that we've got to remember that multiple processes is nothing revolutionary. A single thread for each tab would probably work just as well from a parallelization standpoint, but you'd lose the ability to kill one without bringing down the entire browser.

<comment><AUTHOR> I agree. However, it seems like a fundamentally simpler to build a share- nothing system than a threaded one.

<comment><USER3> Yes, but "share-nothing" almost always has some sharing. (If it doesn't, it can be run somewhere else, by someone else, at some other time, including "never".)

<comment><USER4> yeah, chrome tabs are not "shared-nothing".

They have a common document cache, a common cookie store, a common history store, probably a common dns lookup result cache, and maybe some other things. These all need to be carefully synchronized between multiple tabs.

In fact, I would argue that multi threaded would be better than multi process so that even more things could be easily shared. For example, I imagine that css stylesheets are parsed into some big fat data structure inside browsers. If I open two tabs from a website that share a stylesheet it would be optimal if they share this same internal representation (no locking would be required for the sharing since it's read-only). This has the obvious savings of memory, but it also increases speed since the css file only has to be parsed and processed once instead of multiple times. And things like sharing keep-alive connections between tabs are virtually impossible with multi process, while very possible with multiple threads.

<comment><USER5> >probably a common dns lookup result cache

Uhh, from the OS they get that for free.

<comment><USER4> But nevertheless, browsers still maintain their own internal cache. Firefox: [http://jelmer.jteam.nl/2006/11/04/disabling-the-firefox- dns-...](http://jelmer.jteam.nl/2006/11/04/disabling-the-firefox-dns-cache/)

</comment></comment></comment></comment></comment></comment><comment><USER6> I don't really get what he's saying. Most of the time you will have one active tab, which is consuming a lot of CPU, and all the other tabs in the background will do nothing. Dividing those background tabs onto multiple cores won't bring any significant performance enhancement.

<comment><USER7> If you have a tab in the background that has flash elements (i.e. most sites with animated ads these days) they will continue to run, even if the tab is hidden. This will have a knock on performance hit.

<comment><USER8> I really think that there should be a way to shut down "smart" content that´s invisible as not to steal CPU cycles from other tasks. I don´t think Flash content is that much important you need to run it all the time.

<comment><USER9> This is already done in Safari (and probably other browsers): <http://webkit.org/blog/96/background-music/>

_In both Safari 2 and WebKit nightlies, GIFs don't animate unless they are being painted somewhere. If an animated GIF becomes invisible, then the animation will pause and no CPU will be consumed by the animation. Therefore all animated images in a background tab will not animate until the page in that tab becomes visible. If an animated GIF is scrolled offscreen even on a foreground page, it will stop animating until it becomes visible again._

 _Many plugins do animation and work based off being pumped "null events" in which they do processing. The faster you pump these events, the faster animations will occur, and the more CPU will be used. Safari 2 actually throttles these events aggressively to background windows and background tabs._

</comment></comment></comment></comment><comment><USER10> I don't ever recall a time when a web page that I was loading pegged my CPU. I agree that tabbed browsing is embarrassingly parallel. But, are web pages particularly CPU bound? If anything, it's the bandwidth that's throttling the development issue.

The hard core javascript guys I know talk about developing interesting client side code compare it to developing the old 8 bit computer games, and trying to do something really cool and interesting with 64K of memory. They're trying to do something interesting and bundle it up in 64K of code, so the download speeds don't cause people to bounce to another site.

<comment><USER9> _I don't ever recall a time when a web page that I was loading pegged my CPU._

I see this occasionally due to browser bugs. (This is tautological, since I define pegging the CPU as a bug.) In some sense Chrome is the first postmodern browser: instead of trying to eliminate bugs it lets you kill -9 tabs.

</comment></comment><comment><USER11> I'm not sure if that makes any sense. The bottleneck in terms of parallelism on the client is me, the user. Predictably, what all those cores will do 99.999% of the time is wait for me and wait for my ISP to increase throughput. The multi process model in chrome (that IE has as well, on a per window basis) is meant to reduce the effects of crashes, not increase parallelism.

</comment><comment><USER12> I'd really question the theory that #cores will grow exponentially.

Be interesting to see some evidence that's likely to happen.

<comment><USER13> Moore's Law is exponential

If you believe it will continue, and that clock speeds won't increase, then you get exponentially increasing #'s of cores (or some other use of silicon estate).

An alternative scenario is that there will be no mainstream demand for more computing power, and only niche markets will buy them. The mainstream will favour cheap, less powerful CPU's. The rise of eeePC and clones is suggestive of this scenario.

<comment><USER5> >If you believe it will continue, and that clock speeds won't increase, then you get exponentially increasing #'s of cores (or some other use of silicon estate).

Only if you believe the wiring connecting the cores wouldn't explode with the number of cores.

<comment><USER13> I think the wires would just be a single bus.

A single bus works fine for moving data to/from one of many memory locations. Another method of using just one bus is TCP-IP packet-style communication. Of course, there's limited bandwidth, so you want most of your computation done within a processor, not between them.

<comment><USER3> If a single bus works for large numbers of processors, why are data centers wired differently?

For many problems, bisection bandwidth is a key constraint.</comment></comment></comment></comment></comment>


A Square Is Not A Rectangle - <AUTHOR> http://cafe.elharo.com/programming/a-square-is-not-a-rectangle/ <comment><USER5> Computer programming is young enough as a field that the mainstream hasn't realized it isn't possible to fit everything into one unified taxonomy. (Biologists and librarians have both spent over a century trying, and they have a lot of insight on the matter.) Putting types into a hierarchy is a useful abstraction sometimes, but there's not some Grand Truth in it -- often, attempts at cramming disparate elements into a hierarchy just create extra complexity. Most systems will keep trying to turn back into graphs unless you anchor the hierarchy in a specific context (what does 'a IS-A b' mean, really?), and the context tends to shift with the problem definition.

Worse still, it's the sort of complexity that _looks like work_ , even though it's usually more like _flailing in quicksand_.

I think not having to deal with class hierarchies is a big reason why some people find dynamically-typed languages so freeing. I'm still kind of new to Erlang, but I think its push towards modeling things via a graph of communicating processes, with a relatively flat type structure, is worth considering as an alternative. It explicitly focuses on the message protocol between actors, rather than a tree of subtypes. Granted, I haven't worked a large enough project to see it break down and get ugly yet. (C++ style OO sounds good on paper, too.)

Regardless, it isn't classes per se that lead to OO's problems, but the tendency to overuse inheritance. Among statically-typed languages, Haskell's typeclasses seem like another good solution - they break the hierarchy of inheritance up into composition of properties.

Also, the late-binding in OOP means that any class can potentially be responsible for maintaining its invariants even after any of its methods has been overridden by _any possible future subclasses._ That's not necessarily true even with dynamically-typed languages.

<comment><USER6> Your points concerning inheritance are good but "the field is young" seems like just a pseudo-profound explanation for the situation. CS as a field really can't be compared _in this way_ to other fields - it's not really a science since it doesn't deal with the discovery of verifiable facts. It is more like some combination of mathematics, humanities, management and engineering.

CS has to connect very fuzzy things, human beings, with very exacting things, computers. The problems of CS aren't really about the age of the discipline but difficulty of the domain. For example, when you start to get into biology- as-programming-with-DNA, you are dealing with an even more complex domain and biologists look to CS for clues in this situation.

<comment><USER5> That's why I mentioned librarians. Professional catalogers have spent over a century trying to figure out how to organize resources so that people doing research can find relevant information, and classifications that are useful for everyone prove surprisingly elusive. The Dewey Decimal system is from the 1870s, after all. (Its flaws are well-known, now, and there are several other cataloging systems in use.)

I was thinking about a quote (I _think_ it's from Philip Greenspun or Joe Armstrong, though in ten minutes of googling I wasn't able to source it. Anyone?) observing that programming seems to be in a pre-scientific phase (in the Kuhn-ian sense) -- there still isn't a broad consensus about major ideas, so advances often come via books and manifestos, rather than gradually through organized research.

(Edit: The closest match I'm getting is regarding AI. I've been reading about Prolog, so that might be where I read the quote...)

<comment><USER6> Hmm,

The thing is that the phrase "pre-scientific" implies that CS is destined to reach a scientific phase. I don't know if that's at all certain.

... Another thing, just to think about, is how Google today often lets one find more cross-links than any hierarchical system would allow you to find, yet Google is, itself, not a well defined system using the semantics of the items involved but rather a "dumb" algorithm that only looks at the links between things...

<comment><USER7> I don't know if programming (as opposed to computer science, in the research sense) will ever attain "science" status because we don't stay in one place long enough to be settled. If we were all still writing terminal apps on 80x25 green screens, the science would be pretty well settled on how to do that by now, with recipes for every occurrence that any normal programmer would ever hit readily available, and easy access to people who could do the somewhat harder cases.

"What about the really hard cases?" you might ask, and the entire point of my hypothetical is that if we can't do it in 80x25, we _don't_ do it.... and the contrast to the real world where we kept going is exactly my point. So, when will programming finally stabilize enough to become a science? I don't know, but I don't see it even in the long term (30+ years).

</comment></comment></comment></comment></comment><comment><USER8> Problem is from historical conventions of what a square and rectangle are.

A square is not really a thing, its a description of a thing. In this case, proportions of the sides of a shape.

So when you translate this into object oriented language, you are subclassing a concept with one of its potential variations. It would be like making a class called MusicalNote and then a subclass named MusicalNoteC, even though MusicalNote already has it covered.

So "square" shouldn't be a subclass because its just a proportion of the data within "rectangle", so more appriopriately, 'square' would be a method of Rectangle since it deals with internal data.

</comment><comment><USER9> This just comes down to the difference between identity that changes with mutation, and identity which is constant with mutation.

All squares are rectangles. Some rectangles are squares. If the object used to represent squares and rectangles is mutable in width and height, then its squareness cannot be immutably associated with its identity, and thus cannot be encoded as a type, since objects in static languages have immutably associated types.

There's some deep point about naming objects after their attributes, without paying attention to whether the attributes may change. Experienced programmers know this well, but laypeople don't need to make the distinction often as their language usage is usually only temporary, not needing to account for changes over time. It's the statement that must always be true, when all the right qualifiers and conditions have been included, that's hard to make.

<comment><USER6> No, there is no easy answer to this problem in a way that jives with all doctrines and also works in practice.

OO is ambiguous as to whether a "subclass" of an object is _specialization_ of the parent object or a generalization. In practice, most subclasses are a generalizations and specializations introduce all sorts of problems, especially enforcing constraints.

This naturally comes down to OO trying to shoe-horn (at least) four related- but-not-necessarily-identifical activities together: code/data encapsulation, program design, code-reuse, and modeling (the translation of real-world objects-and-categories to code).

The net result is that OO languages, tools and methods _can_ be useful for writing large program and _can_ give you effects that are better than the alternatives but that the pronouncement of OO gurus wind-up sounding idiotic and following the book to the letter can create situations that negate the particular benefits of OO.

<comment><USER9> By Liskov substitution principle, or with the set view of types, subclasses are always specializations / subsets, unless you're introducing some kind of home-baked type system built on top of the existing type system.

I would classify the parts of OO differently. I think your second and fourth activities are the same, but one models abstract concepts, and the other models concepts of concrete things. I wouldn't bring in code reuse at this level; every practical programming paradigm tries to include code reuse. It's the mechanism that's a distinguishing feature, and the mechanism OO uses is a combination of subtype polymorphism and dynamic dispatch. It's a baked-in version of the function table / union|variant record idiom from procedural programming, and it has a transposed expression in sum types and pattern matching in functional programming: OO limits the addition of new (virtual) methods (on the base) but accepts the creation of new types (even at runtime), while FP limits the creation of new types (in most implementations I've seen) but accepts the addition of new methods (which costs some in discoverability in modern IDEs, and has namespace implications).

<comment><USER6> Hmm...

 _By Liskov substitution principle, or with the set view of types, subclasses are always specializations / subsets, unless you're introducing some kind of home-baked type system built on top of the existing type system._

So, does that mean that subclasses shouldn't have extra member variable in the way that a square doesn't have any extra member variables in inheriting?? I know that there are some systems which try to do something like this - <USER2> and Date's Third Manifesto, for example, though they don't try to say they're doing OO. And, of course, this is far away from what most people do in defining objects.

The various tools and approaches are useful and your particular take on it might make it consistent if it was generally accepted. But at this point, the many confusions about what OO are set in people's minds. What's being defined now is Agile - which is naturally another semi-original, semi-useful, semi- contradictory toolset.

But hey, I guess my conclusion is it's all good if you don't take it too seriously and do stupid things just to satisfy some absurd constraint - <USER3> in the hay-day of OO when people let go of common sense and built these huge, fragile multiple inheritance trees that wound up not having the slight understanding of - or used ten separate, nested classes to define the complex numbers...

<comment><USER9> > _does that mean that subclasses shouldn't have extra member variable_

Not sure what you meant here. Extra members, whether they be properties, fields, methods, types, whatever, should be fine in subclasses. If it was removing members from the superclass, that would be problematic from a subtyping / polymorphic perspective, but adding members makes it more specific.

</comment></comment></comment></comment></comment><comment><AUTHOR> I have a simpler dictum: Square was-a Rectangle. In other words, we wish to implement a square using the rectangle class, but we do not acknowledge that a square is a rectangle at all. Implementation inheritance should sometimes be independent of interface inheritance.

If I was forced to use interface inheritance for this, I would say that both squares and rectangles are abstract quadrangles, but rectangles allow individual sides to be set and squares do not.

<comment><USER10> The article is good at pointing the logic faults.

As you correctly say, the abstraction is wrong. If you were abstracting classes for a graphics program the abstraction could even go one level higher in abstracting p o l y g o n s, rather than rectangles and squares. You can even have crossed rectangles (<http://en.wikipedia.org/wiki/Rectangle>).

Using such an abstraction IMHO any polygon shape would consist of line objects which would consist of points (x,y and even z)!

OOP abstractions can sometimes be masochistic! ;)

<comment><USER11> _> OOP abstractions can sometimes be masochistic!_

You think?

The article is a train wreck of analysis piled on the train wreck of "OO Design", which is itself a train wreck of an attempt to promote reuse by modeling code with data types, which is itself a train wreck of an attempt to imagine what hypothetical programmers in some hypothetical universe might find "useful" as masturbatory aids, hypothetically speaking. (This is not actually true - OO[D] is really an attempt to commoditize programming.) Most of the comments here are just dumping more trains on the pile. The abstraction shitheap is so high at this point that we can barely even remember that we are supposed to be solving some kind of actual problem.

The best part of the article is when the author acknowledges that the code might not actually need to be thread safe and so avoids wasting his time with that particular assumption. There is nothing else to be salvaged. A square is not a rectangle? Goodbye mathematics - what is the point of a type system again? More to the point: what planet are the users of this API from? Obviously not this one, and just as obviously no one knows or cares. Not ONCE does the author stop to wonder what services the actual users actually need; it's only about what this guy thinks MIGHT comply with some random "design" rules. One wonders if the users even exist as anything other than just another abstraction, and wondering about what problems those users might actually be trying to solve is right out.

Object Oriented Design can be seen as a case of reusing a cliche and butchering it at the same time, with the cliche being the shooting of ones self in the foot, and the butchery being the placement of said foot squarely upon the face of beauty immediately before pulling the trigger.

<comment><USER9> I think you're going _way_ overboard with your cynicism and criticism of OOP - cynicism bordering on paranoia. I've read your other comment, alleging that OOP "was pushed by manager types who just wanted as many reports as possible".

The dominant paradigm before OOP was procedural programming, and it had (and has) real problems: tendency towards storing data in globals, lack of a machine-checked mechanisms for subtyping, less discoverable APIs (often a namespacing issue), and difficulty in sharing code when representing abstractions where many kinds of values need to be treated very similarly but with little differences, GUI widgets in particular.

OOP is unmistakably a better approach for a large class of problems, primarily because it encodes good procedural practice into well-defined concepts that are checked by the machine, either at compile time, run time, or both.

Functional programming has a different kind of benefit: whereas OOP helped modelling values, FP helps modelling algorithms. Because strict FP demands pure functions and immutable data, you can reason about complex functions and expressions knowing that there are no side-effects that can bite you. The benefits of FP over OOP aren't as clear as OOP over procedural programming, as taking the strict approach makes state management problematic and limits freedom in data structure design and ultimately algorithmic complexity, but the benefits are very clear in certain areas.

<comment><USER11> I note that every advantage of OOP you cite is a modularization feature (even subtyping, since OOP basically conflates modules with types).

Clearly you are not entertained by rants based on my experiences, so maybe I should just cut 'n paste pg:

"Object-oriented programming is exciting if you have a statically-typed language without lexical closures or macros. To some degree, it offers a way around these limitations. (See Greenspun's Tenth Rule.)

Object-oriented programming is popular in big companies, because it suits the way they write software. At big companies, software tends to be written by large (and frequently changing) teams of mediocre programmers. Object-oriented programming imposes a discipline on these programmers that prevents any one of them from doing too much damage. The price is that the resulting code is bloated with protocols and full of duplication. This is not too high a price for big companies, because their software is probably going to be bloated and full of duplication anyway.

Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. Something that a Lisp hacker might handle by pushing a symbol onto a list becomes a whole file of classes and methods. So it is a good tool if you want to convince yourself, or someone else, that you are doing a lot of work."

<http://www.paulgraham.com/noop.html>

<comment><USER9> Modularization is independent of programming discipline; you can have modules in procedural programming, OOP, FP, etc.

I didn't argue that OOP is exciting, just that it is not a conspiracy perpetrated by a business elite to reduce the productivity of the average programmer.

And appeal to authority won't work on me, sorry. FWIW, I think pg goes too far in his rant - I think he mistakes a certain strand of Java enterprise development in large corporations for all business OOP.

The programming languages I use most often outside of C - Delphi (I maintain the compiler, written in C) and C# - both support closures, and of course C supports textual macros. As a compiler engineer I'm not oblivious to the fact that code is data and vice versa: turning code into data, and data into code is my meat and potatoes, as is symbolic manipulation of code trees (I implemented Delphi's closure support). But there's a downside to treating all the world as a list, and building all your structures out of conses: lack of documentation, encapsulation, machine checking. These things matter when you're trying to build an economy of software modules in a closed source world.

In my own past in business development, I even used call/cc for certain web client / server dialog scenarios, using a DSL especially built for GUI data binding and events over an AJAX protocol. Assuming that all, or even the majority, of business developers are inefficient bumblers performing make-work is foolish, insulting and extremely myopic.

<comment><USER11> Modularization is indeed independent of programming discipline. That is basically my point. Breaking a program down into the correct components is all-important, but most of this happens well below the module level. Unless the system has been over-engineered to death, as OOP encourages.

Three cheers for not being swayed by appeal to authority, but I'm curious about what you think counts as "business OOP" that doesn't count as "enterprise," as "enterprise" seems vague enough to encompass pretty much anything.

Your critique of lists and conses is again centered on the notion that documentation and encapsulation should be done in code and enforced by the machine. These things may well be necessary to build an economy of software modules in a closed source world, but the original article is just one example of the brain damage that this sort of world creates.

I'm glad you've been exposed to functional concepts, and I don't think that business developers are idiots, but I do think they live in an environment that is by and large toxic to good programming practices. I'm not paranoid, I just see a lot of evidence for the validity of Conway's Law.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Beyond just the obvious "this is a bad way to design things" message, another good takeaway is just the fact that most OO-design tutorials/discussions/books use the worst possible examples that teach people bad habits.

When done well, the useful part of OO design is encapsulation and data-hiding, not inheritance, but everyone gets hung up on inheritance because it's easy to cobble together "is-a" examples from real-world-like things, which just trains people to abuse the model.

In the real world outside OO-design books and freshman CS classes people don't have separate classes for different shapes, they just have "Polygon" or whatever the graphics buffer requires. And no one has separate subtypes of "AbstractVehicle" for "PassengerCar" and "Motorcycle" and "CommercialTruck," they just have a "Vehicle" class with a bunch of data on it and rely on the client code knowing what to do with that data.

<comment><USER13> This is why Eric Evans' "Domain-Driven Design" should be on every programmer's reading list. He applies object-oriented principles (though not exclusively) to real-world-sized problems, frequently pointing out the traps inherent in the enterprisey languages most big systems will use.

</comment></comment><comment><USER14> I understand the author is trying to show pitfalls of OO design. But the square/rectangle example doesn't do it for me.

1 - "There are actually several problems here. Thread safety is one, but let's assume the class doesn't need to be thread-safe."

The Rectangle implementation has a thread issue without regard to the Square subclass:

       public double getPerimeter() {
        return 2*width + 2*height;
      }

2 - "In object oriented programming, it is necessary that a subclass be able to fulfill the contract of its superclass. In this case, that means the square has to respond to setHeight() and setWidth() calls. However doing so enables the square to violate the nature of a square. A square cannot stand in for a rectangle.

You can try to work around this by overriding the setHeight() and setWidth() methods. For example, one might call the other:...

However this is fundamentally unsatisfying because there is no reasonable expectation that calling one of setHeight() on a Rectangle object will also invoke the setWidth() method or vice versa."

This is where things unwind. It is perfectly expected that calling setHeight() on a Square will also change its width.

3 - "We could instead just forbid setHeight() and setWidth() completely by throwing UnsupportedOperationException"

Yep, you could do that and it does show you are doing more work in working around using Square as a subclass of Rectangle. So either don't subclass it or accept the fact that its perfectly normal that if you have a Square, changing either its width or height will effect the other.

The author is trying too hard here. Its decent writing and a good attempt to show how subclassing can lead to unintended consequences. But this is not a great example.

<comment><USER15> "It is perfectly expected that calling setHeight() on a Square will also change its width."

If you're writing code that operates on Rectangles you wouldn't expect setHeight to have the side-effect of changing the width too.

It's only "perfectly expected" if you know about the implementation details of Square, which may not even have existed until after a lot of Rectangle code was already in place.

<comment><USER16> >It's only "perfectly expected" if you know about the implementation details of Square, which may not even have existed until after a lot of Rectangle code was already in place.

I don't quite agree. You don't need to know implementation details of Square (e.g. does SetHeight set the height and call SetWidth, or does it just call SetSide? Or does it, as well as SetWidth, set some new property called side?), you just need to know how a Square differs from a Rectangle (width == height).

Because Squares are a subset of Rectangles, any Rectangle code should also work with Squares. Even without Square, prevents you instantiating a Rectangle and always calling SetWidth(x) and SetHeight(x) one after the other.

</comment></comment></comment><comment><USER17> Sigh.

Those who do not read Quine are doomed to reproduce his results, as I remind people every time Uncle Bob or someone else of the cabal starts going off on this problem:

[http://www.reddit.com/r/programming/comments/7zy40/writing_u...](http://www.reddit.com/r/programming/comments/7zy40/writing_unit_tests_is_reinventing_functional/c07w5bx)

<comment><USER18> I'll see your Quine and raise you a Bolzano:

<http://plato.stanford.edu/entries/bolzano/>

<http://plato.stanford.edu/entries/bolzano-logic/>

</comment></comment><comment><USER18> Aka: <http://en.wikipedia.org/wiki/Circle-ellipse_problem>

<comment><USER19> This smells like a job for Type Classes.

</comment></comment><comment><USER20> Studying functional programming can really illumniate certain concepts in object oriented programming. The solution is a sum type which you can simulate in OOP using an abstract base class (in C# parlance) and a set of sibling classes that derive from it. So, as other have mentioned, you could have an abstract Polygon (or quadralateral) base class

</comment><comment><USER21> I had an instructor once who started a lecture with this example, and then argued that rectangle should be a subclass of square.

</comment><comment><USER22> Mirrored from Google's cache: <http://jottit.com/qykre/>

</comment><comment><USER23> Well, the problem in my opinion is, that a square is a rectangle, indeed. However, this is not square is-a rectangle;, but rather: square is-a rectangle with rectangle.height == rectangle.width;

This is overall something I have been pondering (and recently planning and implementing) to extend the standard object orientation: adjectives (opposed to 'nouns' (objects) and 'verbs' (methods)).

An adjective would simply describe a noun furhter and simplify a dispatch inside a method depending on the state of an object.

Some pseudosyntax from the current state of ideas would go like this:

      adjective_group rectangle_type(R) {
         if(R.width == R.height) {
           return square;
         } else if(R.width * 4 = R.height * 3) {
           return widescreen;
         }
       }

      draw(square rectangle R) {
         // specialized draw for squares
       }
       draw(widescreen rectangle R) {
         // specialized draw for widescreen rectangles
       }
       draw(rectangle R) {
         // general drawing method for rectangles
       }

This goes pretty deep if one starts to think about it: * Buffers: empty, full, something in between * Abstract syntax trees: well-typed, ill-typed * Accounts: banned, active, moderator, admin

Basically, it simplifies the pattern

      method(object) {
        if (predicate_1(object.state)) {
          // stuff
        } else if(predicate_2(object.state)) {
          // other stuff
        } else {
          // default stuff
        }
      }

I am just currently working on a dispatch mechanism which is at least a bit intuitive :)

<comment><USER5> Have you ever used a language that makes heavy use of pattern matching? Prolog, in particular, or to a lesser extent (due to increasing amounts of distraction by other novel features) Erlang, OCaml/SML, or Haskell. It sounds like you're essentially describing functional dispatch based on structural attributes or current characteristics, rather than a (generally fixed) object identity.

<comment><USER23> yes, this is where a large part of the idea comes from.

</comment></comment></comment><comment><USER24> My Haskell way of thinking of it would be that Square and Rectangle are distinct (non-inheriting) data types, Square and Rectangle are both instances of the type-class Rectangular (which inherits and provides default functions for Closed and Polygonal), Square has a transformation into Rectangle, and Rectangle has a transformation into Maybe Square.

</comment><comment><USER25> OO is an incredibly powerful tool but is unnecessary for so many tasks. The contrived examples of many books show beautifully, as does this example, simple inheritance hierarchies that get at the gist of it but are not really an appropriate use of the technology. Everything does not need to be modeled as an object, oftentimes with only one or two methods, no internal state, etc. Some of the newer multi-paradigm languages (F# and Scala come to mind at first glance) seem poised to rescue us from improper use of OOP when you are stuck in an OO environment with a non-OO pattern or problem to solve. You get the OO stuff when you need it, with a more flexible syntax, without being strapped into a design straightjacket.

</comment><comment><USER26> "Another is that it's possible to give the sides negative lengths."

Is that really a problem that needs fixing? Also the with/height problem - <USER4> could argue the fault would lie with the code that tries to do both...

A while ago I had a realization as to what defines the Java developer mindset: it is fear driven development (FDD).

(Taking Java as an example because it is the only world I know a little bit better).

Maybe sometimes FDD is being called for, or maybe it really is the superior development style. Personally, I am quite sick of it, and it definitely makes it harder to get things done in my opinion.

</comment><comment><USER27> If you believe OOP is "making physical objects' memory maps", instead of "related data put together" then yes there are some problems on some conditions. But this is caused by unrelated physical mapping need. If you can let go about this belief and think a bit lower level, OOP is a good enough methodology for thinking "like" objects. But it's not perfect. I don't know if this mapping need is good for software engineering.

</comment><comment><USER28> I really like this comment from Uncle Bob: Inheritance is _not_ ISA. It is a redeclaration of variables and functions in a sub-scope!

[http://cafe.elharo.com/programming/a-square-is-not-a- rectang...](http://cafe.elharo.com/programming/a-square-is-not-a- rectangle/#comment-436689)

</comment><comment><USER29> Funny I remember seeing a library (used somewhere internally) where the Rectangle inherited from square. It was a surprising discovery when reading the codebase but the implementation as odd tough.

</comment><comment><USER30> Make sure to check out Uncle Bob's comment (it's first after the post.)

</comment><comment><USER31> 403 Forbidden

Damn. Did I miss it?

<comment><USER31> Okay, so I came back finally and checked again to see if I could get in.

My thought, now, is that a functional approach to making square a "subclass" (by stretching the term "subclass" out of the confines of its traditional Java-style OOP usage) of rectangle.

        (define (square s)
          (rectangle s s))

Simple. Yes?

</comment></comment><comment><USER32> a square is indeed not a rectangle therefore i see this as the only flaw that needs to be pointed out:

public class Square extends Rectangle

inheritance for the sake of implementation is bad OO design.

<comment><AUTHOR> It is an old concept that got ignored somewhere along the road to java. Inheritance for the sake of implementation is called WAS_A. In C++, this is what private inheritance does. In languages like Java and Ruby, WAS-A is often implemented using delegation, so that a square HAS-A rectangle.

</comment></comment><comment><USER33> What about the rhombus?!</comment>


MemSQL Launches Unlimited Community Edition - <AUTHOR> http://blog.memsql.com/memsql-community-edition/ <comment><USER2>
      > The Community Edition is distributed as an executable
      > binary and is a free edition of the commercial MemSQL
      > Enterprise Edition. You are free to download and use
      > MemSQL Community Edition within your organization.

So.. how long until the same thing happens as happened with FoundationDB?

<comment><USER3> I think the FoundationDB acquisition by a company with no interest in selling enterprise products was an anomaly. A popular, commercial enterprise storage system that actually makes money would be an acquisition target from the likes or Oracle, SAP, EMC, etc...in that scenario, the acquiring company would have significant interest to increase adoption of the product and maintain the developer community versus completely shutting the product down.

<comment><USER4> You mean like Oracle with MySQL? At least in that case the 'community' could move to MariaDB, which is not an option for non-Free databases like MemSQL.

<comment><AUTHOR> you can do the very same - MemSQL uses the MySQL-wire protocol so it works with any MySQL driver and tool.

<comment><USER5> If MySQL was a drop-in replacement for MemSQL, you wouldn't need MemSQL in the first place. The reason you chose MemSQL is probably because it offers something that MySQL doesn't. If I can't take the source and continue using the product, it's a very different situation from MySQL/Oracle.

</comment></comment></comment></comment></comment><comment><USER6> Cue "Call me maybe, MemSQL"

Aphyr's posts (taken with appropriate amounts of salt) have become the authority on marketing claims. That said, many solutions are perfectly viable with their shortcomings, but knowing what those shortcomings are is essential.

<comment><USER7> When MemSQL is configured for synchronous durability and all databases are configured with synchronous replication, Jepsen confirms that writes to MemSQL are durable and acknowledged appropriately. As part of testing for the 4.0 release, we used the jepsen network partition test and observed data durability equivalent to Postgres([https://aphyr.com/posts/282-call-me-maybe- postgres](https://aphyr.com/posts/282-call-me-maybe-postgres)) e.g. the scalability of a cluster with the durability of a single node machine. As part of running this test, we noticed some opportunities to do some cool performance optimizations. Stay tuned for a blog post to follow!

<comment><USER8> ^ would love to see the details of this in a blog post, yeah. Please submit that on HN when it's ready; I'm sure I'm not the only one interested :)

<comment><USER7> will do!

</comment></comment></comment></comment><comment><AUTHOR> Eric, one of the cofounders, here. happy to answer any questions on MemSQL 4 and the community edition. Some new features in MemSQL 4:

\- fully distributed joins

\- native geospatial index and datatypes

\- lots of new SQL surface area

\- concurrency improvements

\- analytic optimizer

\- Spark, HDFS, and S3 connectors

<comment><USER9> Hi Eric!

Not sure if you remember me, but we spoke several (5?) years ago when you guys first started. I was the SAP HANA guy and I think we were talking about the landscape of in-memory solutions back then. First off, congrats on the success so far. Second, a few questions:

\- How is MemSQL comparing to HANA and Vertica? My understanding is that MemSQL provides the same infrastructure (columnar in-memory based storage) of those solutions but will run on commodity hardware (HANA for example is hardware-vendor locked).

\- One of the interesting topics that has come up in the HANA space is that it's expensive to maintain and scale. Specifically, provisioning new servers for data growth and archiving old data out of memory. Are these issues present at all in MemSQL?

\- Lots of your customers seem to be using it for company-specific strategic solutions. Are any using it for operations? (like financial close reporting, or as a transactional DB)

<comment><AUTHOR> Of course we remember you. Please stop by our new office!

You are right about the commodity hardware. The other difference with HANA is that MemSQL rowstores are in memory for high throughput applications and columnstores can be stored or flash or disks. So it's economical to scale MemSQL to very large datasets.

\- MemSQL is very easy to scale. It comes with an ops dashboard that lets you add nodes with just a few clicks.

\- There are a lot of different use cases. Some companies use us for operational reporting, end of day financial reporting, high throughput counters, real-time risk analysis, etc

<comment><USER9> I might take you up on that! Shoot me your contact details so I can set up (just did a search on my emails and can't find anything). My contact is in my profile.

Thanks!

<comment><USER7> eric at and nikita at memsql.

<comment><USER9> Cheers!

</comment></comment></comment></comment></comment></comment><comment><USER10> Our company (Simbiose) recently did a strong stress test with memSQL with billions of JSON rows, using complex JOIN queries and the results are simply AMAZING.

</comment><comment><USER11>
      > While you are free to use Community for your projects,
      > MemSQL does not support or endorse using it in production.

([http://blog.memsql.com/memsql-community- edition/](http://blog.memsql.com/memsql-community-edition/))

Ehhh. Do they mean that the Community Edition is only usable for development?

<comment><AUTHOR> for critical deployments, the enterprise version has high availability, cross data center replication, and more. you can use the free edition however you please.

</comment></comment><comment><USER12> The CloudFormation cluster generator tool they have is really cool. ([http://cloud.memsql.com/cloudformation](http://cloud.memsql.com/cloudformation)) The templates it generates are pretty complex, I wonder if that is hand written or using some kind tool.. would anyone be able to shed some light on how they did it? Do you think most of it is hand coded? I've been playing around with the .NET SDK in VisualStudio 2013.. it includes a cloud formation project type, and you can type out the JSON with Intellisense which is pretty cool.

<comment><USER13> Hi @superlogical, thank you for using it and for the kind feedback! CloudFormation by itself provides some very basic level of conditional/looping logic, but we found that it was not enough yet to provide a stellar experience. So, when you fill out the form on cloud.memsql.com, we auto- generate a template (we wrote the code to do this) that matches the parameters you filled in, upload it to an S3 bucket on our account, and then expose it as a download or via GET directly to your AWS account (i.e. you own the hardware/database/data).

</comment></comment><comment><USER14> This is way cool. Already spinning it up on my AWS clusters. Such a quick setup. Super stoked to us it.

<comment><USER15> It is way cool. I've been an enterprise user for some time now and am excited to get to use it on other projects for which there wasn't cost justification in the past.

</comment></comment><comment><USER16> When can we expect windowing functions, specifically row_number, rank, count, lead, lag, by partition.

<comment><USER17> All I can say is "it's on the roadmap." :) I used to do a _lot_ of analytics at Facebook and am now a PM at MemSQL, so it's one of my priorities.

</comment></comment><comment><USER18> Would love to hear from any existing users on their experiences so far (assuming that's allowed under previous licenses). Choosing a database is one of those decisions where I tend to go with the safest, well known option, but maybe I'm missing out.

<comment><USER15> I have been an enterprise user and had the luxury of using the 4 beta for the last month or so. I run a cluster of 18 machines with 192 cores and 540GB of RAM.

Impressions:

memSQL is remarkably stable. I actually have one machine running the old memSQL 1.0 beta that has not rebooted in months. 4.0 has similarly stable. The only problems happen when you run too many other processes on the aggregators (which is really just me being stupid).

Speed is great and the wire compliance with mySQL makes it very easy to develop for. To be honest, the "keeping the data in memory" part isn't the best part, it is the query compiling. It is incredibly fast. Often a query that takes 30sec to 1min to execute will compile down to fractions of a second. It is very cool to watch and never gets old.

We are looking to literally move all of our internal stuff to memSQL community edition while keeping our customer tools on enterprise.

</comment></comment><comment><USER19> Slightly off-topic: The font weight is too light to read properly on my PC (Widows 8.1, Chrome). Stopped reading because it was too much effort to try and read.

</comment><comment><USER20> Lol. I got what i asked for in the quora question?

</comment><comment><USER21> Are there any optimizations or explicit support for proximate ordered joins?

<comment><USER7> Could you please elaborate? Do you mean approximate joins as in this talk? [http://www2.research.att.com/~divesh/papers/ks2005-aj- tutori...](http://www2.research.att.com/~divesh/papers/ks2005-aj-tutorial- talk.pdf)

<comment><USER21> No no, sorry, it's much simpler (at least in how it works, no guarantees on implementation complexity, of course). It's an issue that comes up in timeseries databases pretty often.

Say I have a table full of quotes and a table full of trades. I want to know what the quote price was at the time the trade occurred. In no-frills SQL, that translates into something like:

        select * from t left outer join q on q.time=(select max(time) from q where time<=t.time and sym=s) and t.sym = q.sym where date = d and sym = s

If you have some sort of support for time proximate joining, the query engine only has to perform a binary search (as long as the indices on the symbol and time columns are appropriate, say symbol partitioned, then time sorted within symbol) to find the correct row from quote to join against. If it doesn't have such support, then a scan is required to find the maximum time value from the quote table that satisfies the constraint on the trade time. Presumably, if you do have support, this wouldn't be the exact query syntax, because that would heavily imply that you _want_ to perform a table scan, or that you could change some aspect of the subquery without affecting performance. Maybe you'd have it be something like this:

        select * from t left outer join q on before(t.time,q.time) and t.sym = q.sym where date = d and sym = s

<comment><USER22> If you just use the no-frills SQL query, we're able to optimize it to do a fast index seek (instead of scan) on q.time, because we know we only have to get the max row. This optimization isn't specific to proximate joins, a simple query like: select max(a) from t where a < 42; will be optimized by memsql.

</comment></comment></comment></comment><comment><USER23> #FoundationDB

</comment><comment><USER24> Goood~</comment>


Show HN: Python bindings to the Servo HTML5 parser, html5ever - <AUTHOR> https://github.com/tbodt/htmlpyever <comment><USER2> The html5ever parser source [1] is remarkably easy to read, since it uses the Rust macro system to represent the state transitions declaratively. It also uses pattern matching to nice effect.

[1]: [https://github.com/servo/html5ever/blob/master/html5ever/src...](https://github.com/servo/html5ever/blob/master/html5ever/src/tokenizer/mod.rs)

<comment><USER3> I would hope it would be nice to read since one could argue Rust was _designed_ for the purpose of building Servo. So, if you can't implement Servo nicely in Rust, it'd be a pretty bad design.

<comment><USER4> I think you've mistaken what pcwalton was trying to say. This library is interesting because (via macros) it creates a DSL that attempts to emulate how the HTML 5 spec is written, in order to more easily verify the correctness of the implementation. Note that, by dint of much of HTML being an accident of history, the HTML 5 spec is somewhat imposing; it's not going to be a cakewalk in any language, and at the same time it's bespoke enough that it would be silly to design your language to cater to the needs of the HTML 5 spec in particular. The fact that Rust can create DSLs via macros does help here, though I wouldn't recommend this approach for anything other than a similarly extreme case. In fact I'd say this library has the most extensive macro use of any production Rust code I've ever seen, it's quite atypical as far as Rust code goes.

</comment></comment></comment><comment><USER5> This one and [https://news.ycombinator.com/item?id=14588333](https://news.ycombinator.com/item?id=14588333) should fight.

</comment><comment> git-pull This is exciting. It's using Cython [1]

To the author:

What do you feel about binding python to rust? Did you use any tutorials?

[1] [https://github.com/tbodt/htmlpyever/blob/880da57/setup.py#L5](https://github.com/tbodt/htmlpyever/blob/880da57/setup.py#L5)

<comment><USER6> Seems to be using lxml's C API for treebuilding; I wonder how that compares (perf wise, primarily) to using libxml2 directly and then calling adoptExternalDocument?

<comment><AUTHOR> I did not know adoptExternalDocument existed...

<comment><USER6> Heh, okay, so it wasn't a deliberate decision!

</comment></comment></comment></comment><comment><USER7> This sounds useful. It should parse the same way Firefox does.

<comment><USER8> As a contributor to html5ever, it isn't made to parse the same way Firefox does, just so that it parses HTML5 correctly. Hopefully, the two are the same, but in practice some Firefox parser errors/behaviors won't be reproduced.</comment></comment>


Linux UEFI TPM 2.0 security impacts - <AUTHOR> https://plus.google.com/+GuidoStepken/posts/XZsgDcuairt <comment><USER2> This is BS. It mixes the idea of TPM and (I'm guessing, it's not precise) AES- NI. Hardware encryption doesn't work as described and the data isn't magically backdoored this way.</comment>


There's one clear, immediate way to fix L.A.'s traffic: Tolls - <AUTHOR> http://www.latimes.com/opinion/livable-city/la-ol-traffic-toll-lane-freeway-20170303-story.html <comment><USER2> This is great. The rabble gets to pay for the roads. And the wealthy get to drive on them without some fool in his 1998 Honda Civic getting in the way.</comment>


KeeFarce – A KeePass 2.x database extraction tool - <AUTHOR> http://seclists.org/fulldisclosure/2015/Oct/106 <comment><USER2> Does this work from an unprivileged process? I'm not familiar with Windows DLL injection techniques, but I do use KeePass and want to know if I should stop keeping it open in memory.

I guess I could always run it in a thin Linux VM or something...</comment>


Show HN: I made a commit time histogram of 504,015 github repositories - <AUTHOR> http://nightowls.swizec.com/histogram/hours?op-repost

<comment><USER2> "It means programmers do not work at night. Well, some do, there's more than 5,000,000 commits at midnight ... In general they like afternoons and evenings."

Nope. People live and work from all over the world, not just in America.</comment>


Michael Puett's book The Path draws on the insights of Chinese philosophers - <AUTHOR> https://www.theguardian.com/world/2017/mar/26/can-harvards-most-popular-professor-and-confucius-radically-change-your-life <comment><USER2> Just googling for some related ideas I found:

1) The Axel age, [https://en.wikipedia.org/wiki/Axial_Age](https://en.wikipedia.org/wiki/Axial_Age), 2) The concept of liminarity: [https://en.wikipedia.org/wiki/Liminality](https://en.wikipedia.org/wiki/Liminality)

I think Hume ideas, [http://www.iep.utm.edu/hume/](http://www.iep.utm.edu/hume/), for example about utilitarity, and his idea that there is no permanent self. Obvious, is your dynamic self is shaped by rituals then you can apply practice makes perfect techniques. A recent comment about good study habits suggested small time habits better than a strict but non-real schedule that in the end you are not going to adhere to. Also there is a very old book, whose name I cannot recall now, about Chinese culture and the art of living, in which the main insight is that Chinese culture is not about a formal system of rules, but about embracing nature and learning practical skills, that is you learn to live your life by living (repl) read (sensor model) eval (action model) print (show off yourself in society and take liability of your acts) and loop (think about how to improve). In the interview the interviewer notes that the author use the words great, good question, ...

So my takeaway is that a professor of 101 philosophy should motivate (positively) students to question their assumptions , that's the role of philosophy, and that is good to sell books. On the other hand, a bad cop is needed to say students that they know nothing and that perhaps this book, beyond motivating them to think about philosophy, is null. But the ultimate role of philosophy is to make you think by yourself, so a null thing can be a good think, the media is the message.

Edit: Recalled the book name: Author Lin Yutang, China - The Art of Living. Don't follow if you need a pay check.

<comment><USER3> There's a strong connection between Hume and Eastern philosophy, especially Buddhism, btw. He was likely well-versed in Buddhist thought. [http://www.alisongopnik.com/papers_alison/gopnik_humestudies...](http://www.alisongopnik.com/papers_alison/gopnik_humestudies_withtoc.pdf)

</comment></comment><comment><USER4> His book: [https://www.goodreads.com/book/show/23492653-the- path](https://www.goodreads.com/book/show/23492653-the-path)

</comment><comment><USER5> I've had several personal interactions with Prof. Puett. He's sort of like a new American Emerson, spartan in lifestyle, and incredibly inspiring both in his intellectual rigor and dedication to principles. I highly suspect he his having an extremely outsized impact at Harvard.

</comment><comment><USER6> All roads lead to enlightenment, there is no right/wrong way to get there. Its not about the destination its about the journey, whatever path you choose.

</comment><comment><USER7> If you don't straighten your mat, your ass will get sore.

And damn, that man had _long_ thumbnails. Never noticed that.

<comment><USER8> In Chinese culture, long fingernails are a status symbol.

<comment><USER9> Well they were, fell out of fashion in early 20th on the collapse of the Qing. Another dramatic change around this time was the mass abandonment of the long queue of hair, long associated with Confucian values

<comment><USER10> It's true that Confucian values talk about not self-injuring/damaging what parents gave to children --- their physical bodies etc. --- but pretty sure the abandonment of the long queue of hair on the collapse of the Qing was due to the fact it'd been imposed on the Han Chinese by the Manchus as a form of suppression.</comment></comment></comment></comment>