Tesla Autopilot - <AUTHOR> https://www.tesla.com/autopilot <comment><USER2> Watch this at 0.25x speed or slower to see what's going on. This is a carefully chosen environment. Every place it drives has very clear highway centerline markings. It seems to be highly dependent on those for guidance. Sometimes it can't quite identify the road edge, but the centerline provides a position reference.

The inputs seem to be road line recognition, optical flow for the road, and solid object recognition, all vision-driven. Object recognition is limited. It doesn't recognize traffic cones as obstacles, either on the road centerline or on the road edge. Nor does it seem to be aware of guard rails or bridge railings just outside the road edge. It probably can't drive around an obstacle; we never see it do that in the video.

This looks like lane following plus smart cruise control plus GPS-based route guidance. That's nice, but it's not good enough that you can go to sleep while it's driving.

<comment><USER3> It terrifies me to think of relying on image recognition software to correctly determine an upcoming crossing road (with cars zipping across) so it can properly slow down, rather than get broadsided at full speed. Or a number of other life-and-death situations (which are common during driving). It just seems fragile (what if the 'vision' is somehow impaired, f.ex. blinded by sunlight, or the road markings are wrong or obscured) when the failure mode is so catastrophic.

I suppose once statistics start to prove that these cars are safer than human- driven ones, we can chalk it up to an irrational fear, but for now it seems crazy to me to put my life in the hands of an AI, when a mistake means that I die or kill someone, rather than play the wrong song on Spotify.

I don't fully understand why more effort is not put into a hardware solution, where roads are simply marked up for self-driving vehicles, e.g. magnets lining the lanes or something like that. Of course a more expensive solution, but seems like it would make the vehicles themselves a whole lot simpler and safer. Begin with inner cities, where the area is limited and traffic is most complex.

<comment><USER4> > It terrifies me to think of relying on image recognition software to > correctly determine (... snip)

Do you not drive using only your eyes? If you are not terrified of the sensors, then software? Turing's central belief was that the human brain was 'just' a computer.

Regards doing things like embedding reflectors in roads and other ways to simplify lane holding, completely agree. But we can't forego the cameras etc that deal with situations that don't contain reflectors.

<comment><USER5> The thing is, human "machine vision" has graceful failure modes. You don't switch from seeing cars to seeing nothing to seeing an elephant just because the input got a little noisy. The same cannot be said about current ML demonstrations - because they operate on _just_ vision. Humans continuously reconcile visual input with their model of the world and with other inputs, to the point of overriding visual data if needed.

I suppose you could make ML avoid sharp changes in recognition, but I don't trust the current neural-network models to do so reliably.

<comment><USER6> You've never been temporary blinded by a low-sun? Never sneezed and had your eyes closed at the wrong moment?

This is the same thing..

<comment><USER7> Humans know when they can't see properly. The problem with adversarial examples is that the neural net _thinks_ it's doing great. You have to manually specify every possible failure mode for the neural net before hand -- if you miss one, you might have an accident.

<comment><USER8> Motorcyclists have a word for this phenomenon. It's called SMIDSY - "sorry mate, I didn't see you." Clear road, good vision, bike traveling in a straight line within the speed limit, car still somehow pulls out and hits the bike. Even worse, the times when the bike is stationary at a red light and the car just drives through it.

<comment><USER9> And it's not limited to cyclists. I think the general term used in cognitive science is "Looked but failed to see".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> This is quite interesting, I hadn't seen or heard about their intention to restrict like this, prior reading it tonight:

"Please note also that using a self-driving Tesla for car sharing and ride hailing for friends and family is fine, but doing so for revenue purposes will only be permissible on the Tesla Network, details of which will be released next year."

<comment><USER11> I don't think our legal system should allow car manufacturers to impose these kinds of restrictions on cars fully owned by their operators. If I have the title on my vehicle, I should be able to use it in any legal capacity. This restriction is an attack on the fundamental ideas of ownership and property.

<comment><USER12> the question is one of responsibility in the case of accident. is it the owner of the car? or the driver? what happens when there is no driver? well, my guess is that TSLA the manufacturer of the auto-driving software is going to be liable in place of the driver, and as such, they have every right to say, nope, no using our auto-pilot for commercial activity unless it is on our own network where we can self-regulate to make sure we are liable for as few of problems as possible.

<comment><USER13> >what happens when there is no driver? well, my guess is that TSLA the manufacturer of the auto-driving software is going to be liable in place of the driver, and as such, they have every right to say, nope, no using our auto-pilot for commercial activity unless it is on our own network

Why does this argument hold true only for self-driving cars, and not current cars ? As such, self-driving cars are just a point in continuous evolution. Current cars are already quite different from what they were a few decades ago. Why is now a good time to draw a line ? Every change in this eveolution goes through government approval. If it is approved, it should be safe enough for everyone.

<comment><USER14> It sort of _does_ hold for current cars. Generally a driver (in most cases, a human) must obtain a further license or some form of government permission/authorization to drive a vehicle for commercial purposes like a taxi or other passenger carrying service. This seems to be simply pointing out that the same restriction will apply to the _software-based_ driver in a Tesla...?

<comment><USER13> There is no legislation about ride sharing/taxi with self driving cars. So whether or not an extra authorization is needed by the owner of the car is a different issue. Here Tesla is asking you to not engage in ride sharing unless Tesla gets a cut. i.e., Even if the government and insurance companies allow you to do so, Tesla won't unless you hand over your cut to them. Is there more to it than that ? Tesla is getting approval to make a car road legal. An insurance company may underwrite insurance for various purposes including taxi. Why do I need tesla's permissions to combine a road legal car for taxi purposes ?

<comment><USER14> Because Tesla is assuming responsibility (that is, guaranteeing fitness for purpose, and all the ramifications that come with that) for the car being able to drive you under the same circumstances as any other private person driving. They would be taking on much more (legal, insurance, etc.) risk if they were to allow the car to drive as a passenger carrying, fare accepting, commercial entity, therefore it seems fair that they require you to use their managed system to (I assume) mitigate and/or manage that risk. I would guess that it would also be possible, eventually, to license the autopilot software for your own arbitrary commercial use.

</comment></comment></comment></comment></comment></comment></comment><comment><USER15> Tesla sent out an email today.

Autopilot Updates We just released the latest version of Autopilot. You can now experience Enhanced Autopilot features including Traffic-Aware Cruise Control, Autosteer, Auto Lane Change, Parallel + Perpendicular Autopark, and Summon. Automatic Emergency Braking, Forward + Side Collision Warning, and more advanced safety features are also active and standard.

All Tesla vehicles have the hardware needed for full self-driving capability at a safety level substantially greater than that of a human driver. And Tesla vehicles continue to improve with over-the-air software updates, introducing new features and improving existing functionality to make your vehicle safer and more capable over time.

<comment><USER16> > You can now experience Enhanced Autopilot features including Traffic-Aware > Cruise Control, Autosteer, Auto Lane Change, Parallel + Perpendicular > Autopark, and Summon

Scary stuff, really. No consumer wants (or needs) autopilot "features" \- at least not from a marketing standpoint. If you ask me, the car either drives itself or you are driving it.

It's a bit ridiculous to expect people to use these things safely. If anyone has to _think_ about when the car is or isn't in control, I'm sorry, but you've already lost in my book. Humans just aren't that good at switching context or remembering what a product does (or what this particular _version_ of a product does).

<comment><USER17> this is probably one of the most ignorant and short sighted comments i've ever read on HN and reaks of competitive shilling.

It's like saying we shouldn't have released seatbelts because people moght not have used them. Or maybe we shouldn't have released vaccines because you still need booster shots.

Safety features, even incremental ones, make the world safer for everyone.

<comment><USER18> The difference between autopilot and examples you mentioned is that autopilot can decrease safety. If it works correctly 99.9% of the time, you get used to it and when 0.1% arrive you will cause accident, because you weren't paying attention.

<comment><USER19> The airplanes of this world demonstrate this.

<comment><USER20> Airplanes generally somewhat safer than driving. By quite a margin.

Without consulting the literature, it just seems easy to believe that machine- like consistency 99.9% of the time is more important to safety than confusion in the 0.1%.

<comment><USER21> It really depends on what 0.1%.

If the car fails to detect one in a thousand cars in front of you, or one in a thousand corners, I can see that being highly dangerous.

Let's say you change lane 5 times while commuting. That's 50 times per week. Now, are you going to pay attention well enough that you catch it twice a year just before it pulls out right into another car?

Perhaps likening it to having another person driving you would be good. If you were given a perfect chauffeur, except with the knowledge that they'll drive straight through one in a thousand red lights with no warning, are you confident you'll catch them?

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> From this you can see, they are selling, and people are buying, a self-driving car.

My theory is still that the demo video is actually from Nvidia's SDK and the actual autopilot they deployed is totally different and not actually in the 'self-driving' category at all at this point.

But they are very aggressively rolling out updates and new features for more autonomy and yes they do intend to push for a complete door-to-door self-drive ASAP, ideally before the end of 2017 (at least as a new alpha version they can demo). Otherwise they would not sell it as such. But they do not plan to take another year to get there, based on Musk's tweets and the fact so many already paid extra for a full self-driving ability.

<comment><USER23> I very highly doubt they'll have a full self-driving solution by year's end, but I'd be happy to be proven wrong!

