Apple is developing a feature for using apps without requiring full downloads - <AUTHOR> https://9to5mac.com/2020/04/09/ios-14-apple-developing-clips-feature-for-using-apps-without-requiring-full-downloads/ <comment><USER2> It seems very similar to Android feature called Google Play instant: [https://developer.android.com/topic/google-play- instant](https://developer.android.com/topic/google-play-instant).

<comment><USER3> This (or something like it?) has been available for ages, but the only time I've ever actually encountered it in the wild is with links to a JIRA project.

<comment><USER4> A local news site uses it, however as that's in a (distant) second language for me, and I discovered their app doesn't let me select to copy-paste words into a translator, it wasn't useful. Probably just an issue with their app implementation however.

<comment><USER5> Screenshot -> OCR -> Translate

</comment></comment></comment></comment><comment><USER6> I have an app written in Swift and weights between 8-20Mb(depending on device and iOS version), which is not too far of from a typical website these days and the startup times are phenomenal(between 250-500ms, depending on the devıce).

Writing in Swift is a delight and this is the feature I was dreaming about because having the user to install the App is not easy these days(100 impressions on Appstore Search would get me about 8 installs) however the people who install it are quite happy according to the feedback.

I would imagine that the experience is similar to Apple's AR experience on Safari, which I feel can be improved but much nicer than opening the Appstore still. Let's hope that it's not too limited and can be possible to give a good feel to the user about the App's full functionality.

The article talks about letting the dev to pick which part of the App would be presented but I suspect that the actual implementation would be similar to making an App Extensions - basically creating a separate mini-app that shares the codebase and the resources.

<comment><USER7> It's hard to imagine, but some DOS apps had <100ms startup time on a 486 while coming full-featured on a 1.44MB floppy disk.

I agree that your app is small and fast compared to what others are putting out there, but compared to what software engineering could do if people cared, this is still bloated and slow.

<comment><USER8> And it had 2 squares on the screen with 10 pixel letters inside them saying 'Proceed y/n'?

What kind of a comparison is that? People do care, it's just they care about ease of use (not putting strain on your sanity) over some imperceptible startup time difference or space difference on hard drives that get cheaper every day.

<comment><USER7> Nah, it was a full cashier system including a bar code scanner attached through that big printer port.

I believe Circle K still uses pretty much the same UI, because that mouse-less keyboard interface can be used efficiently with one hand.

Not everything needs to be pretty to work well.

</comment></comment></comment></comment><comment><USER7> The reason why this is needed at all is because a todo list regularly needs 20 MB updates.

The problem is that there is no incentive for developers to keep their apps small. And since Apple makes money from selling larger phones, they also have an incentive to tolerate bloat. And lastly, your provider will be happy to charge you astronomical fees for downloading that critical update over mobile data.

There's nobody making money from small apps but 2 of 3 parties can monetize bloat. So bloated apps it is!

The name Clips and the QR scanning suggests to me that this will be used for advertisements, like those AR overlays.

<comment><USER9> Well if the feature is successful and apple puts a hard limit on binary size for it then it might incentivise developers to ship less bloated apps.

</comment></comment><comment><USER10> Android has Instant Apps. Not sure how others feel but I hate it. Compared to a website it's slower to load, harder to share, and outside of my normal flow.

I guess it would be cool for a demo but I dunno. Also iOS apps are so large this won't be practical at all on cellular data.

<comment><USER11> >Also iOS apps are so large this won't be practical at all on cellular data.

They don't have to be. For example Tweetbot, which is a fully functional app, is only about 7MB. It's not hard to imagine that a single screen of an iOS app specifically optimized for space could be only a fraction as large – considerably smaller than the average site these days (10MB+).

<comment><USER12> They're big because of swift. Tweetbot is small because it's still only Objective-C.

<comment><USER11> That should be changing as more apps drop older iOS versions and stop bundling Swift.

<comment><USER9> Exactly, an app of mine targeting iOS13+ weighs in around 2mb.

</comment></comment></comment></comment></comment><comment><USER13> Wouldn't it be more surprising if Apple wasn't working on something like this? Even if it is true, basically it sounds like someone leaked out a test build of something. They're probably prototypes for all kinds of crazy things, some good some bad, just like everywhere.

</comment><comment><USER14> This looks similar to wechat mini programs. They are instants apps availible from within the chat app. They are very easy to share. They are a real game changer. E. G you go to a restaurant scan a qr code and order and pay through the mini program.

</comment><comment><USER15> Sounds like a horrible idea. Why on earth would I want the act of scanning a QR code to start downloading & executing random code. Heck native code too since they say it's an app.

<comment><USER16> Well that what you are doing when you scan a QR code a put the URL in your browser. You download random code that the server send to you, and execute it.

</comment></comment><comment><USER17> This could be a real game changer. I think it might be part of the drive into AR

Instagram and snapchat have ways to launch interactive experiences from a code and I've always thought Apple are missing a trick there.

One of the biggest hurdles getting clients to make apps now is "no one downloads apps anymore" so this could make a huge difference and make more frivolous interactive experience work in apps again.

I hope this happens soon.

</comment><comment><USER18> MIUI has had this for a couple of years already. Leverages the Android feature for Google Play Instant as @esmi mentioned. I dont know how it works but effect appears to be a wrapper of sorts is setup for the app so the app itself does not get installed. Not all apps support this mode for reasons with which i am not familiar.

</comment><comment><USER19> Every app i've seen use this uses it to implement a "microsite". for eg nytimes made an instant app for the crossword puzzle on android... except if i'm into crossword puzzles i'll download the app anyways,why the hell would i download the instant app everytime unless it was part of my "flow" ie read the new york times paper and then the crossword is sent to my phone automatically or something? except i'd be reading the paper on my phone as well?

the usecase for these kinds of things is so muddled and unclear i don't understand the point...

</comment><comment><USER20> They already have such a feature: on-demand resources ([https://developer.apple.com/library/archive/documentation/Fi...](https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/On_Demand_Resources_Guide/index.html))

The change seems to be that this allows all code to be downloaded on demand, not just scripts.

</comment><comment><USER21> I wonder if a phone OS will move to Google Stadia-esque offer: your device is just a remote viewer, everything including rendering the UI happens on their backend (Marketing has a field day touting Cloud-features), and is streamed to your device.

Of course it'll be limited to places with high speed cellular Internet, but hey 15 years ago no one thought we'd be able to stream 3D games over the Internet..

<comment><USER22> This is similar to AWS Workspaces but for mobile. The biggest concern is obviously privacy and security.

</comment></comment><comment><USER23> Every time I hear about things like this, I think about XKCD's take: [https://xkcd.com/1367/](https://xkcd.com/1367/)

We really are reinventing web pages on a regular basis

</comment><comment><USER24> This is common in Windows environments and is called app streaming / virtualization there. It's been included in Enterprise editions of Windows feature called AppV. This must be something similar. App Store sales more profitable than iphone/iPad device flash size?

</comment><comment><USER25> Considering that nowadays the average website is clocking in at dozens of megabytes of obfuscated JS and/or WebAssembly, I'm looking forward to lightweight and snappy native applets as an iOS alternative. Hopefully Apple enacts a hard limit on size.

</comment><comment><USER26> So, apple don't want web app to be first class citizens and then reinvent web apps?

<comment><USER27> The web is the biggest threat they face to their App Store.

They see the writing on the wall with technologies like wasm blossoming, and with web APIs beginning to open up possibilities for "native"-quality apps.

So they're interested in anything that can reduce the friction necessary to get into native iOS apps.

<comment><USER28> It's quite amusing to look back to iPhoneOS 1, where they doubled down on web apps without an AppStore.

</comment></comment></comment><comment><USER29> Seems like a terminal, storing the content in the cloud like a container where the app lives up there instead of in your localhost, but still uses the native interface APIs.

</comment><comment><USER30> Hope the security around this is air tight. Otherwise this will definitely be a new attack vector hackers will be using to get malicious binaries running on your phone.

</comment><comment><USER31> Sounds like a great attack vector to me.

<comment><USER32> How?

</comment></comment><comment><USER33> This is going to be another Apple success story along the lines of: Yes, others have had this for years in theory, but nobody actually ever used it. Apple enter the market super late but instantly capture it fully because they're the only ones not monumentally sabotaging themselves.

</comment><comment><USER34> Is this like Microsoft Office 'click to run'?

</comment><comment><USER35> This is probably going to make iOS more bloated, but perhaps Apple could surprise us.

If people swap out QR codes with malicious ones in real life, that could have all sorts of implications.

<comment><USER9> > If people swap out QR codes with malicious ones in real life, that could > have all sorts of implications.

This can already happen with a QR code and a website? I doubt these aren't going to be heavily sandboxed.

</comment></comment><comment><USER36> > this new API, we can say that it allows developers to offer interactive and > dynamic content from their apps even if you haven't installed them

Also formerly known as Web Applications but now made by Apple with the added features of less control from the developers, a 30% mandatory fee if you accept any payments of any kind and locked to just one platform.

<comment><AUTHOR> Nice snark, however web apps are still possible, and Android has a very similar feature (Instant - enabled by slices). Did you provide similar feedback when that was announced?

<comment><USER36> > Did you provide similar feedback when that was announced?

I did not, as I'm a lot more bored at this point in time and also have a lot of more free time.

But I do feel the same about both of the platforms movement towards "instant apps" that could have been equally solved by making web apps work better on respective platforms, instead of trying to solve the same problem again.

<comment><USER37> > But I do feel the same about both of the platforms movement towards "instant > apps" that could have been equally solved by making web apps work better on > respective platforms, instead of trying to solve the same problem again.

The web ecosystem has been trying to solve this for almost a decade now and has made relatively little progress. There's no reason to believe Apple could suddenly solve it in a few months if they just cared a little harder.

Web components & shadow dom are approaching 10 years old and still have issues with framework & browser support. asm.js is 7 years old, yet the ideas birthed from it are still struggling. Effective parallelism is still largely nonexistent. RAM & CPU/GPU efficiency remain a bad joke, made worse by the entire world now running on battery power.

A _huge_ number of people are working on making web apps more viable, including people at Apple. It's not from a lack of trying at this point. The foundations are just all terrible & wrong for being an app platform. That's never what it was built or designed to be, and retrofitting that without breaking compatibility is really really difficult. If it turns out the incremental delivery benefits of the web can be retrofitted to an existing app platform more easily than the web can be retrofitted to be an app platform then... well, why not? The cross-platform-ish nature of the web was (and is) a great dream, but why can't that dream be realized by SwiftUI instead? Or Flutter? Or whatever? Why must it be web alone that gets to be that thing?

<comment><USER38> > There's no reason to believe Apple could suddenly solve it in a few months > if they just cared a little harder.

No, they really could just solve it. Progressive web apps are _so close_ to being useful. Apple just refuses to make them user-friendly to install. Just look at android for what's possible [https://web.dev/progressive-web- apps/](https://web.dev/progressive-web-apps/)

<comment><USER37> > Progressive web apps are so close to being useful

PWAs have been pushed since 2015. 5 years of perpetually being "so close to being useful." And that's despite Google's _heavy_ promotion of them, including building an entire OS around them.

<comment><USER36> PWAs are also actively worked _against_, at least from Apple. See [https://news.ycombinator.com/item?id=22686602](https://news.ycombinator.com/item?id=22686602) for a previous discussion

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> looks like they are reinventing the web?

</comment><comment><USER40> I guess not to be confused with Apple's Clips app which is for making short selfie videos. [https://www.apple.com/clips/](https://www.apple.com/clips/)

<comment><USER41> For anyone with an iPhone who has never given this app a try, I recommend it-- it's surprisingly powerful and fun to use

<comment><AUTHOR> Agree - just used it today to mash together 5 videos of my family saying happy birthday to my sisters. Worked great, and a really fun result.</comment></comment></comment>


On dashes, hyphens, and other important aspects of life. - <AUTHOR> https://medium.com/typography/989bb7902cf3

<comment><USER2> This is going to be an unfair comment.

Today marks the first occasion that I saw the title of a post on HN, then saw that it came from Medium, and on the basis of its domain name decided that it would probably be a fluffy and superficial treatment of the topic alluded to in the title, where typography (ironically enough) and a very generous x-height gave the impression of substance to something that was in point of fact really barely worth writing or reading in the first place.

Having noticed this thought arise, I decided I better go through to read the article and see if I was right.

<comment><USER3> This article reads like a piece from a content farm. I flagged it and going forward the urge to flag everything from Medium will be hard to resist.

</comment></comment><comment><USER4> Writing 'twenty eight' as 'twenty-eight' is accepted practice? The looks very odd to me. But perhaps that's a difference between British and American forms.

Also 'friendly-looking' isn't joining together two adjectives , it's making a compound adjective.

<comment><USER5> It makes sense, as it would remove the ambiguity of something like "Those are twenty eight year olds." Am I referring to 20 children, or some number of adults?

</comment></comment><comment><USER6> I'll never understand typesetting fans. Two spaces after a decimal point is confusing and incorrect (even though it has the advantage of using buttons that are actually _on the keyboard_ ) whereas having three different kinds of dash that are identical except for width (the middle one being generally indistinguishable to the layperson's eye) is perfectly sensible.

</comment><comment><USER7> In HN style I'm going to comment by bashing a very minor detail of the article: at my current page width the subtitle: "Below I cover the common uses of three horizontal marks: the hyphen -, the en dash –, and the em dash —." breaks lines so that a new line starts with a comma and that's very bad!

</comment><comment><USER8> Here's more on dashes and hyphens: [http://practicaltypography.com/hyphens- and-dashes.html](http://practicaltypography.com/hyphens-and-dashes.html)

</comment><comment><USER9> Using the hyphen in "friendly-looking" is incorrect. The exception for hyphens in compound adjectives is when the first adjective ends in "ly." It should be "friendly looking couch."

[http://www.grammar.com/compound-adjectives/](http://www.grammar.com/compound- adjectives/)

<comment><USER10> "Friendly-looking" is correct (if a bit archaic), as "friendly" is an adjective, not an adverb.

Most "-ly" descriptors are adverbs, and it is indeed incorrect to compound "-ly" adverb-adjective combinations with a hyphen. (For example, "finely- chopped garlic" is incorrect). But _adjectives_ that end in "-ly" can be hyphenated. ("Friendly," "elderly," "dastardly," "squirrelly," "burly," "lovely," "ghastly," "deadly," and so on).

These days writers often choose not to hyphenate them, as compound-hyphenation in general is dying out in contemporary usage. It often feels old-fashioned and fussy in informal writing. But there is no rule prohibiting the compound- hyphenation of adjectives with "-ly" endings.

<comment><USER9> Thanks for the corrections! :)

<comment><USER10> No worries. I dig the username, btw. :)

</comment></comment></comment></comment><comment><USER11> Is it common to use "she" for punctuation marks? Or is it a perversion of the current trend in mixing he and she randomly?

Oh, and is "looking" really an adjective? It must be: this author is lecturing us about English usage, I can't believe she wouldn't tell adjectives and verbs apart.

<comment><USER12> > Oh, and is "looking" really an adjective?

Among other things.

"looking" is a actually a present participle; this form functions as a part of a compound verb used in forming continuous tenses, as a noun, and as an adjective.

[http://en.wiktionary.org/wiki/present_participle](http://en.wiktionary.org/wiki/present_participle)

<comment><USER11> Ok, then looking is not an adjective, it forms an adjective compound with another adjective.

<comment><USER13> Correct, a member of the same small POS group as 'smelling', 'feeling', 'sounding', 'tasting', and 'seeming'.

</comment></comment></comment></comment><comment><USER14> The problem for me is remembering how to create the various dashes on a typical keyboard.

<comment><USER15> I type _Ctrl+Shift+U 2014 Space_ (U+2014 EM DASH) surprisingly regularly. (That's with Ubuntu.) U+2013 is EN DASH and U+2010 is HYPHEN.

Does anyone else find that they know dozens of Unicode code points purely by accident? Other useful ones in that block are U+2018, U+2019, U+201C and U+201D, the left and right (first and third) single and double quotation marks...

In the end, though, I _really_ wish everything supported Vim's digraphs. (e.g. Ctrl+K l * produces λ.) I know even more of those than I know numeric codepoints…

<comment><USER16> I find using the compose key easier than remembering Unicode points. For em dash: `Compose - - -`, for en dash: `Compose - - .`.

</comment></comment></comment><comment><USER17> While I think that proper em dash usage—like this—looks fantastic, I'd be happy enough if somebody just ran s/ \- /\--/g on the internet.

<comment><USER12> Note that different style manuals will suggest em-dashes set closed for that use or en-dashes set open; either is better than hyphens (open or closed).

</comment></comment><comment><USER18> Oh bother. Use `-` for hyphen and `--` for dash. That's it and that's all you need. If a style transformer wants to convert `--` to – or —, fine whatever. But f* the difference between the two.

Please, stop making things more more complicated than they need to be! It is so f*ing tiresome.

</comment><comment><USER19> My character set has 7 bits -- and that's the way I like it.

</comment><comment><USER20> What was that green bar flashing across the top of the screen while I was trying to read the article?

</comment><comment><USER21> And what symbol is used for the "minus" operator?

<comment><USER22> Ah, for minus you should probably use − (U+2212), which will typically display at the same width as numerical figures.

Next question: should you use the same character for unary minus and binary minus? That is, to represent negative numbers and subtraction? ;)

</comment></comment><comment><USER23> This leaves out hyphens at line breaks for long words.</comment>


To Wash It All Away [pdf] - <AUTHOR> https://www.usenix.org/system/files/1403_02-08_mickens.pdf

<comment><USER2> This was really a rant piece, written as the author was leaving his post.</comment>


The Collected Papers of Albert Einstein - <AUTHOR> http://einsteinpapers.press.princeton.edu/

<comment><USER2> Cool concept. Be warned that the early papers are not in English, nor is there a translation available.

I expect this will change with time, but this is powerful collection nonetheless.

I also warn the reader that there is no tutorial. The papers assume you are already motivated to read by learning the meaning of terms independently of these papers.</comment>


Worm Spreading Malware via Facebook Using SVG, JavaScript and Google Chrome - <AUTHOR> http://react-etc.net/entry/worm-spreading-malware-via-facebook-using-svg-javascript-and-chrome-extension <comment><USER2> "Initially only Windows users are being attacked, but infected macOS and Linux computers can be attacked and abused in the future:"

illogical Captain :)

"In the past web browsers in have been very secure by default .. the likelyhood of exploits targeting JavaScript and browsers is bound to grow."

Google on ActiveX exploits ..

</comment><comment><USER3> Article pretty light on meaningful details, anyone have anymore information about how this works?</comment>


SF Approves Twitter Tax Break Deal - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2011/04/05/BA7R1IQM9D.DTL&type=printable

<comment><USER2> IMHO, this entire 1.5% payroll tax should go. And while we're at it, lets bring the property tax below 1%. And sales tax should go back to the 8% that it used to be.

Yesterday I got an email from SEIU (the government employees union), asking me to write in opposing this deal. It turns out there are over 14,000 city employees in the City + County of SF. For a population of under 800,000 . Wow. And in last years election, they were pushing hard for a ballot initiative that would have slapped an additional tax on hotel rooms.

There is just too much bureaucracy in this city. As revenues have gone up, the bureaucracy has ballooned. The City's annual budget is $6 Billion; and yet they can't find the $300K to support the SF Botanical Garden? In the meantime, personnel costs keep skyrocketing. Politicians keep hiring their cronies. For example: a local politician served before there was a law providing for healthcare benefits upon retirement for politicians. So he was hired for a month on the City payroll; his previous service counted, and voila! Now he has subsidized healthcare for the rest of his life. Lucrative Parking Garage management contracts are awarded at below market rates to cronies, who make a tidy profit.

Abuse is rampant all across San Francisco. The only way to stop is to stop the flow of funds that enables such abuse.

[edit: I had written 34,000 earlier; corrected it to 14,000 _City_ employees]

<comment><USER3> Try living in Upstate NY. My school taxes were $2,500 in 2007. With no change in property assessment, they are up to $3,400 this year. And we just found out that the local library wants to jack their portion of the tax by over 25%.

This place was a boomtown in the 1960's. Today, the booming business is in demolishing abandoned buildings.

<comment><USER2> In San Francisco, a 2-BR condo goes for around $800K. At a 1.16% property tax rate, you'll be paying $9000/year in property taxes. How's that for a tax rate?

<comment><USER3> In my city, a 3 BR home assessed at $175k goes gets hit for $3100 school and $2100 city/county taxes. A little less than 3x more.

That said I'm not claiming that San Francisco is a cheap place to live, but I'm assuming, that like NYC, living there comes with other opportunities that may balance the costs somewhat.

</comment></comment></comment></comment><comment><USER4> Actually, San Francisco got it right.

Instead of giving Twitter a tax break, they're giving anyone who moves into mid-market or the Tenderloin a tax break. Mid-market has been a blight for decades and plans to revitalize the area have never panned out. The Tenderloin (especially lower Tenderloin), isn't any better.

I think this is a great alternative to the city dumping money into the area. It'll create a powerful incentive to move there regardless of the blight and the effect of a few thousand engineers moving into that area will be dramatic.

I just wish it was for more than 6 years since I think it'll take longer than that to revitalize the neighborhood.

</comment><comment><USER5> Bureaucrats and politicians who make ad-hoc decisions like this do a lot of indirect damage to companies. What they have effectively done is raised uncertainty for businesses in SF. Will we get a break? Will our competition? Etc, etc. Uncertainty adds to risk and risk adds to costs.

</comment><comment><USER6> Apologies in advance for sounding so pessimistic, but this is just another example of _beggar-thy-neighbor_ tax/tax-break policies that limit government revenue potential.

</comment><comment><USER7> This is outrageous and, in my opinion, is unconstitutional. Americans and American businesses are entitled to equal protection under the law, and handing out customized tax breaks to a couple neighborhoods in order to benefit a specific company is shameful and corrupt.

<comment><USER8> First off, the payroll tax applies only to companies with payrolls > $250k; does your demand for 'equal protection' mean that you insist on companies of all sizes paying this tax?

Second, the tax break is not Twitter-specific (although even if it were, that would not be unconstitutional). It applies to businesses located in a certain part of SF, and it exempts a company from the first six years of payroll taxes.

Third, city supervisors have the authority to adjust tax structures with a level of geographic-granularity. Why shouldn't they be allowed to make a dumpy part of town more attractive to businesses?

Do you complain when cities and states make themselves more attractive to outside businesses by giving exemptions to certain classes of companies? Do you complain when cities block big-box stores like Walmart from opening in their limits? (Since those are as targeted as this exemption.)

<comment><USER9> _Do you complain when cities and states make themselves more attractive to outside businesses by giving exemptions to certain classes of companies? Do you complain when cities block big-box stores like Walmart from opening in their limits? (Since those are as targeted as this exemption.)_

Personally, yes, I complain about both of these.

As for this specific deal... I'm not too concerned about it, but I think it's the kind of special deal that cities shouldn't be allowed to make. There's just too much potential for corruption when city hall can say "OK, businesses inside this particular neighbourhood don't have to pay taxes". (Gee, Mr Mayor, I've been so good to you with campaign donations over the years, how about you declare _my_ block to be dumpy too?)</comment></comment></comment>


Meet Crystal language in its birthday. It is compiled and has ruby like syntax - <AUTHOR> http://crystal-lang.org/2013/09/04/happy-birthday-crystal.html

<comment><USER2> This is really interesting. A hypothesis I have on Ruby is that people attribute dynamic typing to it being a productive language, but that Ruby is actually productive for other reasons, _in spite of_ being dynamically typed.

With Crystal, at least when it matures a bit more, this hypothesis could be tested.

There are very logical reasons why dynamic typing at first appears better than static for Rubyists, that I think don't hold up as well after you scratch the surface:

* many Rubyists came from Java, and that kind of typing does slow you down. You need a modern type system with at least local type inference (Crystal seems to have global type inference)

* dynamic typing does actually help develop things more quickly in some cases, definitely in the case of small code bases for newer developers. A developer only has to think about runtime. With static typing a developer also must think about compile-time types, which takes time to master and integrate into their development. The relative payoff of preventing bugs grows exponentially as the complexity of the code base increases and at least linearly with size of the code base.

<comment><USER3> There is a Ruby with static typing---it's called C#. Seriously, even though my background is all in non-MS stacks, I did some C# work a few years ago and found the language surprisingly nice, and with a lot of the features I love from Ruby. It even has type inference like Crystal. (The _libraries_ are not nearly as clean/consistent as Java though.) For folks in the Ruby/Python/Java world, it's something to look at.

<comment><USER4> As someone whose last 8 years of professional work have been largely split between...C# and Ruby, I have to disagree. I _do_ agree about C# being quite nice; it's all the things Java should be but isn't. And it's evolving quickly in all the right ways.

But it isn't really like Ruby with static typing. The language isn't Rubyish (no mixins or blocks, for example). It makes you put everything in a class, a la Java. It can verbose and is occasionally downright clunky (though syntactically it's categorically slicker than Java). The .NET ecosystem doesn't have the Ruby characteristic of lots of small, fast-evolving libraries that are easy to use. In fact, the C# open source ecosystem is kinda poor in general and not a huge part of most developer's lives, whereas Ruby's ecosystem is vibrant and an integral part of its coding culture.

Another way to put all that is that if C# were purely dynamically typed, it wouldn't feel anything like Ruby.

I do see what you're saying: LINQ feels like a static (and lazy!) version of Ruby's Enumerable module, the lambdas look similar, C# actually does have optional dynamic typing, and C# is increasingly full of nice developer- friendly features. In general, I'm a fan. But switching between them doesn't feel like just a static/dynamic change.

<comment><USER5> Interesting - I found the lambda syntax of LINQ to be quite "Ruby like"

      someList.FindAll(i => i < 2)
        .Select(i => i * 2)
        .GroupBy(i => (i % 2) == 0 ? "even" : "odd")

Is about as close to Ruby's Enumerable as I've found in a mainstream/enterprise language (unless you include Scala).

<comment><USER4> Yeah, I mostly of agree with that and sort of said so in my post. Not sure it has much impact on my central point though.

One really key difference with LINQ is that it doesn't produce arrays (or dictionaries, as in your example); it produces Enumerators, which you then have to do call toList() or toDictionary() on. That laziness is actually an awesome feature and my favorite thing about LINQ, because it can massively improve performance by shortcutting work and not creating intermediate arrays. You can even work on infinite sequences with it. Besides performance, it's just tastier. It's so great I actually wrote a Ruby library to imitate it: [https://github.com/icambron/lazer](https://github.com/icambron/lazer)

<comment><USER6> Is LINQ really fast/performant though? Wouldn't the above expression cause three sequential loops to run?

One of the biggest performance issues I've seen with modern .NET code is people abusing LINQ and lambdas. Chaining functions like this is most decidedly not fast. I once wrote a library that had do do some heavy signal processing on large data sets, and since I wanted to ship the first version as soon as possible, I just used LINQ in a lot of functions to save time. It wasn't very performant so later I rewrote most of the functions to use standard native code such as loops for iteration, hashmaps for caching and all sorts of improvements like that. I completely got rid of LINQ in that version and for many functions the runtime went down from something like 500ms-1000ms to microsecond area.

So sure, LINQ makes development fast and it's very nice to be able to write code such as .Skip(10).Take(50).Where(x => ...). On most web projects, it won't make a huge difference. I've seen Rails "developers" use ActiveRecord in such a way that they would create double and triple nested loops and then hit the database multiple times by using enumerable functions on ActiveRecord objects without realizing how this works, what's going on behind the curtains and so on. I've seen .NET devs do similar things using EntityFramework.

So yeah, it's convenient and all, but it can also be very dangerous when used by someone who doesn't understand the fundamentals behind these principles.

<comment><USER4> > Wouldn't the above expression cause three sequential loops to run?

No, it wouldn't; that's the really important point about LINQ I was, clumsily, trying to express above [1]. Take this admittedly totally contrived example:

      someList
        .Where(i => i % 2 == 0)
        .Select(i => i + 7)
        .Take(5)

This is _not_ equivalent to a bunch of sequential loops. What it is is a bunch nested Enumerators. Here's how it works. It gets the list's Enumerator, which is an interface that has a MoveNext() method and a Current property. In this case, MoveNext() just retrieves the next element of the list. Then Where() call wraps that enumerator with another enumerator [2], but this time its implementation of MoveNext() calls the wrapped MovedNext() until it finds a number divisible by 2, and then sets its Current property to that. _That_ enumerator is wrapped with one whose MoveNext() calls underlying.MoveNext() and sets Current to underlying.Current + 7. Take just sets Current to null after 5 underlying MoveNext() calls.

So all that returns an enumerable, so as written above, it actually hasn't done any real work yet. It's just wrapped some stuff in some other stuff.

Once we walk the enumerable--either by putting a foreach around it or by calling ToList() on it--we start processing list elements. But they come through one at a time as these MoveNext() calls bring through the list items; think of them as working from the inside out, with each MoveNext() call asking for one item, however that layer of the onion has defined "one item". The item is _pulled_ up through the chain, only "leaving" the original list when it's needed. The entire list is traversed at most once, and in our example, possibly far less: the Take(5) stops calling MoveNext() after it's received 5 values, so we stop processing the list after that happens. If someList were the list of natural numbers, we'd only read the first 10 values from the list.

Now, those nested Enumerator calls aren't completely free, but they're not bad either, and you certainly shouldn't be seeing a one second vs microseconds difference. If you craft the chain correctly, it's functionally equivalent to having all of the right short circuitry in the manual for-loop version, and obviously it's way nicer.

So why are you seeing such poor perf on your LINQ chains? Hard to say without looking at them, but a few of pointers are: (1) Never call ToList() or ToDictionary() until the end of your chain. Or anything else that would prematurely "eat" the enumerable. (2) Order the chain so that filters that eliminate the most items go at the end of the chain, similar to how you'd put their equivalent if (...) continue; checks at the beginning of your loop body. (3) Just be cognizant of how LINQ chains actually work.

[1] In the example in the parent, FindAll isn't actually a LINQ method, so there is one extra loop in there. Always use Where() if you're chaining; use FindAll() when you want a simple List -> List transformation.

[2] A detail elided here: each level actually returns an Enumerable and the layer wrapping it does a GetEnumerator() call on that.

<comment><USER6> Thank you for this awesome explanation, it really clarifies how Enumerable methods work. I guess this is the real reason behind deferred execution. Still, I can't help thinking there is a big overhead involved with using such methods. We did some benchmarks in the past and the code that does the same thing manually always ended up being much faster.

The nice thing about Enumerable methods is that they can significantly speed up development and most projects won't suffer for it. However, for speed critical code it's probably not the best tool in the box.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I was very excited by this when I read the description, because a compiled language that looks like Ruby is exactly what I've wanted. Unfortunately I'm not super excited by the quirks of the implementation. For example:

        if some_condition
          a = 1
        else
          a = 1.5
        end

If I'm working in a compiled and typed language, the _last_ thing I want is a language that automatically gives union types to variables. As far as I'm concerned, the type inference should fail at this point. In the above example, now I'm forcing the compiler to maintain a union which is going to have a pretty significant overhead on every computation the variable `a` is involved in.

<comment><USER8> But isn't that how type inference works in most statically typed languages?

For example, in Scala: val x = if (some_condition) Employer else Employee

If Employer and Employee both derive from Person, then x will be of type Person. The run time uses dynamic dispatch to figure out how members are accessed from x.

If you want to constrain x, you need to specify the type explicitly.

<comment><USER9> Your example shows a different kind of behavior than the parent's example. A union type (t1 \/ t2) is a type that says "either this value has type t1, or it has type t2".

In your example, the type of x is not (Employer \/ Employee), it is their shared superclass - Person. The analogous example would be if

        val x = if (some_condition) Employer else Employee

succeeded _even though Employer and Employee did not share a superclass_. Very few languages use union types - Typed Racket comes to mind, and Algol apparently did too.

<comment><USER10> But actually in Crystal you will have the same behaviour:

      class Person
      end

      class Employer < Person
      end

      class Employee < Person
      end

      x = some_condition ? Employer.new : Employee.new
      # x is a Person+

This is not said in the "happy birthday" article (or anywhere else, IIRC).

In the beginning we typed x as Employer | Employee. But, as the hierarchy grew bigger compile times became huge. Then we decided to let x be the lowest superclass of all the types in the union (and mark it with a "+", meaning: it's this class, or any subclass). This made compile times much faster, and in most (if not all) cases this is what you want when you assign different types under the same hierarchy to a variable.

What this does mean, though, is that the following won't compile:

      # Yes, there are abstract classes in Crystal
      abstract class Animal
      end

      class Dog < Animal
        def talk
        end
      end

      class Cat < Animal
        def talk
        end
      end

      class Mouse < Animal
      end

      x = foo ? Dog.new : Cat.new
      x.talk # undefined method 'talk' for Mouse

That is, even though "x" is never assigned a Mouse, Crystal infers the type of "x" to be Animal+, so it really doesn't know which types are in and considers all cases.

Again, this is most of the time something good: if you introduce a new class in your hierarchy you probably want it to respond to some same methods as the other classes in the hierarchy.

<comment><USER7> Well, the happy birthday article has a section on "union types", and that code block has the comment "# Here a can be an Int32 or Float64". I just assumed that this meant a had the type Int32 | Float64. If the language doesn't actually have union types, then the article should probably be edited to reflect that (because it's very misleading on this issue).

<comment><USER10> It has union types. Right now if you do 1 || 1.5 it gives you Int32 | Float64. If you do Foo.new || Bar.new, and Foo and Bar are not related (except they both inherit from Reference), then you get Foo | Bar. If Foo and Bar are related by some superclass Super, then you get Super+.

If you do:

a = [1, 'a', 1.5, "hello"]

you get Array(Int32 | Char | Float64 | String)

In a way, the Super+ type is a union type of all the subtypes of Super, including itself, but just with a shorter name.

</comment></comment></comment></comment></comment></comment><comment><USER11> The one that caught my eye is that the macros are disappointing: they merely feel like (not even glorified) syntactic sugar for an _eval_ wrapped in a function.

Hint: if I'm manipulating/interpolating a string, it's an eval, not a (lisp-y) macro.

</comment><comment><USER12> I guess it's also worth mentioning Mirah, a JVM language heavily inspired by Ruby. Unlike JRuby, it compiles down to byte code ahead of time and needs not support libraries.

[http://www.mirah.org](http://www.mirah.org)

</comment><comment><USER13> I'm putting my faith in Ruby. It might take 10 years, but eventually the performance will resemble C's. It's basically a compile-to-C language right now as it is. There's just a whole bunch of inefficiencies in the implementation. Once they get ironed out, we'll finally be able to have our cake and eat it too. One language to rule them all.

<comment><USER14> No it won't. There are so many problems with trying to get a dynamic language like ruby to be in the same order of magnitude of performance as C.

Garbage collection, inlining virtual calls etc.

<comment><USER15> Go has garbage collection and it's in the same order of magnitude as C. In fact so are Scala and Java. So, we can at least stop blaming gc.

<comment><USER16> Yes, but neither language is nearly as dynamic as ruby. That's where the costs come in. Method calls in ruby are comparatively glacial in speed.

<comment><USER13> That's why the ten years.

<comment><USER17> after ten years, square wheels will suddenly be round?

<comment><USER18> If you've been rotating them against a surface in that time period; then they'll certainly be a lot more round than when they started.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> Dynamic typing is simply sugar. It's a bit misleading (particularly for newer developers) that you don't have to think about types just because you don't have to declare them. Automatic coercion, etc, is really only useful if you're a more experienced developer because for the most part, you keep the type information in your head.

That said, python is the most productive language I've used so far but type management is really just one part of that.

</comment><comment><USER20> You cannot have full classical OOP with C like performance. It won't happen without a big fat JIT runtime and more optimization than put into hotspot.

<comment><USER21> Yes, you can. You might have heard of C++.

<comment><USER22> Uhh, "classical OOP". Like Smalltalk. What C++ calls "OOP" has its place, but it's not the same thing.

</comment></comment></comment><comment><USER23> Interesting. I really liked the solution for writing C bindings.

Given the syntax looks similar, could it run Ruby source, unaltered?

<comment><USER24> Some of it, I guess. Sometimes it would break due to "type differences," I guess.

</comment></comment><comment><USER25> This is great. Now if we need parallelism we can choose Rubinius and if we require raw speed we can choose Crystal (when it's done) instead of jumping on the JRuby bandwagon.

I respect Charles Oliver Nutter but Java is something I want less of in my life. This seems like a great alternative for people seeking performant Ruby interpreters.

<comment><USER26> This isn't a Ruby interpreter

</comment></comment><comment><USER27> There is a typo: foo2.ord in the first class Foo(T) example should be foo2.value.ord.

<comment><USER10> Thanks, I just fixed the example.

</comment></comment><comment><USER24> It would be really cool if one could write binary extensions/gems for Ruby with Crystal somewhere down the line... far down the line, probably.

<comment><USER10> Yes, it's one of our dreams too. Right now you can do:

      # In a foo.cr file
      fun init_foo = Init_foo : Void
        puts "Init foo! :-)"
      end

Compiling it:

      bin/crystal foo.cr -o foo.bundle

Then in Ruby:

      $ irb
      irb(main):001:0> require "./foo"
      Init foo! :-)
      => true

But more complex things don't work right now (because of the initial implementation of the GC, which needs to be turned off for this case).

So, yes, we are not that far from allow you to write Ruby extensions in Crystal.

We'd also like to write Objective-C code that way, and also Erlang extensions.

</comment></comment><comment><USER28> One of Ruby's benefits is UTF-8 support for strings. C-strings make it seem it's absent. Or did I missunderatand?

<comment><USER10> The current String implementation is just a temporary one. UTF-8 will be there.

</comment></comment><comment><USER29> Looks very interesting. I am intrigued by the idea of Ruby having type hinting and optimizations based on hints.

</comment><comment><USER30> Can it use Ruby libraries? People use Ruby mostly because of its ecosystem.

<comment><USER13> It appears to have nothing to do with Ruby except syntax similarities.

</comment></comment><comment><USER31> Another language with un-googleable name.

<comment><USER32> Can't be worse than Why. (Go ahead, I dare you to find it!)

<comment><USER33> Wow. You have to quote "the why programming language" before you even get a trace. It's not even in wikipedia's alphabetized list.

</comment></comment></comment><comment><USER34> How is this different from Ruby?

<comment><USER35> It's compiled and type-checked.

<comment><USER36> Which also implies performance benefits over Ruby. I think another way to view it is Go with Ruby syntax (although Go has its own runtime overhead). Their introduction document [1] is a pretty concise overview.

I think it's an interesting project. But not being a Ruby focused coder these days, I can't see myself choosing this over other compiled languages at this point.

[1] [https://github.com/manastech/crystal/wiki/Introduction](https://github.com/manastech/crystal/wiki/Introduction)</comment></comment></comment>


Researchers: Medical errors now third leading cause of death in US - <AUTHOR> https://www.washingtonpost.com/news/to-your-health/wp/2016/05/03/researchers-medical-errors-now-third-leading-cause-of-death-in-united-states/ <comment><USER4> If you spend anytime with the medical industry you soon realize the issue.

I helped launched (the now deadpooled) Theil backed MetaMed a few years -- essentially a private research team for medicine, and what the founders taught me was astounding.

That things like amputating the wrong limbs, doctors not washing their hands and killing you by infection and a horror of other preventable errors are shocking common.

This didn't even take into consideration that things discovered in labs that might cure you take at least 30 years to reach the doctors who might implement them, if they ever do.

The distortion of hubris from doctors, economic incentives and other systemic issues results in a "health care system" that doesn't realily seem to do what it sets out to do -- we spend 10x what some developing countries do per year per person with no better outcomes.

Accute care seems to be reasonably good, fixing a broken arm, etc. (assuming they don't accidentally remove it); but chronic care is often just a pipeline for the recurring revenue model of big pharma (at best).

The examples are never ending but for fun, take a google to discover how many pap smears are performed annually on women _who have already had their uterus removed_ \- then consider the cost to insurance and tax payers.

<comment><USER5> I often think that the medical industry enjoys (or suffers) from some sort of a given god complex. They can do what they want as soon as they reach a certain threshold of saving. Nobody will debate them (most of us don't have the articulate knowledge anyway) and will morally and existentially satisfy from still being alive.

I just went through 4 doctors (gen. and specs.) about deep yet diffuse cardio vascular problems (life altering if not threatening). Their diagnosis was "nothing to see you are depressed". Since my problems started I can't sleep on my right side (causes heart race, pain and suffocation), and have now back pain; in order to sleep without pain I tried on my stomach. This configuration changed something, I felt stings around my heart, and a sudden relaxation, warm blood reaching my fingers and feets (something I didn't feel for a year). Stings moved along, hurting at finger and toe tips. I felt sweetly alive, jumped out of my bed (because now I can). Even cleand my browser tabs. So much for depression.

I tried discussing with doctors calmly. Accepting the data, their knowledge. Yet not backing down if I felt they weren't really solving my problems. But it's impossible. One doctor even dared me to reproduce transient symptoms with an annoyed tone. You start considering being hypercondriac, a crybaby.

Deep down all I want is a way to monitor myself deeply so I can take care of myself but I'm facing this paywall.

<comment><USER6> Don't give up! I was told the same thing you are depressed. Doc even wanted to push meds on me. Took months of seeing specialists but ended up getting a real diagnosis which required a major surgery. Now I'm finally better but you have to work within the system which means finding a good doctor.

<comment><USER7> What was the diagnosis, if you don't mind me asking?

</comment></comment></comment></comment><comment><USER8> These kinds of metrics are almost not interpretable, for two main reasons :

(1) as _logicallee_ has mentioned, we're getting better at treating patients and preventing death due to disease. The better we get, the more different treatments patients get, the higher is the risk of a medical error happening.

(2) it is very difficult to know exactly what proportion of "medical errors" are preventable. For instance, the seemingly "simple" case of healthcare- associated infection is far from simple, and except for a few cases (infection associated with elective surgery, and so on), there are _NO_ known intervention to reduce risk further. I will give you an example: a patient needs a central catheter in order to survive. If we don't put it in, and he dies, he'll be classified as a "death due to primary disease X". If we do put a central line, and he acquires an infection (and a certain baseline rate of infection IS inevitable, because the catheter is indwelling and gets colonized by the patient's own flora), and dies 2 months later due to sepsis, it will be codified as "medical error". Adverse drug reactions are also codified as medical errors, even if the drug was administered in a life-or-death situation, when even the patient's ID was not known, even less his full list of medications (and thus, the error could not be prevented in any way). I could go on and on.

That being said, I also see stupid preventable errors like quietly giving the drugs to the wrong patient going unreported. Hospital stay is certainly dangerous.

<comment><USER9> Actually research shows that many central line catheter infections _are_ preventable. The AHRQ and CDC have published best practices and checklists, yet many hospitals still don't adhere to those.

[http://www.cdc.gov/hai/bsi/bsi.html](http://www.cdc.gov/hai/bsi/bsi.html)

[http://www.ahrq.gov/professionals/education/curriculum- tools...](http://www.ahrq.gov/professionals/education/curriculum- tools/clabsitools/index.html)

<comment><USER8> > many central line catheter infections are preventable

Again, of course some of them are preventable, and nobody's saying its OK to install central lines without putting gloves on, and so on. However, there is a baseline rate of infection which is not preventable, and will continue to happen. Check the Figures S1 and S3 in this recent study : [http://www.nejm.org/doi/suppl/10.1056/NEJMoa1500964/suppl_fi...](http://www.nejm.org/doi/suppl/10.1056/NEJMoa1500964/suppl_file/nejmoa1500964_appendix.pdf)

> many hospitals still don't adhere to those.

What is the source ? As far as I'm aware, around ~ 90% facilities do have checklists -- I do not follow this literature closely, though.

</comment></comment></comment><comment><USER10> These studies do not prove that medical errors _caused_ these deaths. It proves that people who died had some sort of medical error in the weeks leading up to their death.

As it turns out, people who are going to die soon get a fair number of medical 'interventions', which means there are many opportunities for errors to occur. This inflates the error rate for these patients. But if we're talking about patients who are going to die very shortly anyway, did a nurse accidentally giving them a double dose of their evening antacid really hasten their death? Probably not...

This is not to say that there aren't preventable deaths due to medical errors. There absolutely are. But studies like this seriously inflate the numbers...

I'd recommend the Healthcare Triage video on subject: [https://www.youtube.com/watch?v=1JkFN_2mzR4](https://www.youtube.com/watch?v=1JkFN_2mzR4)

</comment><comment><USER11> Just want to mention a book I recently read about a doctor's quest to eradicate medical errors through the use of something as simple as checklists.

The Checklist Manifesto, by Atul Gawande.

It's a quick read and very enjoyable. I'm not a medical professional, but Gawande makes the value of checklists clear for people in any profession.

</comment><comment><USER12> Isn't this simply because the US tries to run everything as a company or takes economics and legal above everything else? You can't do anything unless you make a profit or are completely legally covered (or can completely sue something/something out of existence). It's that the US runs on, and as soon as you get near something that doesn't work that way (i.e. infrastructure - <USER2> road needs to be good, it doesn't need to be cheap or legally covered) or that can't work that way (humans and health don't bend to the rules of law or economics) you're going to have a really bad time.

<comment><USER13> This. Recent exposure to the US healthcare/medical system has horrified me. The fact that it's majority for-profit enterprises and isn't equal-access leads me to conclude the US shouldn't be able to call itself a developed nation.

</comment></comment><comment><USER14> From the article: _He said that in the aviation community every pilot in the world learns from investigations and that the results are disseminated widely._

 _"When a plane crashes, we don't say this is confidential proprietary information the airline company owns. We consider this part of public safety. Hospitals should be held to the same standards," Makary said._

Seems like this number would be higher if they also included HAI's (healthcare associated infections, about 75K additional deaths): [https://www.cdc.gov/hai/surveillance/](https://www.cdc.gov/hai/surveillance/)

And it's right, the rates of what are essentially malpractice haven't changed. Arguably despite spending more, we get worse care: [http://www.npr.org/sections/health- shots/2013/09/20/22450765...](http://www.npr.org/sections/health- shots/2013/09/20/224507654/how-many-die-from-medical-mistakes-in-u-s- hospitals)

If infections are included in the numbers then the US is only slightly above average: [http://www.euro.who.int/en/health-topics/Health- systems/pati...](http://www.euro.who.int/en/health-topics/Health- systems/patient-safety/data-and-statistics)

The WHO suggests by reducing HAI, the EU could reduce deaths by about 95K/year vs. US's 75K (actually normalizing by population makes the US's number look really bad..assuming stats apply to entire EU's pop of 508-ish million and the US's ~308 million).

I can't find in the cited study (original article) if they included hospital acquired infections like the WHO does. If they didn't then we've a lot of work to do. Likely will never be an issue though, unless we treat the med profession like any other professional service provider with the power of life and death. We need to open the books on investigations, share data publicly, and likely provide more oversight. Also...seems like a wonderful area where big data and ML could contribute to meaningful improvements...

</comment><comment><USER15> A few questions:

1\. Is there a metric similar to deaths per passenger mile in automobiles? That is, is it possible that more people go and stay at the hospital, more new kinds of diseases (which were considered incurable previously) are now being treated, even if people know it is some what futile? How much of the jump would it explain? How about the increase in the population itself?

2\. From the word "now", we could infer a couple of things. It is possible that medical error itself has risen drastically (or not, depending on whether we have a good answer for 1), or just that treatment for whatever used to be number 3 previously - respiratory disease - has improved in recent times? It is entirely possible that medical error could climb further up and top this chart and still allow the possibility that medical care is actually improving.

3\. From the article:

\</comment><comment>---

Although all providers extol patient safety and highlight the various safety committees and protocols they have in place, few provide the public with specifics on actual cases of harm due to mistakes. Moreover, the Centers for Disease Control and Prevention doesn't require reporting of errors in the data it collects about deaths through billing codes, making it hard to see what's going on at the national level.

"The CDC should update its vital statistics reporting requirements so that physicians must report whether there was any error that led to a preventable death, Makary said.

"We all know how common it is," he said. "We also know how infrequently it's openly discussed."

\</comment><comment>---

There was a similar discussion a while back, about the topic of the coding of the cause of disease not being consistent and that it could be misreported. Before that situation is improved, shouldn't we be considering these kinds of articles from a more skeptical viewpoint?

</comment><comment><USER16> I suspect this statistic is inflated by "failed to extend this person's life by another three weeks" type errors. A genuine medical error is one which creates a problem completely unrelated to the treatment or original health issue.

<comment><USER17> I wouldn't be surprised at all. Far more than most people realize, a lot of medicine today is focused on keeping people who likely have no hope of recovery alive for just another week.

</comment></comment><comment><USER18> Here is the link to the original article - [http://www.bmj.com/content/353/bmj.i2139](http://www.bmj.com/content/353/bmj.i2139)

<comment><USER19> Thank you. I find it bizarre that these days articles include text such as "Their analysis, published in the BMJ on Tuesday" without providing a link, even though the article is sadly paywalled.

</comment></comment><comment><USER20> I know that each of these deaths is a tragedy, but if we turn back the clock to an era of polio, TB, cholera and malnutrition it is amazing to find _doctors preventable mistakes_ in the top three.

Yes it needs fixing, but it also needs a quiet fist pump in the same way more people die from obesity related diseases than starve to death.

It's the very definition of a first world problem.

</comment><comment><USER21> _Their analysis, published in the BMJ on Tuesday, shows that "medical errors" in hospitals and other health-care facilities are incredibly common and may now be the third-leading cause of death in the United States — claiming 251,000 lives every year, more than respiratory disease, accidents, stroke and Alzheimer's._

Title of article omits the "may". I hope someone is able to review their report and data.

<comment><AUTHOR> Frustratingly I put in the "may", because the current title is both link baity and inaccurate.

Mods edited it. :-/

</comment></comment><comment><USER22> Just an anecdote but on a subreddit I sometimes browse there's two MDs who boast of sleeping only 3 hours per day.

And then on the financial incentives side of things, at this point practice insurance might be so robust that it might not be so risky any more to end up committing a medical error while working those extra 3 to 4 hours per day might mean you're making enough money to retire in your early 40s.

<comment><USER23> > working those extra 3 to 4 hours per day might mean you're making enough > money to retire in your early 40s.

The only way you could retire in your 40s as a doctor these days is if you were already independently wealthy before becoming a doctor.

If you go into medical school today, you're looking at finishing off your student loan payments in your 40s (depending of course on which school you go to, where you do your residency, whether you do a fellowship, and what specialty you choose).

The pre-tax, pre-insurance, pre-expenses, _gross_ pay looks high on paper, but the lifetime ROI on going into medicine is nowhere near as good as what you describe, no matter how many hours you work.

<comment><USER24> That is a gross generalization. It is true in the US if you are a primary care physician or one of the lower-paid/lifestyle specialists. It is far from true if your are a higher-paid specialist or sub-specialist.

Also consider that unlike tech, where you get paid more for working in higher- cost-of-living cities -- in medicine you get paid more for working in lower- cost-of-living cities.

Also note that unlike tech, the peaks and valleys are much less pronounced.

<comment><USER23> > Also note that unlike tech, the peaks and valleys are much less pronounced.

The point is that, unlike tech, you have to take on _massive_ amounts of debt before you can even begin to work[0]. And even after that, there's a really high latency before you're earning enough to make more than the minimum payments. Six-figure debt compounded over a decade or more really adds up.

> That is a gross generalization. It is true in the US if you are a primary > care physician or one of the lower-paid/lifestyle specialists. It is far > from true if your are a higher-paid specialist or sub-specialist.

It's actually more true if you're a specialist or subspecialist. People who don't practice medicine tend to overestimate what specialists get paid, and to underestimate what PCPs get paid. It also doesn't help that, in the last ten years, the relative reimbursement rates have changed dramatically, and to top it all off, private practices have been rapidly going the way of the dodo - <USER3> it's understandable that the public perception would be out-of-date.

Overall, reimbursement rates for specialists have been slashed far faster than they have for primary care (with some specialties hit harder than others). Combine that with the fact that they have to spend even more time in training (during which time their debt compounds

> Also note that unlike tech, the peaks and valleys are much less pronounced.

Quite the opposite - tech salaries are relatively flat and stable compared to most other industries, and we get to take home pretty much 100% of our salary, less taxes. Yes, the industry as a whole has booms and busts, but so does literally every private industry. In medicine, unlike tech, even if you're salaried, you're oftentimes paying for a large chunk of your business expenses out of your "salary". This is one of the reasons why looking at listings of what doctors make is incredibly misleading. The insurance rates vary dramatically between fields of medicine (and practice locations), as does the necessary equipment and mandatory continuing medical education expenses (again, even salaried doctors will oftentimes have to cover these out-of- pocket).

In tech, we don't have to worry about any of that. We have it pretty easy.

> in medicine you get paid more for working in lower-cost-of-living cities.

This used to be the case. It still is, for some fields like emergency medicine. It's a lot less the case in other fields, partly because of the consolidation of practice groups and the downward pressure on reimbursement rates across the board.

[0] Unless, as I said in my previous comment, you're independently wealthy beforehand, in which case this whole discussion of early retirement is moot.

<comment><USER24> With respect - you are comparing apples vs oranges. You are comparing independent/priv-practice doctors vs salaried technologists. If you had an independent contractor technologist, they also have to eat all the overhead (Liability insurance, E&O insurance, benefits, office, supplies.) Similarly, if you have a doctor working at the hospital, just like a salaried technologist they don't have to pay the overhead.

To be fair, doctors' overhead is higher for certain practices, but remember that facility fees can be billed back to the insurance or directly to the patient and even sent for collection. Those are extra fees on top of the doctor's pay -- essentially a form of rent forwarded to the patient for the doctor's facility costs.

Finally, we're not comparing tech salaries to other industries, we're comparing them to doctors. I've rarely seen doctors face a 2001 market crash or 2008 market crash and mass unemployment or had their entire training wiped out when JE22 went south. Tech is very volatile. Also consider that doctors generally make more as they age, whereas technologists often face increasing age discrimination. Yes, MLK in LA and St Vincent's in NYC did shut down, but have you ever seen the equivalent of a Lucent or Lehman or IBM or Intel in medicine? Rare...

You are right that I don't practice medicine, but I work 75hrs a week in hospitals since my startup sells to hospitals. I've seen the relative function and dysfunction of both American and single-payer overseas systems. And BTW, i pay _gigantic liability insurance bills for my diagnostic technology product_ , and it effectively comes out of my salary.

</comment></comment></comment></comment></comment><comment><USER25> 5 years ago my uncle was hospitalized with a knot in the gastrointestinal tract which usually gets treated within days. He never left the hospital and died 3 weeks later after every single organ in his body started failing post- treatment. The man has always been healthy and never had any serious illnesses. His daughter witnessed (and on a few occasions so did i) plain stupidity and negligence of the medical staff who insisted to take him off life-support after putting him on it. We eventually ended up moving him to another hospital where he showed signs of improvement but eventually died when his kidney and then lungs gave out. She and her mother are convinced that he died because of numerous medical errors. I watched him suffer for 3 weeks and have since developed a phobia of hospitals. I basically lose my shit over any hospital visits these days.

<comment><USER26> There's an old joke inside hospitals. Hospitals are where people go to die. Unfortunately, it's not a joke. Hospitals are the definition of asymmetric information warfare. You know nothing and they _think_ they know everything. Absolutely have someone on your side who knows what's what. Family/friend who is a doctor, nurse, PA, NP, etc. Hospitals are so wedged that some actually have "patient advocates" who work there and whos sole job is to be that advocate for the patient and patients family.

</comment></comment><comment><USER27> This isn't a new phenomenon, there's even an ancient word for it: [https://en.wikipedia.org/wiki/Iatrogenesis](https://en.wikipedia.org/wiki/Iatrogenesis)

Doctors are pre-disposed to do something rather than nothing, and doing something is more dangerous than doing nothing in the vast majority of medical cases. This is especially true when "doing something" has unknown or unbounded side effects and the original ailment is something that the body will take care of by itself in short order.

Every prescription you take for a minor inconvenience is a tiny chance that you're taking the next recalled drug for something that does long-term damage that wasn't found in short-term medical trials, or the chance that your pharmacist makes an error in filling the prescription.

<comment><USER28> Maybe. I wonder if these 'medical errors' also counted situations where the patient was probably going to die anyways.

<comment><USER27> What is this "maybe" in response to?

Going to the doctor or taking a medication, even if the _chance_ of risk is low, has a downside that is a lot worse than the upside, except in cases that are life-threatening or have potential long-term health downsides.

So next time you're thinking of taking something to fix your acid-reflux, maybe try listening to your body and changing your diet, instead of risking that the drug you take to mask the symptoms is the next Nexium.

<comment><USER29> Everything has risks. Maybe you change your diet and end up doing an unfamiliar food preparation and you screw it up and end up with a case of salmonella or e. coli. Or you do your usual thing and it happens anyway.

It's inane to suggest anything labeled "medication" should only be taken in life-threatening circumstances. Everything you ingest is going to have an impact on your body - some good, some bad, many both. Medications have a particularly strong impact, but are also highly controlled. You can judge the probability of various outcomes very well, which makes it a lot easier to come to a clear conclusion about using them or not.

And I'm going to assume you didn't intend to say that merely going to the doctor should be avoided except in life-threatening circumstances.

<comment><USER27> Of course everything has risks, but I'm just advocating not taking risks with extreme downside when the positive upside is small. Eating is necessary for life, but taking a pill to reduce the risk of acid-reflux symptoms is not.

> _Medications have a particularly strong impact, but are also highly > controlled. You can judge the probability of various outcomes very well, > which makes it a lot easier to come to a clear conclusion about using them > or not._

This is the main point where we disagree. You say medications are controlled, but I see alarming numbers of recalls of drugs [1]. Controlled studies only show a small part of the picture of the long-term impact of a particular drugs' use.

> And I'm going to assume you didn't intend to say that merely going to the > doctor should be avoided except in life-threatening circumstances.

All I'm saying is that going to the doctor has risks that need to be considered. And when a doctor recommends some treatment, ask what he would do if he was in your situation, or what recommendation she would give to her brother.

1\. [http://www.raps.org/Regulatory- Focus/News/2014/08/11/20005/N...](http://www.raps.org/Regulatory- Focus/News/2014/08/11/20005/Number-of-Drug-Recalls-Surges-at-FDA-Led-by-Mid- Level-Concerns/)

<comment><USER29> It's not just a question about the magnitude of the possible upside or downside though, it's also about how likely they are to occur. If you offer me the opportunity to almost certainly make every day slightly better with the risk of killing me at a rate of once in the current age of the universe I'm going to take it. It's a tiny upside with a massive downside, but it would be irrational not to take it given the chances involved.

Medications absolutely are controlled. That doesn't mean they don't have issues, but are you willing to suggest medications are less controlled than food? I don't need to hope I've washed my medications well enough, nor do I need to ensure I've heated them to at least a certain temperature for a length of time, nor do I need to worry about cross contamination or any such thing. This isn't to say medications are without risk, but compared to produce, meat, or eggs I have a much better idea about what exactly is entering my body when I consume it.

>All I'm saying is that going to the doctor has risks that need to be considered.

I doubt that very much. Are the risks significantly greater than the risk you likely took getting to the doctor in the first place? I'd be shocked.

</comment></comment></comment></comment></comment></comment><comment><USER30> This is a good thing.

If all causes of death were medically preventable (which would be _awesome_ ), by definition preventable medical errors would cause 100% of deaths. (Since they could have prevented it and assuming it's an error not to.)

It's simple logic. In other words, the better the standard of medical care, and the better the state of medical science, the higher this number will be, right up to 100% if medical science has an answer to everything. It will never be 100% of zero, as obviously in practice not everything will be done perfextly - but medical error is the delta between theoretical standard of care and actual outcome. The better the theoretical standard, the more deaths must be deemed errors.

It can still be far better than if that were not the standard.

<comment><USER31> _This is a good thing._

Just looking at the cause of death percentages misses the point. Imagine your dream scenario has been achieved and all deaths are caused by errors. 2 hospitals that treat the same number of patients (with similar complexity across the patient populations) are performing similarly on the death metric, 100% of deaths are caused by errors. Never mind that Hospital B kills 100 times as many people.

Putting it another way, without some information about what good performance is, you'd better not make any conclusions about whether this is a good thing or not.

</comment></comment><comment><USER9> For those interested in this topic I strongly recommend reading the Institute of Medicine report "To Err Is Human" linked in the article. [https://www.nap.edu/catalog/9728/to-err-is-human- building-a-...](https://www.nap.edu/catalog/9728/to-err-is-human-building-a- safer-health-system) It set the foundation upon which a lot of this later research is based.

</comment><comment><USER32> Medical error is third biggest cause of death in the US, experts say: [https://www.theguardian.com/society/2016/may/03/cause-of- dea...](https://www.theguardian.com/society/2016/may/03/cause-of-death-united- states-medical-error)

</comment><comment><USER33> Nobody has comment on the ridiculous amount of hours doctors have to work on emergency rooms. 7 hours with 3 hours of sleep between going to class and being into the ER again. This is actually illegal but every student I talk to is afraid of complaining and risk their careers.

</comment><comment><USER34> As a most awesome MD, really at the front lines told me once after a 36 hour shift:

1\. 50% of the patients are in this hospital are here because of medical errors.

2\. Don't get sick.

But if you do get crushed by a car, you really are going to be damn happy I'm here.

</comment><comment><USER35> My foster son died in 90's after taking a powerful steroid where the dosage was multiplied by 10 by a transcription error. I never found out if the doctor or pharmacist was the one responsible.

<comment><USER36> That is absolutely disgusting and tragic. I am so sorry for your loss.

</comment></comment><comment><USER37> Hm. Article strongly states we need to measure this invisible killer. Also ranks this (unmeasured) risk high on a chart by number of deaths per annum. Seems like guessing to me?

I'm thinking 'medical error' is a catchall for some constellation of events, and only shows up high on the chart because its an aggregate of several causes. Once its measured and dissected, it will turn into 12 low-frequency entries and disappear from the conversation.

<comment><USER38> Medical error is actually underestimated. You get preventable deaths that are attributed to "complications of an underlying cause".. You might consider MRSA infections as a preventable medical error but frequently sepsis is not listed as a cause of death.

<comment><USER37> My point exactly. Split it into a dozen causes, they all fall down the list to 10th or 12th place.

</comment></comment></comment><comment><USER39> I find that hard to believe, 250K is a huge number. CDC's list:

• Heart disease: 614,348

• Cancer: 591,699

• Chronic lower respiratory diseases: 147,101

• Accidents (unintentional injuries): 136,053

• Stroke (cerebrovascular diseases): 133,103

• Alzheimer's disease: 93,541

• Diabetes: 76,488

• Influenza and pneumonia: 55,227

• Nephritis, nephrotic syndrome, and nephrosis: 48,146

• Intentional self-harm (suicide): 42,773

[http://www.cdc.gov/nchs/fastats/leading-causes-of- death.htm](http://www.cdc.gov/nchs/fastats/leading-causes-of-death.htm)

</comment><comment><USER40> Would love to compare this stat to other nations. G8 at the very least.

</comment><comment><USER41> What would be a _good_ 3rd leading cause of death?

<comment><USER42> Being struck by lightning?

</comment></comment><comment><USER19> Any estimate in terms of DALYs?

</comment><comment><USER43> Among other things I have worked as a researcher, a Psychiatrist, a Neurosurgeon, and a web developper. Reading comments about how much distrust there is in doctors saddens me. Medical errors are killing people but it has to be put in perspective to the reality of modern medicine in hospitals. Usually medical errors kill patients that are the most vulnerable, who need several invasive acts, strong and potentially harmful treatments, who need to stay in bed, in the hospital, for days or even months. The first comment by ada1981 talks about how acute medicine seems to be doing ok, that is not because acute doctors are good, and chronic doctor are asshole sold to big pharma. It is because longer stay in the hospital means a more severe condition, and an incremental risk of yes, preventable errors. Actually, this feeling of mistrust is one of the main reason I stopped practicing, the other reason was that I was frustrated by the way doctors have to practice medicine and is of course related to this issue. The way we practice medicine has not changed for years, although medical knowledge increase exponentially and doubles every two years. This immobility is mainly due to three things: the highly hierarchical and rigid structure of the medical field that resist adaptability and innovation, economic constraints imposed by big pharma and insurances who basically decide of how medicine is practiced in the whole world, as well as misguided political/societal views as to what should be a doctor of the 21st century, what tools should he use and how should he study.

In the article, the author - who by the way seems pretty biased and judging from previous work to hold a profound grudge against physicians, is comparing doctors to pilots, and medical errors to crashes. And besides the simple demagogic argument of doctors are dumb and proud and pilot are better formed and humble, the reality is that pilot are using machines worth millions that are able to diagnose, fix, and steer themselves. They are three in the cockpit, and communicate with flight controllers for the most critical parts of the flight. They have real time weather prediction and course change. Their tools are evolving in time, does she even know that modern airplanes produce more than a terabyte of data on every flight ? This data is used to make airplane safer every year, update software, hardware, security...

Practice of medicine has to change yes, and article pointing at medical errors will help change minds and practices in the coming years. Technology will play a big role in it.

But the author, and some people commenting here should remember that pilots are not battling death. People who die in hospitals from medical errors are usually the one who are suffering from chronic and hard to treat diseases. You all want to live forever, blaming doctors of the sad reality that most of you will die from a chronic disease.

Instead of drawing a dark portrait of physicians who for the most part work selflessly to make a positive change in the world, you should ask yourself: why is there medical errors, what can they do better ? What could they do in this context ? Go to school 18 years instead of 12? Work 120 hours instead of 90 ?

The solution is a deep change of how medicine is practiced, a revolution driven by technology (IOT, big data, AI) and the open science movement. But you have to realize that this revolution was not possible before maybe 4-5 years ago. Now it is, and soon it will change.

</comment><comment><USER44> So why are doctors paid so much, it obviously has not improved service any?

<comment><AUTHOR> You used to die at 50 from cancer or heart disease. Now you die at 80 from cancer or heart disease or medical error.

I think that's an improvement.

<comment><USER45> Indeed, one of the things that needs to be kept topmost in mind when reading statistics like this is that people are going to die of _something_ , and as we reduce or all but eliminate other causes, _something_ or things are going to shift to being the new "top causes".

ADDED: and because nowadays, no later than the end of WWII, the former somethings have be forestalled by medical interventions, as those increase, the number "killed" by the simple fact that healthcare workers are fallible humans is going to rise.

My father survived the immediate post-WWII period when he got a nasty bacterial pneumonia I think it was because civilians were then able to get the earliest form(s) of penicillin. Thanks to that medical intervention, which could have killed him (I've read that penicillin would never get approved by the FDA today because of its allergy potential), and others, now he'll die of Alzheimer's in his mid-'80s or his '90s, if nothing else gets him first.

</comment></comment></comment><comment><USER46> I guess of all problems, this is one of the better ones to have.</comment>


Analysis: more than 16 cores may well be pointless - <AUTHOR> http://arstechnica.com/news.ars/post/20081207-analysis-more-than-16-cores-may-well-be-pointless.html <comment><USER2> The UltraSparc T2 has 8 cores and each core can run 8 concurrent threads, so you have 64 concurrent threads running "simultaneously" on a single chip: <http://en.wikipedia.org/wiki/UltraSPARC_T2> One of the techniques they use to solve the memory bandwidth problem is to have four memory controllers.

<comment><USER3> Yeah, but the way it does it is by switching concurrent threads when the last gets stalled on memory.

It's brilliant, and seems effective, but it's still just 8 cores per socket.

<comment><USER4> This is useful to get around the latency issues, which let's you use more of your memory bandwidth before stalling a core.

</comment></comment></comment><comment><USER5> Why not do for memory controllers the same thing we are doing for cores? If 8 cores is the practical limit of a single memory controller, why not ship 16-core CPUs with 2 independent controllers, one for each set of eight cores?

True, the two groups of cores would probably not be able to share memory (at least not at full speed), but that's something the OS scheduler and memory manager could take care of.

For one, there are plenty of pins. The socket used by Core i7 more than doubled the amount of pins (in the 1300s now), yet a QuickPath Interconnect (Intel's replacement to the FSB) only takes 84 pins. Surely, they can squeeze those in.

<comment><USER6> I would guess that having a high speed cache on chip would be a better use of real-estate.

Going with multiple mem controllers means that performance would still probably be pretty variable, depending on how the mem controllers are mapped to your physical addresses + how your data is laid out.

</comment></comment><comment><USER7> Memory latency problems can be worked around with pipelined requests, if you have enough concurrency in the CPU; memory bandwidth problems can be worked around with more independent banks of memory and more memory channels to the CPU, which means more wires. Both can be worked around by putting more memory locally.

Absent such workarounds, it's true that there are some problems (large-mesh finite element analysis, maybe) that more cores won't help with, and other problems that exhibit enough locality (large cellular automata) that more cores _will_ help with. This article observes that some problems are in the first category. It would be absurd to claim that no problems are in the second category.

</comment><comment><USER8> Perhaps this would be an extremely inefficient use of chip real estate, but what if extra cores were used to execute the same set of instructions in parallel with both outcomes of conditional branches (i.e. completely replace branch prediction) and take whichever one ends up being correct?

On second thought, it's probably not worth it. It seems modern branch predictors are at least 90% accurate (<http://en.wikipedia.org/wiki/Branch_predictor>), and only a few percent of instructions are conditional branches anyway ([http://bloggablea.wordpress.com/2007/04/27/so-does-anyone- ev...](http://bloggablea.wordpress.com/2007/04/27/so-does-anyone-even-use-all- these-darn-cpu-instructions/)).

</comment><comment><USER9> If a problem is parallelisable to that extent, are the cores actually hitting the same memory? (Presumably not, since you don't want multiple threads mutating the same memory).

So the problem is really that we have:

[lots of cores] <=chokepoint of memory bus=> [lots of ram]

when we could have:

k times: [1/k of our cores] <=single mem bus=> [1/k of our RAM]

That increases our aggregate memory bwidth by a factor of k. This has to be <= number of cores, and the problem being solved needs to be able to be partitioned into k chunks.

This is basically the clustering approach (individual proc+ram working on the problem), with the added advantage that we can leave some of the RAM unsplit so we get 'local' shared RAM for free.

<comment><USER10> No, the crossbar between the cores and memory controllers is not a problem. The problem is getting enough pins to attach more than four memory channels.

<comment><USER9> OK, thanks. So the problem is that transistor density is going up faster than pin density? Makes sense.

I guess one approach to that is a bigger die size, so you end up with a fixed transistor/cm^2? That would mean die sizes doubling with Moore's law I guess. So you'd want other ways of packing them in (use the flipside of the mobo, try 3d arrays and suffer heat problems).

Or the cores come with attached (non-shared) RAM, which is of course where we are with adding cache.

Other random thoughts: why have memory busses stayed parallel when peripheral busses (scsi, usb) have gone serial? That would reduce pin count for a connection?

Can we avoid going to full 'macro' pins for the CPU-memory bus (and thus pack more pins into the same area for memory connections)? Instead have a smaller, denser collection of pins which are attached as a group to each memory connector?

Sorry for being clueless and thinking aloud, but it's an interesting problem.

<comment><USER10> I don't think the die size is a problem; AFAIK you can get very many pins out of a die, but getting them out of the package is where it gets expensive.

FB-DIMM is already a serial-style high-frequency interconnect, but it isn't needed on low-end systems.

I think this is really about business, not technology. What they want is not what the mainstream wants, so they must choose between cheap but memory starved systems or very expensive balanced systems. HPC people have been whining about killer micros for 20 years; this is just another version of it.

</comment></comment></comment></comment><comment><USER11> _I think there is a world market for maybe five computers._

<comment><USER12> Did you actually read the article? How is it in anyway related to the "five computers" thingy? The article is talking about an architectural limitation not a business/consumer one.

<comment><USER11> Claiming limitations when it comes to technology usually proves short-sighted. The quotes about five computers, 640k of memory, etc, are not formally comparable but they give the anecdotal hint that limitations will always be beaten.

The point made in this article surrounds current architectures and their limitations. The conclusion that more than 16 cores makes no sense might well be a good conclusion for now, but "more than 16 cores may well be pointless" is by no means a conclusion for the long or even mid term.

<comment><USER13> "they give the anecdotal hint that limitations will ALWAYS be beaten."

Don't you mean usually? I haven't seen the big break throughs in AI that were expected. I haven't seen a solution to the halting problem, etc, etc.

<comment><USER14> Because, by definition, when an AI breakthrough is achieved, it's no longer AI...

<comment><USER13> that's a good soundbite, but it's nonsense.

AI hasn't lived up to the promises made a few decades ago.

* 1958, H. A. Simon and Allen Newell: "within ten years a digital computer will be the world's chess champion" and "within ten years a digital computer will discover and prove an important new mathematical theorem."[53]

* 1965, H. A. Simon: "machines will be capable, within twenty years, of doing any work a man can do."[54]

* 1967, Marvin Minsky: "Within a generation ... the problem of creating 'artificial intelligence' will substantially be solved."[55]

* 1970, Marvin Minsky (in Life Magazine): "In from three to eight years we will have a machine with the general intelligence of an average human being."[56]

<comment><USER4> I like how you found 2 people who support your argument, but there is a gap separating predictions from promises. Many classical definitions of AI have been surpassed, but because people are still better at a verity of tasks we say we don't have AI.

PS: A digital computer is the worlds chess champion or would be if we let them compete. Making a useful captia is hard, but computers don't compose poetry so we can still say we don't have AI.

<comment><USER13> poetry is a bad example. A computer still can't translate from one language to another at a level anyone would trust for something important.

<comment><USER4> Computer translations fall in between a freshman HS language student and an expert. I am not going to trust it for diplomatic negotiations, but I have still used it for some verifiable tasks. Voice to text translations also fit in this context if you can't type then it's ok, but if you need a high level of accuracy then use a person. Which IMO describes the state of most computer AI. It's picking stocks and rejecting parts but I still want a real doctor.

<comment><USER13> exactly, AI hasn't lived up to the promises which was my original point. Remember I was responding to this quote,

"they give the anecdotal hint that limitations will ALWAYS be beaten."

Limitations will not always be beaten.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> How does this development affect the issue then?

<http://news.ycombinator.com/item?id=389857>

</comment><comment><USER16> Assuming "stacking memory chips on top of the processor" means local stores for each processor, it's pretty much a given at this point. That's how GPUs work (~16k local), and that's how the PS3 SPUs are (256k local).

It's _extraordinarily_ painful to code for, but hey, all performance optimization is an exercise in caching. So it goes.

<comment><USER3> Yeah, essentially the processor cores start looking like ccNUMA boxes. The late 1990s called, they want their architecture back :-)

IMHO, it looks like we'll need some smarter memory bus management. If we're looking at the 1990s, anyone remember the crossbar switches SGI used to put in their short-lived x86 boxes? Thoughts on effectiveness?

<comment><USER17> That's what I was going to post. Use NUMA - each core gets it's own memory. Doesn't linux support NUMA?

It seems to me that each thread already has it's own memory space, just make sure the memory space for the thread is on the same CPU the thread runs on.

It isn't really necessary for each core to be able to access all memory (or at least it'll be way slower to access memory outside it's area).

</comment></comment></comment><comment><USER18> Don't super computers have shared direct memory access of all the memory for all CPUs?

Perhaps it is time for home desktops to adopt the super computer architecture!

<comment><USER18> Alright I'm not a hardware engineer I don't even like assembly.

Can somebody explain how mainframe DMA is different from the DMA in your home PC?

I know mainframes have more then 16 CPUs. The memory problem we're talking about here does not apply to them, right?

</comment></comment><comment><USER19> Why stack? Just make it an onion.

</comment><comment><USER20> "640K ought to be enough for anybody." \- (Never actually said by) Bill Gates

<comment><USER8> That quote is irrelevant, except that both the quote and title of the article are misleading.

The real title should have been "With the current architectures and/or memory speeds, more than 16 cores may well be pointless".

<comment><USER21> "may or may not be pointless, becasue author couldn't find the data to backup his point".

There, FTFY.

<comment><USER8> Well, the basic premise of the article is common sense. The memory needs to feed the processor instructions and data.

If the clock speed and number of cores increases at a faster rate than memory speed increases (assuming all the cores share memory) then at some point the memory can't keep up.

Whether or not 16 cores is the magic number, I don't know.

<comment><USER4> Your assuming a linear relationship between memory access and number of cores but the size of L2/L3 cache mitigates the problem to some degree. We already have chips with 12+ MB which is plenty of RAM to run windows 3.11. The real question is what type of workload do you have and how well does that play with the number of cores your using etc.</comment></comment></comment></comment></comment>