</comment></comment><comment><USER24> This is an old microsite from last October. Most features listed on that page are not available in production (or at all).

<comment><USER25> I believe the claim is that all of their vehicles include the hardware required for these planned future features. They call attention to regulatory challenges, but gloss over the fact that many of these items aren't ready yet from a software perspective.

<comment><USER26> I think this is old, or at least deceptive advertisement.

There are two packages for the model S which add up to $9k extra[0]:

Enhanced Autopilot

Full Self-Driving Capability

The fact those are add-ons and their descriptions seems at odds with the statements made on the page.

0: [https://www.tesla.com/models/design](https://www.tesla.com/models/design)

<comment><USER27> The add-ons are software unlocks. The old 60D models actually had a 75KwH battery pack, but were software-limited to 60KwH unless you paid for an upgrade.

</comment></comment></comment></comment><comment><USER28> I have an AP1 car and a AP2 loaner (for the last month). This is just reaching parity to AP1 autopilot capabilities. AP2 has been crippled since launch.

There a few new features that my AP1 might not have like Perpendicular Autopark, but I won't know till I get it back. From what it seems it's just gotten to the level that they were with with the previous generation that was developed by or in conjunction with MobilEye.

I think they will need a hardware revision for actual full self driving perhaps 2 years away.

<comment> bjelkeman-again But they are only using two of the eight cameras in AP2 at the moment. There is more capacity in AP2 hardware to tap into. [https://electrek.co/2017/03/30/tesla- autopilot-2-0-camera-8-...](https://electrek.co/2017/03/30/tesla- autopilot-2-0-camera-8-1-update/)

<comment><USER28> There are rumors they might want to use Lidar. People have seen Tesla's equipped with Lidar, but it could be a 3rd party testing it or even Tesla doing some comparison research.

Since newer sensors are become more cost effective I could imagine them incorporating them into future hardware revisions.

<comment><USER8> Could be using the LIDAR for ground truth for training a depth-from-stereo system?

</comment></comment></comment></comment><comment><USER27> This is not news. Current Tesla vehicles with Autopilot 2 hardware can do nowhere near this aspirational list. My AP2 Model X cannot even tell when to turn the windscreen wipers on.

This is a statement of intent, and production vehicles are a long way from having software that enables this.

<comment><USER29> Do you mean the X doesn't have rain sensors, or it does but they aren't hooked up in software yet? Surely it has rain sensors, they couldn't do Autopilot using cameras behind the windscreen without them.

<comment><USER27> It will use the Autopilot cameras (there are no additional sensors), and the Tesla Vision software on AP2 hardware does not support detection of rain on the windscreen. The driver has to turn the wipers on manually. My Renault Zoe, which costs about 25% of my Model X, does this automatically.

Tesla Autopilot is cool, but the software is very limited at present. The original link is essentially what Tesla think they can achieve with the AP2 hardware, but the production software is nowhere near capable of these feats.

<comment><USER30> My version 1 tesla does rain detection

<comment><USER31> Right, those have actual rain sensors. AP2 vehicles will eventually rely on the camera to detect rain. AP2 cars are waiting on a future software update to make this happen.

</comment></comment></comment></comment></comment><comment><USER32> "All you will need to do is get in and tell your car where to go. If you don't say anything, the car will look at your calendar and take you there as the assumed destination or just home if nothing is on the calendar." \-- that'll teach you to make sure your schedule is up-to-date!

</comment><comment><USER33> Will I get a DUI if I'm drunk and my car drives me home? Say I'm in the back seat.

<comment><USER34> That question only becomes relevant when it would be considered legal to have the car drive without a licensed driver in control. As long a driver with a license is required, you have of course to be fit for driving.

<comment><USER35> This is really interesting to me as I do not have a driver's license and I am not intending to get one.

</comment></comment></comment><comment><USER36> I don't think these autopilot systems will work well in crowded cities or cities with poor infrastructure for roads.

The amount of objects for detecting and avoiding will be way too high.

The tests shows almost clear conditions for driving. This should be tested on streets of NY or a busy city like Mumbai

<comment><USER37> Check GM autopilot demos in the streets of San Francisco. Much more impressive than this one. Pedestrians, bicycles, delivery van stopped in the middle of the street, etc.

daytime: [https://www.youtube.com/watch?v=SSc8AHIEG9o](https://www.youtube.com/watch?v=SSc8AHIEG9o)

night time: [https://www.youtube.com/watch?v=XHIq0MMViZg](https://www.youtube.com/watch?v=XHIq0MMViZg)

<comment><USER38> Cruise is also using Lidar which provides depth sensing[1]. You can do depth sensing with cameras, but that requires building depth maps from multiple cameras (like eyes) and still being able to interpret the depth map with computer vision. Capturing depth is definitely possible with monocular cameras (because humans can do it), but it seems like lidar works a lot more accurately.

[1] - [https://www.getcruise.com](https://www.getcruise.com)

</comment></comment></comment><comment><USER39> I love watching videos like the one they have on there. theres something almost hypnotic about it

<comment><USER40> The car seems to stop for no apparent reason. I noticed it once next to two pedestrians just off the road, and again after turning right at a stop sign. I wonder if that is why they are showing it in a sped up format -- it certainly makes it harder to notice.

<comment><USER35> I wonder how fast the car is going as well.

</comment></comment></comment><comment><USER41> Self-driving cars' marketing pitch is that they could reduce road accidents, but if we really want to reduce road accidents, might we not have a better chance at it if we removed cars from roads altogether? We could replace them with, I don't know, some kind of overground system of personal pods on rails, or something like that.

I think one big selling point of cars has always been that they grant the user a great amount of autonomy (unprecedented, in their time, taken for granted nowadays). You can ride your car and go anywhere you like! The cost of that autonomy of course is that some of us will be killed or maimed in road accidents, because you can't give silly little monkeys autonomy behind the controls of big powerful machines without death and carnage ensuing.

Self-driving cars propose to reduce this risk of death and injury by taking away the autonomy we traded it for in the first place. What remains would be just a mindless automatic system carting the user to and fro. Well, in that case- we don't need to wait around for full level-5 autonomy. We already have dumb machines that can do that: trains, trams, all sorts of vehicles-on-rails.

Why do we _need_ self-driving cars, then?

Answer: we don't. And I haven't for a moment believed that any of this is anything to do with road safety. Note that nobody even discusses the other 900 pound gorilla in the room: pollution.

Guess what? Taking cars off roads completely would also reduce air and noise pollution tremendously.

<comment><USER21> > Self-driving cars propose to reduce this risk of death and injury by taking > away the autonomy we traded it for in the first place.

A car that can drive itself does not remove the autonomy having a car gives you. The key part of the autonomy is going where you want, when you want. Not that you get to push the pedals and turn the wheel.

> We already have dumb machines that can do that: trains, trams, all sorts of > vehicles-on-rails.

Which travel only from and to certain places, at certain times. It's why what would be a three hour drive is likely to take me closer to five hours tomorrow, for example. For another example: the train station near my friends house stops running trains at 7pm, the roads are open all night.

> We could replace them with, I don't know, some kind of overground system of > personal pods on rails, or something like that.

Building an entirely new, country wide, overhead rail system that goes to or extremely close to every house? That sounds incredibly expensive.

> Why do we need self-driving cars, then?

They're an incremental improvement which requires no new major infrastructure.

</comment></comment><comment><USER42> Hopefully better than AP1: [http://imgur.com/gallery/T5j32i9](http://imgur.com/gallery/T5j32i9)

<comment><USER43> Read this comment: [https://www.reddit.com/r/teslamotors/comments/5welnn/my_car_...](https://www.reddit.com/r/teslamotors/comments/5welnn/my_car_hit_a_barrier_while_i_was_on_autopilot/de9hv3d/)

</comment></comment><comment><USER44> Autopilot for Batteries. What I wonder is, why isn't anyone building self driving batteries that park near the road and can follow you and give you more range if needed. They only would need to implement some kind of follow mode witch should be relatively easy. Cars could be build light and inexpensive and at the same time come with infinitive range.

<comment><USER45> Yeah I've thought about this too... like fighter jets being refueled by tanker jets mid-air. It should be safe for two vehicles to latch on to each other safely and for one to charge the other, then the 'tanker' vehicle goes back home to refuel itself or goes on to fuel another vehicle etc..

This seems like such an obvious step... i.e. if you're at 20% battery capacity and your car reckons it would need 40% to get to your destination, then it would send out a request to local tanker vehicles and the nearest one would come to you, connect and refuel without you having to stop or break speed.

People would probably pay a premium for that service.

</comment></comment><comment><USER46> That car is driving oddly. It stopped for pedestrians who were on the sidewalk, and several times it stopped _after_ making a turn. I could see that being really frustrating for other drivers and even dangerous if it's doing unpredictable things no human driver would do in those circumstances.

<comment><USER27> Current Autopilot tends to brake abruptly in slow-moving queueing traffic, which I'm sure annoys the people behind me.

</comment></comment><comment><USER47> "All Tesla vehicles produced in our factory, including Model 3, have the hardware needed for full self-driving capability at a safety level substantially greater than that of a human driver."

That claim is strong and false. What about Roadster and the old Model S with the old AP1 hardware?

<comment><USER48> "All Tesla vehicles produced in our factory" is present perfect tense, implying an event that happened at an unspecified time in the past and continues to the present. You would have to add "ever" to include all vehicles ever produced.

<comment><USER47> So then, what about the Model S with AP1? It was produced just last year.

<comment><USER49> That isn't present tense, by saying "All Tesla vehicles produced in our factory" means today and going forward.

<comment><USER50> No, that's not what it means. It's past tense.

</comment></comment></comment></comment></comment><comment><USER51> I love the idea of Smart Summon - it reminds me of one of the Assassin's Creed games where you would whistle and your horse would magically appear a moment or two later!

<comment><USER52> I was thinking of Red Dead Redemption, same feature!

</comment></comment><comment><USER53> Tesla plans to restrict the use of their car AI when it is for uber-like uses to their own to-be-announced network! That's probably the biggest news here, for me at least! "Please note also that using a self-driving Tesla for car sharing and ride hailing for friends and family is fine, but doing so for revenue purposes will only be permissible on the Tesla Network, details of which will be released next year."

</comment><comment><USER54> > Please note that Self-Driving functionality is dependent upon extensive > software validation and regulatory approval, which may vary widely by > jurisdiction. It is not possible to know exactly when each element of the > functionality described above will be available, as this is highly dependent > on local regulatory approval.

I wonder what the current status is, both in terms of software validation, and regulatory approval.

<comment><USER55> You can look at their CA DMV disengagement report here: [https://www.dmv.ca.gov/portal/dmv/detail/vr/autonomous/disen...](https://www.dmv.ca.gov/portal/dmv/detail/vr/autonomous/disengagement_report_2016). They were very far away as of the start of this year.

<comment><USER56> The lists are interesting. And for me they are mostly telling that they are all in some super early prototyping phases. E.g. Tesla lists tests with < 600 miles with 4 cars in a year. Mercedes 670 miles with a single car. The only outlier which really seems to do serious testing is Waymo with 630k miles.

To give some comparison numbers how normal series cars are tested at bigger automotive companies: There are test fleets of partly over 100 cars for a new car model, where some of those are tested all around the clock (> 600 miles per day). All in all often 2digit million kilometers.

<comment><USER55> The autonomous car services are going to launch in specific areas first, so they do not need to be tested in all the conditions that a Corolla would be tested in and can instead be tested in the launch markets. The key figure is miles per disengagement, and Tesla appears to be very far from having a viable autonomous car.

</comment></comment></comment></comment><comment><USER57> No one seems to be commenting on the fact that they are doing this all with camera's and ultrasonic sensors. No LIDAR at all, which in the short term certainly provides for a better looking car. And considering the fact that it lowers the car price by a significant factor, seems like a pretty amazing thing!

</comment><comment><USER58> Progress will of course be incremental. But I think about the delta between summer in California and Canadian winter driving conditions and I think there's still such a long long way to go to full full autonomy.

</comment><comment><USER59> I don't think this is a new page on their site-- why is this suddenly at the top of HN? There's no new info here; this isn't an update or press release.

<comment><USER60> I don't know if there is or not something new with that page, but Elon recently tweeted this

"Radar-only braking on HW1 is getting better with every release. We're hoping to do the demo where it brakes for a UFO in the fog soon."

So maybe that has something to do with it.

</comment></comment><comment><USER61> I sure hope it works, for the sake (and lives) of people who own them. And for the people who have to drive alongside them (everyone).

</comment><comment><USER62> Anyone identify which road the car is driving on? Looks familiar like the area around Foothills but couldn't tell.

</comment><comment><USER63> There's so much room for error I can't wait to see how this will turnout.

</comment><comment><USER64> What kind of hardware supports all this signal processing? FPGAs? GPUs?

</comment><comment><USER65> that is amazing offer from Tesla as hardward+software upgrade as a package. I also love the design of "call to action" buttons for buying 2 new car models.

</comment><comment><USER66> Can it self-drive in snow and rain?

<comment><USER67> I've seen multiple ottos and uber self driving cars driving during the rain so I'd trust it.

<comment><USER68> Ubers self-driving cars have LIDAR. Tesla autopilot is fully based on view from cameras that can be obstructed.

<comment><USER69> LiDAR doesn't work well in rain and it's just a ray of infrared laser light scanning surroundings, so it can be obstructed the same way as cameras; radar is what you want. But NVidia uses just 3 normal cameras and deep learning to drive in rain/snow/night and it seems to be working for them.

<comment><USER70> If anyone isn't aware: While most companies use LIDAR, Tesla uses radar

[https://www.tesla.com/blog/upgrading-autopilot-seeing- world-...](https://www.tesla.com/blog/upgrading-autopilot-seeing-world-radar)

<comment><USER69> All of them use both, and in multiple instances of each. So they might have two front LiDARs, two side LiDARs, one rear LiDAR, one front and one rear radar, ultrasonic sensors etc. and then perform a sensor fusion to map car's surroundings.

</comment></comment></comment></comment></comment></comment><comment><USER71> Look ma! No hands!

</comment><comment><USER72> Staged demo. Just driving on single lane, Occasional turns roads at best demonstrates advanced lane guidance. Do a cross country and you've shut everyone's mouth.</comment>


Fake Or Not, New York Times' Tesla Review Speaks Truth About Electric Cars - <AUTHOR> http://www.forbes.com/sites/joannmuller/2013/02/11/fake-or-not-new-york-times-tesla-review-speaks-truth-about-electric-cars

<comment><USER2> _First of all, it took an hour to refuel at a "fast-charging" station. Not many people have that kind of time to spare._

I think that as electric cars become more mainstream, people would be willing to make adjustments to their lifestyle to accommodate charging times. I think that over the next 10 years there could come a point where case reaches a threshold and charging time decreases enough where the scales tip in favor of electric. I'm not sure where it is, but there has to be some point on the continuum where people say "let the car charge for an hour while we eat at Denny's rather than paying $6-7/gallon.</comment>


Men's and Women's Brains Appear to Age Differently - <AUTHOR> http://nymag.com/scienceofus/2015/11/there-are-gender-differences-in-how-brains-age.html <comment><USER2> It's a courageous study in the current environment. Is it even legal in the US to suggest there could be an intellectual difference between sexes, even at a certain age?

It reminds me of this [https://en.wikipedia.org/wiki/Lysenkoism](https://en.wikipedia.org/wiki/Lysenkoism)

<comment><USER3> You mean like when Lawrence Summers was forced to resign from Harvard because he said that (well-known) differences in IQ distribution _might_ have an impact on the number of women in STEM, but more research was needed (and fighting against sexism should also continue).

He was completely right with his information. The bell curve for male IQ is much shallower resulting in men greatly outnumbering women both at the top and the bottom of the IQ chart (note: that doesn't mean that a man with the same IQ as a woman is smarter, just that there are more men with higher IQs).

The idea that abstract logic, spatial reasoning, and pattern recognition (what IQ indicates) are primary components in being good at STEM is well-known too. The one idea definitely implies the other and stating that causal implication shouldn't be a crime.

Nobody stepped forward to disprove the science. They simply screamed sexism. They didn't care that he had even said that fighting the sexist component was also important. They didn't care that he had said the science might be disproven. They only cared that they didn't like the idea no matter if it was true or not.

History is filled with ideologues hurting and killing men of science for ideas we now know to be true. Freedom to research, study, and publish those studies without being threatened or harmed is paramount. If there's a problem, then fight the science -- not the scientist.

<comment><USER4> There was a big followup article in the "Notices of the American Mathematical Society" that actually looked at the numbers and concluded Summers was not supported by the data.

<comment><USER3> Here are the only two articles I can find mentioning Larry Summers

[http://www.ams.org/notices/200810/fea- gallian.pdf](http://www.ams.org/notices/200810/fea-gallian.pdf) [http://www.ams.org/notices/201201/rtx120100010p.pdf](http://www.ams.org/notices/201201/rtx120100010p.pdf)

They do not address the question of IQ in any meaningful way. They only seek to show that women can succeed in mathematics. Summers in no way said that women could not succeed in math (or any other STEM field). The question of IQ has more to do with _potential candidates_ rather than success of those candidates.

</comment></comment></comment></comment><comment><USER5> Why does this get so much attention? Men and women are obviously different in a lot of ways, why should the brain be an exception? Discovering that there are no differences would be an astonishing result, the opposite is what one should expect.

<comment><USER6> Because the official feminist line is there are no physical differences in the brain of men and women. Extra attention is needed to overcome the rhetoric.

</comment></comment><comment><USER7> I want to see a study like this on nonbinary and agender people.

<comment><USER8> Gender theory is by-and-large a sociological theory, not a scientific one. It's extraordinarily difficult -- from an epistemological point of view -- to produce strong evidence for the claim that gender is orthogonal to sex.

What this means, in practice, is that the selection criteria will be vague, which in turn is likely to produce massively varying results from study to study.

I see why you're interested in this, but I think you're basing your hypotheses on a false premise: namely that gender theory is hard science.

<comment><USER7> I didn't state any hypotheses or claim gender is easily tackled by science. I expressed an interest.

<comment><USER9> What would be the point of the results, if they aren't scientific ? Except who would pay for them and their agenda.

<comment><USER7> "Hard to tackle by science" is not the same as "not scientific." Confounding variables are notoriously hard to control for in social science, but people manage to find useful information when they go in without agendas.

<comment><USER8> You've missed my point: my claim is that your study is necessarily non- scientific, given the epistemological problem associated with gender/sex orthogonality.

</comment></comment></comment></comment></comment></comment><comment><USER10> Unlike men, women's brain is horizontally wired and good at multitasking. [http://www.webmd.com/balance/features/how-male-female- brains...](http://www.webmd.com/balance/features/how-male-female-brains- differ?page=2&print=true)

</comment><comment> nv-vn The findings are interesting, however I don't think that such a small sample can be used to make any conclusive assumptions and I think that these findings should be taken with a grain of salt. Since all these studies tend to have quite small sample sizes, it is quite likely that they will contradict past studies of similar sizes.

<comment><USER8> n=50 (closer to 100 with the control group) is massive for a brain-imaging study.

More to the point: statistical power matters, which is only indirectly related to sample size. I mean no disrespect, but this kind of criticism usually betrays ignorance of statistics and scientific methodology.

Do you suspect the study is under-powered? If so, why?

<comment> nv-vn >n=50 (closer to 100 with the control group) is massive for a brain-imaging study.

The problem I see with it being a small group is not necessarily that the results are inaccurate because of size/lack of statistical power, but more so because of the fact that a lot of variables will not show up in a small sample. For example, it is possible that certain diseases that they found to be more common in one sex than the other are only more common in caucasians and the same relationship does not occur with other races (since this happened in Hungary, it is very unlikely that non-white people were a part of this study). The numbers determined here probably apply very well to people in Hungary but they might be very different from what we'd find in the United States or in India, for example.

<comment><USER8> What you're describing is an epiphenomenon, and increasing the sample size won't fix this. In fact, increasing the sample-size (i.e. over-powering a study) _increases_ the propensity for spurious correlation.

This may well be an epiphenomenon, but that's why reproductibility (not statistical significance) is the gold-standard of science.

<comment><USER11> > In fact, increasing the sample-size (i.e. over-powering a study) increases > the propensity for spurious correlation.

Huh? If there aren't just 2 kinds of brain, but instead 30 different kinds, then a study with 300 brains is much more likely to catch all 30 kinds of brains than a study with just 50 brains.

<comment><USER8> So you're worried about a representative sample?

This is -- again -- only indirectly related to sample size. If the sample was randomly selected and the statistical power is great enough, then any correlation it's missing is marginal; this is a feature, not a bug!

You're not entirely wrong insofar as brain-imagery studies rarely conduct random samples, but increasing your sample size won't fix that.</comment></comment></comment></comment></comment></comment>


Introducing Heroku Postgres 2.0 - <AUTHOR> https://postgres.heroku.com/blog/past/2013/11/11/heroku_postgres_20/

<comment><USER2> The email sent to existing customers mentions price drops for certain plans (text below). With the few plans I glanced at for 2.0, it doesn't look so much like a price drop as it does a storage capacity and max connections drop.

Production plans used to allow 1TB of storage and 500 connections. Now the smallest production plan has dropped to 64GB of storage and 60 connections.

I know Heroku is trying to run a business, and that computing resources do cost money -- but that copy seems a bit misleading to me.

Customer email blast:

""" As someone who is already using a Heroku Postgres production database we're excited to ensure you're the first to know about our new release, Heroku Postgres 2.0. This new release continues to build on many of the great features you may already take advantage of as well as a price drop across certain plans. This new release highlights:

Built-in alerts around what you should do for your database, bringing a new level of operational expertise built right into the product. The ability to rollback your database to a specific point in time, similar to how you can rollback bad deploys on Heroku New tiers, with our premium and enterprise tiers including high availability with automatic failover You can read more details about the features included within this release on our blog post.

You will be able to continue using your existing plans. While they will not appear in the addons:list you will be able to visit the legacy pricing page and they will continue working. We will notify you before any changes do occur to existing plans.

Cheers, The Heroku Postgres team """

<comment><USER3> Product manager of Heroku Postgres here, we did indeed lower those limits, but less for the cost and more that we saw many users hitting issues in going beyond that. Our limits exist primarily to prevent people from shooting themselves in the foot and bringing their databases down. Would be happy to hear if you're above one of those limits today and not experiencing problems - firstname.lastname@example.com

<comment><USER2> I have a production app that generates about 500MB of data per day. A small amount of that data needs to be kept hot in cache -- but the rest is accessed infrequently by comparison (but still in a manner that is aided by SQL). No problems at all -- system runs smooth as silk.

The problem is the application was developed based on the specs advertised (as I'm sure countless others also were). Now, the smallest database package with the same storage and connection resources is the "Standard Baku" at $2,000/month. These resources used to be available starting at $50/month. Ouch!! And even then, it is still only the "Standard" feature set -- so none of the new whiz-bang Heroku 2.0 features.

</comment></comment></comment><comment><USER4> I just had a look at the updated pricing.

If my memory serves correctly, the same limits for storage and # of connections were in place before for the non-dev databases (starting with 50$). I don't really care for the connections, but a 64 GB storage limit can quickly become a problem for some apps, while 400MB of RAM is perfectly fine to serve the hot data...

Edit: To put this into perspective: If an app would generate 400MB of data per day (the last 24 hours would fit into the cache completely!), the app would run out of storage after 160 days...

</comment><comment><USER5> Point in time recovery: yes please.</comment>


Iterators in Go - <AUTHOR> http://ewencp.org/blog/golang-iterators/

<comment><USER2> Pattern 5: use the iterator pattern that Go ships with, e.g. in sql.Rows: [http://golang.org/pkg/database/sql/#Rows](http://golang.org/pkg/database/sql/#Rows).</comment>


EBay Spinning Skype Out Public - <AUTHOR> http://www.siliconangle.com/ver2/?p=3996 eBay Inc. (Nasdaq: EBAY) today announced that it plans to separate Skype from the company, beginning with an initial public offering that is intended to be completed in the first half of 2010. <comment><USER2> "EBay plans IPO for Skype, citing limited synergies"

<http://www.physorg.com/news158949373.html>

Captain Obvious called, wants his headline back.

I'm surely not the only one who thought the Skype acquisition by eBay was a huge WTF. Now they are forced to admit it.

<comment><USER3> This is one of the things that I never really understood about Skype either. I have never been using Skype and think, "I should check eBay right now!"

It is funny that they are both independently profitable. No synergy at all.

<comment><USER4> I worked at ebay when the skype deal was announced... we learned of the impending purchase by seeing an article on WSJ... there were no rumors, no speculation... it was just unfathomable.

To be fair to my former employer, they attempted (several times) to create "synergies" between skype, paypal, and eBay - the frequently restarted "Trident" project for instance. But these projects always had the feel of shaping reality to fit Meg's viewpoint, and always doomed to failure.

</comment></comment></comment><comment><AUTHOR> This has huge implications for european entrepreneurs. My Angle is that this great news for them. EU startups will be the dark horse in this new market reality. Right now EU startups need more zero and early stage financing. Skype will be the EU bellweather over there. Congrats to Josh and his team for executing like a startup and not letting a corporate structure stop them from doing great.

</comment><comment><USER5> ?? I thought Skype was being sold back to its founders?

<comment><USER6> The founders were looking to raise funds to buy back - but _IF_ this post is correct, I guess Ebay must think they can get a better price via IPO (or are using the IPO-route as a bargaining tool).

</comment></comment><comment><USER7> Next $GOOG or $VG?</comment>


Zinc: a low level language between assembler, C and C++ with Ruby-like syntax - <AUTHOR> http://tibleiz.net/zinc/

<comment><USER5> I was surprised by my almost-panicky reaction to seeing:

      Identifiers Can Have Blanks

      open_window_with_attributes(...)
      becomes:
      open window with attributes (...)

I think I actually felt that wrongness in my stomach. Like a more intense version of seeing our corporate network shared drive's files with spaces and parens in them.

I guess I'm old.

<comment><USER6> I had a similar reaction, and I'm not sure that it's a "damn kids, get off my lawn" reaction. Specifying an unambiguous grammar may be difficult - <USER2> implies parsing may become a problem.

An implementation exists, so the author has something working, but I'm wondering how robust the parsing is. I haven't seen many code examples (only short fragments on the page), so I don't know what potential issues, if any, there are. But, this is the sort of thing that could significantly complicate adding new language features that requires additional syntax.

edit: I'm perusing the source for the compiler, which is of course written in Zinc. This code from the main driver of the compiler perhaps gives a better feel for how it may look in practice:

      while i < argc
        def arg = argv[i]

        if is equal (arg, "-debug")
          debug = true

        elsif is equal (arg, "-v")
          version = true

        elsif is equal (arg, "-u")
          unicode = true

        elsif is equal (arg, "-o") && i < argc-1
          out filename = new string (bundle, argv[++i])
          to OS name (out filename)

        elsif is equal (arg, "-I") && i < argc-1
          append (include path, new string (bundle, argv[++i]))

        else
          filename = new string (bundle, arg)

        end

        ++i
      end

From an aesthetic point of view, it doesn't look that bad. In this example, I think "is equal", "out filename", "to OS name" and "include path" are all identifiers. But I'm still wondering what kind of parsing and lexing issues that may arise.

<comment><USER7> I already have hard time parsing this code. The main problem I see, is that to read the code I have to know every single keywords in the language.

For example I was wondering if "new" is a keyword. If it is, then "new string ()" might be something interesting, otherwise it's just a function call.

Similarly this raises a question of whether I can write the following code:

      if end of line (str)

This might or might not be permitted because "end" is a keyword. If it is permitted, then the result looks pretty damn ambiguous to me. If it's not then I have to name my identifier differently, like so:

      if end_of_line (str)

But then I'm skrewing up the style of my code...

<comment><USER6> I thought of the recognizing a keyword issue, but then I dismissed it: syntax highlighting make it a non-issue. The ambiguity with using keywords in identifiers is valid, though.

<comment><USER8> Syntax highlighting is not available everywhere, e.g. in black-and-white print.

<comment><AUTHOR> Usually black-and-white print use bold to indicate the keywords.

</comment></comment></comment></comment></comment></comment><comment><USER9> Another Zinc: [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6772)

That one is more popular, it eventually became OCaml.

<comment><USER10> The Zinc paper is one of my all time implementation papers, right up there with Dybvig's thesis, Rabbit and Orbit papers on Scheme, Reppy's thesis on Concurrent ML, and SPJ's Tagless paper.

The Zinc Experiment is Leroy at his best; compiler hacking lore meets programming language research (no hand-waving past performance issues, with a critical eye towards foundations.)

</comment></comment><comment><USER11> I will try to ignore the shallow (but horrifying) issue of identifiers including spaces.

The real question to be asked here is what is wrong with the current portable assembler (C) ? C has occupied this niche for a long time and quite successfully - I believe all current mainstream kernels are written in C (or possibly a limited subset of C++).

If you want a 'portable assembler', a modern C compiler is in my opinion, a good choice:

      - a solid specification: detailing the behaviour of operations, what is defined, implementation, or undefined behaviour.

      - access to platform specific features through builtins and intrinsics

      - ability to use inline asm if you really want to (or need to)

      - easy integration with existing libraries

      - minimal dependencies on a runtime library (pretty much none in freestanding implementations)

      - most compliers give have ways to get good control of both what code is generated and structure layout.

The modern C ecosystem provides (mostly good) tools for:

      - tracking memory leaks/invalid memory accesses (valgrind)

      - static analysis (clang static analyser, sparse, coverity, ...)

      - debuggers (gdb ...)

      - solid optimizing compilers (icc, gcc, llvm)

      - profilers (oprofile, perf, vtune, ...)

Admittedly, most of these tools don't depend on the code being written in C, but I suspect any new language would take a while to get properly integrated. If you want to use a low level language, you really want to have access to these tools or equivalent.

A new language trying to compete in this space would have to offer something fairly substantial to get me to switch - and a strange syntax like zinc is not going to help. From the documentation at least, zinc seems to currently be missing: an equivalent to volatile; asm; anyway to access a CAS like instruction; 64bit types; floats; a way to interface to C code; clear documentation about behaviour in corner cases (what happens if you a left shift a 32bit value by 40?). The only thing seems to bring to the table to compensate is the ability to inherit structures

<comment><USER12> I agree with you. I just wanted to list the one complaint I do have about C: missed optimization opportunities due to lax aliasing rules.

Consider the following C translation unit:

        void foo(const int *i);
        void bar();

        int baz() {
          int i = 1;
          foo(&i);
          return i + 1;
        }

        int quux() {
          int i;
          foo(&i);
          i = 1;
          bar();
          return i + 1;
        }

You'd like to think that both baz() and quux() could compile the return statements to a constant "return 2." After all, foo() is taking a pointer to a CONST int. But alas, this is not the case, because foo() could cast away the const. So in truth, both functions are forced to reload the integer from the stack, add 1 to it, and then return that! You can't use any values you had loaded in registers (or in this case, you can't evaluate the expression at compile time).

My example is contrived, but you can easily construct examples that fit the same pattern and are real.

I've heard that Fortran still beats C in optimization in some cases; I would expect that the above is one major reason why. C99's "restrict" addresses some of the difference but cannot help you with the above.

</comment></comment><comment><USER13> What is wrong with 64 bit integers? Maybe they've been indicted on war crimes or something. The number of languages that appear and don't support them.... And what about interfacing with C? I can count the languages on one hand that have a simple and efficient C interface! (I have a list of other things almost always ignored by languages for no good reason... efficiency, friendly license, lack of macros or ability to extend the language...)

</comment><comment><USER14> Interesting find. It seems to have been left to collect dust. Last changes are about 3 years ago.

</comment><comment><USER15> I guarantee that I would confuse the types "byte" (uint8_t) and "octet" (int8_t). The typical distinction between a byte and an octet has to do with the number of bits in the representation (a byte usually has 8, an octet always has 8). I don't know of any convention for bytes being unsigned and octets being signed.

<comment><USER16> You're right that with "byte" there isn't an official size specification, although the de facto size is 8 bits, unlike with "octet", which was specifically defined as 8 bits (for interoperability between different systems).

Regarding the question of signed/unsigned - I'll try to explain:

 _byte - <USER3>

On page 37 of the C99 standard: "A byte contains CHAR_BIT bits, and the values of type unsigned char range from 0 to 2^CHAR_BIT - 1)"

i.e. according to the C99 standard, a byte is unsigned.

 _octet - <USER4>

Think of an octet in two ways: the concept of something that is exactly 8-bits on the one hand, and on the other hand, the technical representation of this concept.

When you read the literature you'll notice that an octet refers simply to the size of something (8 bits) and not is signedness. For example, octets arguably arose in the networking world, and the NDR (Network Data Representation) refers to octet in sign-neutral way.

On page 256 of the C99 standard: "The typedef name int N _t designates a signed integer type with width N, no padding bits, and a two's-complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits."

Now, how would you go about representing the concept of an "octet" (which is sign-neutral)? If you used an unsigned 8 bit integer, you can't represent the sign of the (conceptual) octet, while a signed 8 bit type can.

</comment></comment><comment><USER17> This reminds me of a slightly higher-level High Level Assembly: <http://en.wikipedia.org/wiki/High_Level_Assembly>

Edit: the HLA web site always used to be a decent place to learn assembly language. I don't remember it being so mauve though: [http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/index.h...](http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/index.html)

</comment><comment><USER18> Related: assembly programming with Python syntax.

<http://www.corepy.org/>

</comment><comment><USER19> From the description: "The goal is to have a portable assembler." Why not just use Fortran?

</comment><comment><USER20> looks interesting but i cant get it to work on os x or linux.

<comment><USER21> Works for me. Here is how to do minimal 3-stage bootstrap.

      gcc bootstrap/io.c bootstrap/zc.c -o zc1
      ./zc1 -I lib -I lib/platform/default -I src src/main.zc -o zc2.c
      gcc lib/libc/io.c zc2.c -o zc2
      ./zc2 -I lib -I lib/platform/default -I src src/main.zc -o zc3.c
      cmp zc2.c zc3.c # should be identical</comment></comment>


Beyond Functions in Elixir: Refactoring for Maintainability - <AUTHOR> https://medium.com/@davelucia/beyond-functions-in-elixir-refactoring-for-maintainability-5c73daba77f3 <comment><USER2> I've been see more Elixir/Erlang stuff on HN recently. It makes me happy.

There's some useful stuff in here for sure. If this is your own blog post here is some feedback.

\- It contains a lot of very Phoenix-specific tips, that could be useful to have in the title.

\- I see you linked to the docs in a number of places. This is great. Blog posts can rot quickly into outdated documentation.

\- You mention using Phoenix 1.3. It might be nice to have that right at the top, so someone who stumbles on this in 2 years can determine whether it's relevant for what they're using.

\- You have all these examples of writing a blog application. Would be great to have this blog post hosted on that application itself, rather than Medium! ;)

<comment><AUTHOR> Thanks for reading, we're going to have a product blog set up on [https://theoutline.com](https://theoutline.com) in the coming months. That will be hosted on Elixir/Phoenix.</comment></comment>


The Power of Interoperability: Why Objects Are Inevitable (2013) [pdf] - <AUTHOR> http://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf <comment><USER3> The author makes arguments for the functionality that OOP encompasses, but doesn't attempt to explain why these should be grouped under one abstraction. Instead the author assumes that this should be the case, and rather naturally ends up with the answer of objects.

The author also has some curious opinions about FP approaches. For example, he points out that Haskell's type system distinguishes between homogenous and heterogeneous lists, but then considers this to be a disadvantage. I get the strong impression that the paper is arguing backward; assuming that the properties of common OOP languages are the ideal, and then deriving from that assumption the answer that OOP is the best paradigm.

</comment><comment><USER4> The author contrasts "objects" and "ADTs" (abstract data types), but uses - <USER2> my mind - an improvished definition of ADTs. I've always thought of _On the criteria to be used in decomposingsystems into modules_ (Parnas) as the key paper for ADTs, which the author cites (at [26]) but doesn't use for this purpose. Of course, different definitions are available.

The distinction the author uses is that objects can have different implementations, but ADTs can't.

From this follows a streams of motherhoods of the advantages of having different implementations.

Curiously, from my scan, he doesn't seem to mention evolution _of interfaces_. That is, instead of evolution being just a different implementation of an identical interface, it is much more common for something to be added: extra data, extra services, extra features. The typical approach is to leave everything the same (so that old clients still work with this new API), and strcitly only _add_ new methods (and/or types with superset values).

My reasonably involved studies of the evolution of Java classes in the standard packages for the purposes of serialization (which must store and recreate them), showed me that in practice, it's pretty rare for an implementation to change _without the interface also changing_. That is, I'm claiming:

      Interface evolution is more common than implementation evolution alone.

To be clear: although implemenation evolution can and _does_ occur (e.g. intern aspects of String recently), it's pretty rare to occur without the interface also changing. Not counting simple bug-fixes, which don't substantially change the implementation, and also not taking into account interfaces that were initially designed to have multiple implementation (e.g. collections, swing/awt, some networking classes etc), as these aren't evolution. (Though, I suppose adding a new implementation of existing interfaces e.g. LinkedHashMap (ordered map) counts as "evolution".)

This higher frequency of interface evolution may be a reflection that we get paid for features, not refactoring.

<comment><USER5> You can't have large flexible systems of any kind without some sort of fixed interfaces or protocols. There must be millions of examples. Sockets, ODBC, drivers, USB, nuts and bolts etc etc.

<comment><USER4> you skipoed parts of my comment: you can have those bnefits, by backcompatibility, which you do by evolving only by adding, not changing the part of the interface that is already there. All those examples you mention evolve, with later versions adding features that require the interface to be added to. They aren't "fixed", they are "backcompatible".

This also applies implicitly to any client for interop: you don't have to use the whole interface, just the festures you want. In effect, you are using different, smaller interface.

</comment></comment></comment><comment><USER6> Thank you, the term "service abstraction" indeed describes the - to my mind - optimal use case for the object model.

That is, as an easily discoverable interface between an established and supported platform and client code.

This is the word I had been missing when discussing the ups and downs of object model within our product's codebase.

Suddenly I have a tiny bit clearer abstraction model in my head of software.

This is the sort of nugget of gold I come to HN for.

</comment><comment><USER7> I agree with the idea that the abstractions provided are "inevitable." I disagree with the idea that the way we're using them is optimal.

I've just spent time in my code reducing polymorphic classes into simpler type identifier + record combinations. The rationale I am going by is that every class I introduce proliferates new symbols: the class definition, the instances, the methods, the values, the references to yet further symbols. Each time I introduce new symbols I bulk up the code and diffuse its meaning; the meaning of these symbols exists in the class, not at the call site. Thus, everything in a class definition is doing its job correctly as long as you want the class to be a true "black box" that hides behind the symbols it provides.

But in many situations, the algorithm is basically "business logic" and conveys the most meaning when inlined at the call site: "Given this type of data, do this. Otherwise, do that." This type of algorithm assumes a schema onto the data, which is usually our true intention; having determined the schema, we can cease further indirection and begin our actual computation. And in this code, ADTs become less important, because we've already used those to query for the data; when we have the queries abstracted, we can stop. We don't need to abstract the meaning any further. Relational database modelling is analogous; when the data is normalized, it's very indirect, yet also very simple. And this pattern can be followed from within a program as well.

Consider the "composable component-entity" model that has become somewhat of a cargo cult fad. These systems generally understand the entity as a record of "which components are used/where to find them/how they fit together". The implication is that a definite schema of "types of components and their properties" exists at or near the top level, and entities do not hide arbitrary blobs of data and functionality in deep recesses, as results when trying to build from class inheritance. Since the concept is poorly defined, actual implementations are all over the place, of course, but the general direction of it is towards flat/primitive/normalized.

The result I got from killing off some classes and inlining their functionality was that I found some lurking unused variables, clarified the top-level, improved the code's flexibility, and reduced total lines of code. So at least in this instance I seem to be on the right track.

<comment><USER8> Bitsquid recently had an interesting 3-part post on the design of the entity system for their game engine:

[http://bitsquid.blogspot.com/2014/08/building-data- oriented-...](http://bitsquid.blogspot.com/2014/08/building-data-oriented- entity-system.html)

[http://bitsquid.blogspot.com/2014/09/building-data- oriented-...](http://bitsquid.blogspot.com/2014/09/building-data-oriented- entity-system.html)

[http://bitsquid.blogspot.com/2014/10/building-data- oriented-...](http://bitsquid.blogspot.com/2014/10/building-data-oriented- entity-system.html)

Data is stored in flat, homogeneous blobs and linked together by integer ids instead of pointers.

</comment></comment><comment><USER9> "Some of the advantages of object-oriented programming may be psychological in nature. For example, Schwill argues that "the object-oriented paradigm...is consistent with the natural way of human thinking" [28]. Such explanations may be important, but they are out of scope in this inquiry; I am instead interested in whether there might be significant technical advantages of object-oriented programming."

This seems to be throwing the rhetorical baby out with the bathwater - programming is not only a technical activity, but in large part a technical activity performed BY HUMANS, and generally to satisfy requirements generated by other humans.

<comment><USER10> But it is a specialization.

</comment></comment><comment><USER11> _While there has unquestionably been some hype about objects over the years, I have too much respect for the many brilliant developers I have met in industry to believe they have been hoodwinked_

A careful student of psychology and history will soon realize that almost everyone is at least partly hoodwinked about something.

[http://www.paulgraham.com/say.html](http://www.paulgraham.com/say.html)

That said, what's popular most often has at least some merit.

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

</comment><comment><USER12> Reading about this stuff reminds me of watching a grass fire: there's a huge amount of smoke and activity going on, but I'm really not sure where the flames are -- or if it should concern me.

Working with Ocaml and F# over the past few years, in small and smallish medium-sized systems, I've been fortunate to have an environment where I can use any paradigm I want in a natural setting. And while I've gone from an OO- diehard to an FP fan during that time, I haven't given up on objects.

I think systems "mature into" objects. I do not believe they should start with them. (Which is completely opposite of what I thought several years ago) Functionality gets created, tested in various scenarios, and then -- and only after a good amount of exercising by various other systems -- does it get grouped into ADTs, objects, or whatnot.

Note that I am describing how these things are created, not what they _are_. For practical purposes I could care less whether this chunk of bytes is exposing a service or providing a type. Of much more immediate concern is _why should it be in this shape?_ I think if you start functionally, you are free to let the problem domain determine the shape of the mature code. Whereas if you start with some kind of preconceived notions of where you're ending up and why, you're making assumptions about the optimized solution that may have no justification.

tl;dr -- you're asking the wrong question.

</comment><comment><USER13> The author is accidentally promoting functional programming, without realizing it. He emphasizes "interoperable extensions" and "service abstractions" but what he's really describing are functional type signatures and interfaces.

His writes: "I now propose a candidate for the leverage provided by object- oriented service abstractions in design: The key design leverage provided by objects is the ability to define nontrivial abstractions that are modularly extensible, where instances of those extensions can interoperate in a first- class way." But he describes is not "object-oriented" in any sense of encapsulated data, internal state, and methods. Instead he describes the fold function, map function, and higher order functions.

The author touches on Alan Kay. Kay wrote this: "I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging" ... The Japanese have a small word -- ma -- for "that which is in between" \-- perhaps the nearest English equivalent is "interstitial". The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be."

<comment><USER14> Do you really believe the author of a paper explicitly about investigating the technical advantages of OO which also happens to touch on Haskell and ML is simply clueless about functional programming? And this ignoramus has somehow faked his way to the position of director of CMUs Software Engineering PhD program.

This seems like a stubbornly obtuse way to not engage in the paper's arguments.

<comment><USER15> Indeed; I have had the pleasure of having correspondence with Dr. Aldrich in the past. I had interest in implementing a static compiler for CMU's Plaid programming language, but found Go sufficient at the time. He also became involved with development of the Wyvern programming language. Nonetheless, he is well versed in programming language design and theory as that is his area of interest. It would be hard to imagine any related ignorance on his part.

<comment><USER16> Jonathan aldrich does come from the UW side of PL, which leans toward objects (a bias I share as well). But he knows his FP. Still, I'm not much for arguments by authority; either you see a proper comparison in the paper or not (I haven't looked closely enough). What both William and Jonathan both seem to miss, however, is more a discussion on object thinking, which I think would make the difference between OOP and fp more clear from a design perspective.

<comment><USER14> I don't think this is really an argument from authority since I'm not saying 'he's right because he has a PhD and teaches at a renowned university'. I'm saying that assuming he's ignorant of FP given both what he says in the paper and his background is silly and shallow.

It's not really fair to say that Aldrich 'misses' a discussion of object thinking, he just chooses to put the focus of that particular paper elsewhere - this is from the intro

 _Some of the advantages of object-oriented programming may be psychological in nature. For example, Schwill argues that "the object-oriented paradigm...is consistent with the natural way of human thinking" [28]. Such explanations may be important, but they are out of scope in this inquiry; I am instead in- terested in whether there might be significant technical advantages of object- oriented programming._

and

 _This success raises a natural question: Why has object-oriented programming been successful in practice?_

<comment><USER16> Everyone reads these papers from different perspectives, so it's quite easy to say someone missed something (fair or not).

My criticism is that an analysis of OOP is incomplete if you avoid looking at...objects. It's like saying, we are going to ignore the objects themselves, and just focus on the technical features of the objects to see what the technical advantage of these features are. It is very reductionist...while objects favor a more holistic manner of thinking.

<comment><USER14> We probably (broadly) agree more than disagree. One reason FP/OOP comparisons are difficult is that FP is closely related to a mathematical formalism while OOP isn't and can't be. I think the tack he's taking is 'can we explain the popularity of OOP in terms of "technical" or really, "practical programming/software engineering" advantages'. It's a tricky needle eye to thread.

The objection 'that approach can't lead to useful insight' is a reasonable one but I don't think he's taking the approach out of ignorance or because he spaced out on something while typing it up - it's a deliberate choice, whatever its merits.

<comment><USER16> Ah, I never said he took this approach out of ignorance. I've talked about this with him before, and never found his arguments lacking.

It is nice that something is still going on in OOP.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> From a discussion we had about this paper, in the context of the relational logic language we are working on:

Data abstraction is an interesting topic in a language that doesn't really have data structures. ADTs are usually used to describe the allowable operations on either a data structure or some side-effectful system.

For describing data _models_ , we have tables and (soon) integrity constraints. An integrity constraint is a rule which aborts the transaction if it produces any output. Simple integrity constraints like column types and foreign keys can potentially be removed when the compiler can prove that they will not be violated.

For derived data, rather than providing a method which returns the desired information, we define a view on the data eg instead of a getTotalSalary method we would define a rule that inserts data into the totalSalary table which is then either lazily evaluated on query or materialised and incrementally updated.

For modifying data we currently have no alternatives to directly working on the base data. There is some amount of work on bidirectional relational views but it seems like it adds a large amount of complexity for a problem we don't currently have.

We do intend to make scalar values and functions extensible, similar to [http://www.postgresql.org/docs/8.3/static/xtypes.html](http://www.postgresql.org/docs/8.3/static/xtypes.html)

For side effects, we request actions by adding a row to a table that has a watcher attached. The interface is described by the set of tables available eg

        jobs started (id, input data...)
        jobs to be cancelled (id)
        jobs completed (id, output data...)

[http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf](http://db.cs.berkeley.edu/papers/eurosys10-boom.pdf) and [http://db.cs.berkeley.edu/papers/vldb14-edelweiss.pdf](http://db.cs.berkeley.edu/papers/vldb14-edelweiss.pdf) describe variations on this approach. Our current editor prototype uses the Edelweiss model, which is my preferred choice if we can make it work smoothly. The main difficulty so far is in constructing stable ids to ensure that actions are idempotent.

In any case, for most protocols you need to constrain not just the types of individual messages but the allowable sequences. ADTs don't help here. Where the protocol can be described by a state machine we can simply encode that state machine in a table and have a rule that verifies message histories and provides a list of currently allowable actions.

<comment><USER16> Why would stable ids be a problem? Is it because immutability doesn't give you any stable references to latch on to?

<comment><USER8> Have a look at the Edelweiss paper I linked. Stable ids are needed for that model. We would probably be fine with eg random uuids if we stuck with Bloom.

EDIT: Thinking about it, the issue is definitely not that it is immutable but that it is declarative. In the absence of control flow, `new` is not sufficient to provide unique identity because the rule in question may be run zero or more times.

<comment><USER16> Alot of work in glitch goes into solving this problem. In the new case, we are able to form stable (reproducible) IDs through a memoized lexical stream (re- lex will produce the same tokens if possible) and by using the call stack (so the id is a path with special ids for loop indices). For a declarative (rule based?) language, perhaps rule firing context could be used for a similar purpose; I'll try to look at that paper and see if something clicks. I guess it depends on what makes a unique object.

Though if you are completely declarative, why would object identities be necessary?

<comment><USER8> For largely the same reason that relational databases need identity. The classic example is the users table. Everything about the user, from their username to their email address, can be changed. So you need some way to stably reference that user. In the timeless Tarpit/Edelweiss world, the current state of the program is a pure function of its inputs. That means that the id has to be deterministically derived from the inputs.

For now we synthesise ids out of contextual information eg "the user created at time T by event X". This works for now but it feels a little awkward. Once we have written more code in Eve we will have a better set of examples to guide thinking about a solution.

<comment><USER16> Isn't that effectively mutation then? You have an ID with information related to that ID that changes, or what we would call mutable fields in the object world. Anyways, this is why I don't play with declarative programming models anymore: I would wind up hacking in necessary things like identity and mutation in very weird ways. This is why I decided instead to try applying declarative time semantics to an imperative programming model.

Your solution is quite similar to mine: all blocks that continue in after clauses underneath an event are indexed by the event instance (we memoize event instances so they have identifiers). One problem that we had to deal with is the discrete nature of an event handling context; it made sense to have an additional clause that continues after the event (to create an object like a new user) vs. code that executes discretely (like a physics step). The former gets indexed by the event instance, the latter is shared across all event instances (so you can't really create an object in anything other than a top-level block of event-after block).

<comment><USER8> I'm not sure where you got the idea that we are proposing a language where nothing ever changes :p

Both Bloom and Edelweiss are ideas about how to model time/change declaratively ie without having to specify control flow or incidental ordering. That doesn't seem to be too different to Glitch. Whether you think of imperative code pushing updates to data structures or declarative code pulling updates from stream is a matter of perspective. Either way, you still have to figure out how to order and combine those updates.

Bloom takes the approach that each fact is true at an explicit point in time, so rather than mutating in place you simple define the state at time T+1 in terms of the state at time T. Both states are simultaneously accessible so you don't have to worry about what order the changes happen in.

Edelweiss takes the approach discussed in Out Of The Tarpit where the true state is just the list of input events and everything else is an incrementally maintained view over these events. Edelweiss makes this practical by analysing datalog code to determine when an input event can no longer contribute to the state of the system. This is roughly analogous to GC, except that instead of relying on pointers to determine unreachability it uses static analysis. The appeal of this model is that you can always explain the state of system to the programmer by tracing backwards through the views.

<comment><USER16> I don't think you are, and neither am I. What we both want is controlled change, we are just going about it from different directions.

I'm still trying to get a handle on Bloom and this discussion is useful, thanks! Glitch is based on the same GC analogy but does a pure dynamic analysis: input events generally never wash out of the system since they are often clock ticks that step a physics simulation :)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER4> html version [http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...](http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fwww.cs.cmu.edu%2F~aldrich%2Fpapers%2Fobjects- essay.pdf)

I'd almost forgotten this trick, just google _cache:[http://www.cs.cmu.edu/~aldrich/papers/objects- essay.pdf](http://www.cs.cmu.edu/~aldrich/papers/objects-essay.pdf) _

request: could HN do this automatically pls? (similar to how it used to provide a second link to scribd for pdf) I _always_ prefer a html version, to assess it. If it's interesting, and diagrams/formulae are garbled, I can always get the pdf later.

<comment><USER17> PDFs render inline wonderfully for me in both browsers I use without plugins.

<comment><USER4> I'm on a phone (but maybe that would be fast enough... I'm using stock: no plugins)

</comment></comment></comment><comment><USER18> The big idea with OOP is "messaging". Right. What makes messaging useful is that the 'messagee' typically understands more than one different message. Because if it only understood one we couldn't take advantage of composing the interaction with them in different ways, as needed by the client.

When we can do that we can also replace the messagee with an instance of some other conformant class, and thus we can reuse the client-side implementation of the interaction-protocol with many different types of recipients.

Using the word "replace" here is easily misleading. A better word is "reuse". We don't typically DELETE the original service object at all. More likely we just REUSE the same client-code with different types of "service objects". The point is it can interact with many differently implemented service-objects that offer the same interface.

If each class defined only one message it responds to, that wouldn't look like OOP, would it? It would look like FP where functions basically understand just one message, "Tell me your value!".

Of course FP languages can simulate OOP and vice versa. Smalltalk for instance defines the class BlockClosure which understands the message #value: (among others). That means - "Tell me your value for this argument". But BlockClosure also understands other messages, like #asString, #class etc. That is OOP.

We could say that OOP is a generalization of FP in this sense. Objects can do what functions do, calculate their "value" for a given argument. But this operation is explicitly declared as just one of the operations that object can perform. There is NO SPECIAL syntax for it, like "()" in FP languages.

JavaScript can be characterized as a functional-object -language because its functions are first-class citizens but they can also have other operations than calculating their value. We can for instance "send the message" .toString() to them to get their source-code.

You could have a "messaging conversation" with a JavaScript function (-object) like this:

Me to function: "Hey tell me your source-code". The function returns it

Me to my Helper -object: "Hey helper, does this source-code look secure?". Helper returns "Yes".

Me to function: "OK, I trust you. Tell me your value for argument 42!". Function returns it.

The conversation / messaging above could be reused with some other type of object without having to modify the client-side code at all.

Summary: The essence of OOP is that objects can declare MULTIPLE messages they respond to, thus defining the protocol they can be interacted with. Many objects can support the same protocol of interacting with them, but provide a different implementation as to how they actually calculate some (or all) responses to the messages they get.

</comment><comment><USER19> This was 2013 and he never heard of the CLOS arguments against traditional objects as he describes it, and he attributes Alan Kay with generics and method based OO dispatch, the functional approach?

All these arguments were already cleared in the early 1990's, and people still don't get it. CS scholar's shouldn't care about the popularity of certain languages, or do they wanna teach VB or PHP?

Objects are of course evitable, functions can do more, can do it better, and functions can represent not only scoped blocks (variable hiding), but also objects easily.

[http://www.gigamonkeys.com/book/object-reorientation- generic...](http://www.gigamonkeys.com/book/object-reorientation-generic- functions.html) talks a bit about this mindset, mentioning also Kay's simple dynamic message passing approach.

<comment><USER20>
      Objects are a poor man's closures.
      Closures are a poor man's objects.
      -- Guy Steele</comment></comment>


4th Amendment does Not apply to data stored with third-party providers. - <AUTHOR> http://volokh.com/2009/10/http://volokh.com/2009/10/28/district-http://volokh.com/2009/10/28/district-judge-concludes-e-mail-not-protected-by-fourth-amendment/28/district-judge-concludes-e-mail-not-protected-by-fourth-amendment/

<comment><USER2> Posession is 99/100ths of Internet Law. I think similar logic led to a ruling that Google did not infringe on plaintiff's IP because Google did not host the images displayed on its pages.</comment>


Ask HN: How long do you work per day? - <AUTHOR> It is curious that a lot of people in Asia countries work extra long hours(eg,9AM - 9PM) <comment><USER2> About 8</comment>


The Omega Man: "Math is built on randomness" - <AUTHOR> http://www-2.dc.uba.ar/profesores/becher/ns.html

<comment><USER2> <http://en.wikipedia.org/wiki/Chaitin%27s_constant>

But seriously, don't upvote this story, it is written by a fifth grader (or at least makes that its audience).

EDIT: In response to the comment below ("just because it's simplification doesn't make it inaccurate"):

Because it's not "simplification." It's--pardon--bullshit. Chaitin's constant has nothing to do with "randomness in mathematics."

Besides, number theory is certainly not "the foundation of pure mathematics." Gauss would say that in the 18th century ("Number theory is the Queen of the Sciences"), but obviously it's long been replaced by logic, model, and axiomatic set theory.

Here, I'll condense the article to one sentence:

 _In other words, the randomness of the digits of Omega imposes limits on what can be known from number theory--the most elementary of mathematical fields._

There. So what? There are limits on what can be known from _anything_ in mathematics. Nothing to see here.

[http://en.wikipedia.org/wiki/Diophantine_equations#Typical_q...](http://en.wikipedia.org/wiki/Diophantine_equations#Typical_questions)

This is just saying that some of those five questions are answerable by Chaitin's constant for that particular huge Diophantine equation.

EDIT2: Disclaimer: I am a graduate student in mathematics.

<comment><USER3> A big part of the problem is that Chaitin is a shameless self-promoter. He is the Bruce Schneier of Algorithmic Complexity. Actually, no, Schneier is not nearly as bad. Let me quote from the highest voted Amazon review of his book:

"Let the author speak for himself. From page 7, "Gödel's 1931 work on incompleteness, Turing's 1936 work on uncomputability, and my own work on the role of information, randomness and complexity have shown increasingly emphatically that the role that Hilbert envisioned for formalism in mathematics is best served by computer programming languages[.]"

Imagine if a working composer wrote, "Bach's preludes and fugues, Beethoven's symphonies, and my own string quartets have shown increasingly emphatically..." This man's reputation in his declared field is nowhere near his apparent stature in his own mind. The ideas discussed in this book are worthy of late-night musings over a nice brandy, or maybe a Scientific American article, but only after extensive revision. They are not ready for publication in a monograph. "

<comment><USER4> I assume you weren't really picking on Schneier. He's a self-promotor in a pretty healthy sense. He has written much content on the human aspects of security useful to laymen. He does so without being arrogant or saying "I invented this". All in all, a good educator that doesn't talk down to his audience and can explain things so that his "grandmother could understand" (my favorite Einstein principle). He has interwoven this practice into his business, the beneficiary of his self-promotion, which seems to have done well for him.

I might even recommend Schneier as the poster-boy of healthy entrepreneurial self-promotion.

<comment><USER3> No, didn't mean to pick on Schneier. He's a self promoter, but the analogy breaks down after that.

</comment></comment></comment></comment><comment><USER5> The first day at University, my Maths Professor told us: "We will asssume you never knew about Maths and we will start fron the beginning". We defined what a number is, what addition is ... and from theorem to theorem we reached some very high and complex domains in Maths a few years later. The process of understanding each step, each demonstration and ultimatly each concept - starting from scratch - made few students among the group Maths masters.

<comment><AUTHOR> That is really neat. I've never had that experience, and I definitely envy you.

<comment> cool-RR You can just attend calculus 101 when the next semester opens, in any university.

<comment><USER6> You mean audit a class? Not sure why you got downmodded, as far as I know you most universities allow people to audit as much as they want.

Edit: Never mind, you go the downmod for saying calc 101 - it's certainly not a 101 class.

<comment><USER7> Not 101 (technically it was labeled 161), but at the Univ. of Chicago (where I went), Spivak was the first Calc class on the honors track--i.e. the honors variant of 101. And that course did exactly what he's talking about.

</comment></comment></comment></comment></comment><comment><USER8> Another introduction to this same topic, that goes much further and is better written:

<http://www.scottaaronson.com/writings/bignumbers.html>

<comment><USER2> _You have fifteen seconds. Using standard math notation, English words, or both, name a single whole number--not an infinity--on a blank index card. Be precise enough for any reasonable modern mathematician to determine exactly what number you've named, by consulting only your card and, if necessary, the published literature._

Judging by the rest of the article, I would have won. I would have written "Ackermann function on Graham's number and Graham's number." For added enjoyment, add "Call this B_1. Define B_n = A(B_n-1,B_n-1) for n > 1\. Now take B_(B_1)."

EDIT: Or I guess just:

 _Let G be Graham's number. Let B_n be G if n = 1 and A(B_n-1,B_n-1) if n > 1 (where A is Ackermann's function). Take B_B_2._

<comment><USER9> I think your number is the XKCD number:

<http://www.xkcd.com/207/>

<comment><USER2> Yep!

Only my second example was doing that recursively...oh the horror...

</comment></comment></comment></comment><comment><USER10> Doesn't this mean that

1) There exist mathematics (systems of logic) for which there is no way to reach logically from what we know now to how this system works, it must be intuited

2) But does this mean that reality is embedded in one of these mathematics? This is not necessary as far as I can see, so this still leaves the door open for a theory of everything in the physical world (string theory or some such).

3) But it does seem to imply that no infinite system can be described by a finite system ( a restatement of Godel ). So we can't set up a computer program to run the universe - no real surprise there.

or are the implications bigger?

from <http://plus.maths.org/issue37/features/omega/feat.pdf>

"To put it bluntly, if the incompleteness phenomenon discovered by Gödel in 1931 is really serious and I believe that Turing's work and my own work suggest that incompleteness is much more serious than people think then perhaps mathematics should be pursued somewhat more in the spirit of experimental science rather than always demanding proofs for everything. Maybe, rather than attempting to prove results such as the celebrated Riemann hypothesis, mathematicians should accept that they may not be provable and simply accept them as an axiom"

So, for example, if we have the axioms of set theory, then for any theorem, it may not be possible to prove this theorem from the axioms as a set of linear deductions, somewhere along the line we may find a new theorem that requires to be stated as axiomatic, i.e.

we have axioms A,B we have theorems C,D,E provable from A,B then we find F which seems to be true, but we can't prove F from A,B, F must be stated as an axiom, probably not that surprising really.

Again just because systems like this exist, doesn't mean we live in one.

</comment><comment><USER11> Call me uneducated, but isn't the rock solid foundation for math the real world? To the extent that math corresponds to the real world, it is correct. The "halting problem" sounds like an attempt to predict the future with math, which seems like a futile effort. Maybe the conclusion from the "randomness" in trying to predict the future is that such predictions are simply not possible and a waste of effort?

<comment><USER8> You are Not Even Wrong, in this instance.

Math is not a simulation of the real world; to take a simple example, both Euclidean and hyperbolic geometry are self-consistent and useful, and yet clearly different. So "the rock solid foundation" of math is not the real world, but rather sets of self-consistent axioms.

The halting problem is not an attempt to predict the future with math; it's a description of a property of algorithms which is inherently non-computable. You cannot, in the general case, prove whether an algorithm halts or not.

So as to your the question of whether the "randomness" comes from trying to predict the future...the answer is not yes, nor is it no. The question is not sensible.

The article was very poorly written though, so I'm not surprised it causes confusion. If you are interested in actually learning about Omega, I recommend <http://www.scottaaronson.com/writings/bignumbers.html> which is an amazing introduction to all these ideas.

<comment><USER12> _So "the rock solid foundation" of math is not the real world, but rather sets of self-consistent axioms._

You're mostly right, but there's a fun twist. The self-consistency of e.g. Peano arithmetic (natural numbers) ultimately rests on our intuitions about the real world - it can't be proven starting from nothingness.

</comment></comment></comment><comment><USER13> > Chaitin's discovery implies there can never be a reliable "theory of > everything"

Just because gravity works every time we check, there's no certainty that it will work the next time.

Physics disproved - I'll take my Nobel please.

</comment><comment><USER14> Let me try to summarize. Out of all possible mathematics, there is something mathematicians care about and also there is a lot of crap. This is really not that surprising...</comment>


Conks - <AUTHOR> http://c0nrad.io/conks/

<comment><USER2> Why is this interesting or news-worthy?

<comment><AUTHOR> Meh. It's not really interesting or news-worthy. But it's an example of how you can have fun learning. If it inspires someone else to pick up their old game they were making, I'd be more than ecstatic.

</comment></comment><comment><AUTHOR> It's Backbone.js with HTML5 canvas.

[http://github.com/c0nrad/conks](http://github.com/c0nrad/conks)</comment>