"They all look alike": Understanding the "other race effect" - <AUTHOR> http://arstechnica.com/science/news/2010/11/understanding-the-other-race-effect.ars <comment><USER2> I remember looking at a high-school yearbook from the beehive hairdo era and remarking to the owner, Geez, you all really wanted to look just alike. I went to high school in a day and place where the girls grew their hair long and left it down, and in looking at that yearbook, all I could see was the beehives.

In fact, at a second look, of course the faces were quite distinguishable. No doubt they were more readily distinguishable then and there because varying hairdos did not distract one from the faces.

</comment><comment><USER3> There seems to be many factors besides race that could be the actual cause of this, such as that people of one race are most likely to be around people of the same race, and people's family is from the same race. Having the hypothesis that race is the cause of this implies this is a genetic phenomenon, whereas it seems more likely an environmental one to me.

<comment><USER4> There's a fair amount of research that suggests that the FFA (fusiform face area, where we supposedly process faces) is really just specialized for processing objects that we're very familiar with. For example, bird-watchers' FFAs light up more when they're differentiating between birds, and I think they have increased repetition suppression too.

Anyway, the theory behind that research is that we process faces differently because we're all very familiar with them, so it would make a lot of sense if this other-race effect is purely because Western Caucasians see Western Caucasian faces more and East Asians see East Asian faces more.

I'd like to see the study done with people who are living in a country where their race is a tiny minority.

<comment><USER5> That's a really good point. This may be telling us something more general about what the cerebral cortex is doing, too.

For example, when people learn a new language that involves phonemes very different from those of their native tongue, they often go through a phase where not only do they have difficulty producing the foreign sounds but have difficulty distinguishing sounds that would seem very different to a native speaker. For example, R and L are perceived as very similar to a native japanese speaker and the nasal vowels of french and portuguese are notoriously difficult for english speakers register.

It could be that Wernicke's area (were language is supposedly processed) is really just specialized for processing complex sounds that we are very familiar with. So you'd expect a bird-watcher specialization effect from ... opera goers? safe crackers? sonar operators?

</comment></comment></comment><comment><USER6> When I (caucasian) moved first to Japan for six months I had a difficult time telling Japanese people apart. By the time I had been there for 4 months this effect was significantly less. In addition I remember being startled to realize that people looked "less japanese" to me.

<comment><USER7> I know exactly what you mean. I have spend enough years interacting with people from Turkey that I no longer recognize any kind of Turkish accent.

</comment></comment><comment><USER8> Somewhat related: you can quiz yourself on whether you can tell apart East Asians' ethnicity by looking at them.

<http://alllooksame.com/exam_room.php>

I scored no better than random for face recognition, though some of the other quizzes had fragments of text that gave the answer away.

</comment><comment><USER9> Does the facial recognition signal N170 generalise/apply to other species too? Dog faces? Cat faces?

<comment><USER10> The article took a 2nd reading to grok, but the experiment shows that N170 recognizes the same face, but only if that face is the same ethnicity. Meaning it is very specific. Presumably, if it can't recognize the same face of another ethnicity, it surely can't recognize the same of another species.

</comment></comment><comment><USER11> Simple explanation: we don't know how to distinguish between faces "out of the box", we have to be trained to do it. Most of our training happens within our own race, so we become very good at distinguishing faces.

When presented with completely different type of faces, we have to work hard to tell two faces apart, we can't just distinguish them on first sight.

It's like knowing to tell the alphabet from your own language vs some other language you're encountering for the first time.

<comment><USER12> We have specialized circuitry to process faces. People are congenitally deficient in this regard suffer from prosopagnosia (in the same way that some people with normal hearing are tone deaf).

That said, you're not completely off track. It is very likely that said circuitry becomes better at disinguishing the kind of faces it has been initially trained with.

A nice complement for this study would be to test mixed race and adopted people.

<comment><USER13> I don't have any studies on hand, but I specifically remember a lecture I attended where it was noted that infants do not have specialized circuitry to process faces. Their affinity for their caretakers, at least at a very early age, is actually not a result of recognizing people, but of the caretakers subconsciously learning how to better provoke an affectionate response.

You also saw this effect with the emotional robot Kismet at MIT. Its reactions were totally hardwired, but it managed to fool people into believing that it "liked" them.

</comment></comment></comment><comment><USER14> This seems to me a simple instance of the general fact that, for telling things apart, you only observe as deeply as you need to, and it takes a while to get used to observing deeper.

For example, suppose I learn the phone numbers of my neighbors. Then I meet a friend who lives across town, and his phone number starts with 322-, while all my neighbors' numbers start with 494-, so when I see a caller ID beginning with 322-, then I immediately know it's him. But then I make several more across-town friends, and holy crap now there are four numbers beginning with 322-, so now I learn to pay attention to all seven digits.

Then I meet someone at a summer camp, and his phone number is in a whole freakin' new area code, so if I see "(408)" then I know it's him. But then if I meet more people in 408, I'll have to learn to look at the rest of the number when it begins with 408.

Or, think of backpacks. I have the only black backpack in my class; that makes it easy for me to tell mine apart. But now someone else gets a black backpack, and I say to myself, hmm, well, mine's got thick straps. Then maybe someone gets the exact same model of backpack, and I'm like, dammit, fine, I'll write my _name_ on mine.

Cars. Mine is a big white car. That worked fine for a few years. Then I saw other big white cars. Mine is a Toyota minivan. Worked fine for some more years. Then I saw another white Toyota minivan, but it had different hubcaps. Fine. Now I've seen a few that are the same model and color of car with same hubcaps; gotta look at the license plate to be sure.

With people, there are many ways to distinguish people. Male/female. Long hair, frizzy hair, buzzcut. Really tall, really short. Color of skin. Color of hair. Facial features common to certain races. Fat. Always wears a particular hat or jacket.

At any time, people's methods of telling people apart are likely not much more sophisticated than they need to be, and if they're thrust into a situation in which those methods don't work well, then obviously they'll have trouble telling people apart. And, given time, they will learn and use new methods and get better at it.

So: There's nothing special about race, there's nothing special about faces, and there's nothing special about finding it hard to distinguish things in ways that you're not used to.

<comment><USER15> This is absolutely what is going on.

My brother had an interesting experience with this. He grew up with Caucasian faces. Then moved to Taiwan. After several years there he came back to Canada. What he quickly realized is that he had learned how to tell Chinese people apart, but had forgotten how to tell Caucasians apart. Given that he actually remembered a lot of Caucasians, a large fraction of the population looked like (but wasn't) someone he knew.

He found this very confusing.</comment></comment>


Croudcube experience bad gateway due to Freetrade's open round - <AUTHOR> Anyone experiencing bad gateway or gateway time-outs when investing in Freetrade's round? <comment><USER2> Crowdcube have acknowledged they're experiencing issues.

[https://twitter.com/Crowdcube/status/1121366289057030144](https://twitter.com/Crowdcube/status/1121366289057030144)

<comment><AUTHOR> I was looking at this right now! Thanks for sharing :)</comment></comment>


Bits of History, Words of Advice (On Smalltalk) - <AUTHOR> https://gbracha.blogspot.com/2020/05/bits-of-history-words-of-advice.html <comment><USER2> The title of the blog post is from the "green book" that describes the efforts of the companies Xerox first licensed Smalltalk to:

[http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/](http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/)

</comment><comment><AUTHOR> Some bits that stood out to me, though the whole piece is full of interesting points:

> I believe, the community has been self-selected to consist of those who are > not bothered by Smalltalk's initial limitations, and so are unmotivated to > address them or support those who do. In fact, they often could not even see > these limitations staring them in the face, causing them to adopt > unrealistic business policies that hurt them more than anyone else.

> Perhaps an even deeper problem with Smalltalk is that it attracts people who > are a tad too creative and imaginative; organizing them into a cohesive > movement is like herding cats.

</comment><comment><USER3> I work in Smalltalk for hobby projects and it's mostly a fun experience. Very powerful debugging and introspection makes it easy to take on stuff I would not consider in any other system.

<comment><USER4> Which implementation do you use and what sort of projects are you implementing?

<comment><USER3> I mostly work with Squeak and do small explorations with graphics and games</comment></comment></comment>


After a second-stage failure, Rocket Lab loses seven satellites - <AUTHOR> https://arstechnica.com/science/2020/07/on-its-13th-launch-rocket-lab-loses-a-mission/ <comment><USER2> HN discussion here: [https://news.ycombinator.com/item?id=23735205](https://news.ycombinator.com/item?id=23735205)</comment>


Email: Archive It All. Immediately. - <AUTHOR> http://parislemon.com/post/20671851536/email-archive-it-all-immediately <comment><USER2> I use GMail's Priority Inbox feature (Settings > Inbox > Inbox Type > Priority Inbox). Sections are

1\. Important and Unread

2\. Starred

3\. Anything else

Essentially, mail from anyone that isn't "important" (previously messaged contacts, ongoing threads, people I communicate with frequently in Google Talk, etc) is put into the Everything Else section. Occasionally, perhaps once a day, or once every couple of days, I will look through my Everything Else pile, and either Star the message, to read later, or mark the sender as important, so I get future communication sent to my Important and Unread section.

I treat my Starred list as a sort of "look at this eventually and do something with it" list. My Everything Else section grows and grows and I just ignore it.

It's great. I set alerts on my phone to only trigger when I get an Important and Unread message, and I find that I'm checking my mail a lot less than I usually would.

</comment><comment><USER3> I am open to the possibility that this is a good idea for people who get a ton of email, but it would be nice if the sender got some sort of indication that his message is unlikely be seen by a human any time soon.</comment>


Ask HN: Computer science heavy fields - <AUTHOR> I am a fullstack web developer. I write build and manage servers in python, or javascript. I write frontends with any of a host of frameworks. I setup logging, and monitors, and CI/CD pipelines.
I slowly refine the process and the product, a little each day.
I have a degree in engineering and I rarely if ever use what I learned. Everything I use is backed by core CS, but us consumers needn't even really know about that. Is the majority of web development like this? Or am I caught in an anomaly?
On top of that, these web-apps we put up are so fragile. Hot one year, archived the next. What fields are more long lasting? Where is the important work being done?
..please don't say blockchain. <comment><USER2> GPU and everything related. 3D graphics now has a very bright future and is not easy!</comment>


"I'm angry at Facebook – but I'm also addicted. How do I break free?" - <AUTHOR> https://www.theguardian.com/technology/2018/apr/12/facebook-how-to-quit-delete-account-addiction-what-to-do <comment><USER2> <irony>move to instagram+whatsapp

<comment><USER3> Cold Turkey!

I messaged everyone I wanted to keep in contact, send me your contact info (whatever I didn't currently have).

It helped me see who I actually wanted to be friends with. If I don't want to take the time to get your phone/email, why the hell do I care if we're facebook friends?</comment></comment>


Show HN: CLMM, an exercise in cryptographic minimalism - <AUTHOR> https://github.com/rongarret/clmm <comment><USER2> Isn't this just similar to PGP but with a smaller public key?

<comment><USER3> Yes, minus the whole WoT part.

Note also that support for ECC is already there in the latest GnuPG, and Ed25519 is already supported for signatures. The rest is coming:

[https://gnupg.org/faq/whats-new-in-2.1.html#ecc](https://gnupg.org/faq/whats- new-in-2.1.html#ecc)

<comment><AUTHOR> > minus the whole WoT part

CLMM is not even close to being as featureful as GnuPG. But it does a lot for being <1500 LOC (compare to >200 kLOC for GnuPG). If you want to look under the hood to see how things word, CLMM is a lot more accessible, which was its primary goal.

<comment><USER4> Another project which seems similar in spirit is reop: [http://www.tedunangst.com/flak/post/reop](http://www.tedunangst.com/flak/post/reop)

</comment></comment></comment></comment><comment><USER5> Hi, from a quick glance there seems to be a few problems that should be easy to fix:

* You should enable -Wall and -Wextra, there are a few other flags that are usually useful as well which I forget.

* You should pass the -std=c99 flag to the compiler, it fails otherwise on my setup (Debian 7.x)

Despite warnings not being enabled, I get many. Implicit declarations of strlen, asprintf, getpassn. This seems to partialy be caused by including strings.h and not string.h.

<comment><AUTHOR> Thanks. I developed it on a Mac. I'll fix the Linux problems ASAP.

</comment></comment><comment><USER6> Any plan to make it tweetable as well? :)

<comment><AUTHOR> No, but it's MIT-licensed so if you want to tweet it by all means go for it.</comment></comment>


Characteristics of a good web developer - <AUTHOR> http://blog.karolzielinski.com/charasterics-of-good-web-developer

<comment><USER2> This article could be alternatively titled "characteristics of programmers I wouldn't want to work with".

Seriously, this sounds like a recipe book for one person writing code in isolation that nobody cares about, rather than any sort of serious criteria for judging the merits of a web developer.

Personally, I think being a good web developer is just the same as being a good developer. You always need to have a good working knowledge of your problem domain. You need to understand the environment you work in.

My favourite part was "needs to know english. Did you born in USA, UK, Canada, Australia or any other english speaking country?". Did I was ever!</comment>


'The Ensemble' team overtakes Bellkor in the Netflix Prize - <AUTHOR> http://www.the-ensemble.com/content/final-submission-countdown

<comment><AUTHOR> The Leaderboard can be found here:

<http://www.netflixprize.com/leaderboard>

</comment><comment><USER2> Good writeup of a true deadline pursuit with a distributed team, one of whom is offline.</comment>


Updated list of my GNU Make articles - <AUTHOR> http://blog.jgc.org/2013/02/updated-list-of-my-gnu-make-articles.html

<comment><USER2> I have been programming in Object Pascal recently and one of the things that makes me happy: no make files. The compiler figures dependencies out.

This will be helpful for work though, thank you.

</comment><comment><USER3> Thank you for the update.</comment>


Playful attempt to reinvent the keyboard as you know it - <AUTHOR> http://sigma.eruditenow.com/ <comment><AUTHOR> I have to warn you that it's not very mobile friendly! It's made for keyboard use only even though gamepad support is to be added real soon.</comment>


Making Clouds Go Away on MapBox Satellite - <AUTHOR> http://mapbox.com/blog/improving-mapbox-satellite-by-making-clouds-disappear

<comment><USER2> The maps look absolutely beautiful. Can I suggest you drop Apple a call and offer your assistance? I just came back from Singapore, and good portions of their hybrid maps were basically unusable because of cloud obstruction. (To be fair, Google also has a bit of cloud coverage of Singapore - but their hybrid maps were completely usable).

Cloud obstruction of satellite imagery six months after Apple released their mapping data, seems to indicate a fundamental lack of knowledge of how to deal with those type of obstructions, so hopefully your call will be well received.

<comment><USER3> Got a number?

</comment></comment><comment><USER4> Wouldn´t the sun-synchronous orbit allow you to use a similar a pipeline with local-time filtering to create a night-time map? That would be quite amazing, and also useful for socio-economic folks (or even correlate that with OSM coverage)

I could only find a related talk about this here: [http://modis.gsfc.nasa.gov/sci_team/meetings/199905/presenta...](http://modis.gsfc.nasa.gov/sci_team/meetings/199905/presentations/Muller_Night- Time.pdf)

</comment><comment><USER5> The images are amazing. When looking for clear skies, I was curious if you saved any metrics regarding how often a particular location (pixel) is clear or cloudy?

(NOTE: I have no intention of visiting the cloudiest place on earth with my vampire hunting kit. ;-)

You might find the weather simulation work done on the old (2005) "Earth Simulator" or newer (2011) "K Computer" supercomputers in Japan really interesting.

[http://www.hpcwire.com/hpcwire/2011-06-20/japanese_supercomp...](http://www.hpcwire.com/hpcwire/2011-06-20/japanese_supercomputer_is_new_top500_champ.html)

<comment><USER6> _I was curious if you saved any metrics regarding how often a particular location (pixel) is clear or cloudy?_

We didn't, but it would be pretty easy to re-derive. The cloudiest places at this scale are the sides of mountains in the Intertropical Convergence Zone[0], where wet air rises several thousand meters, thus cooling and thus condensing. For example, tomorrow I'll be spending a lot of time looking at Andes in Colombia, Ecuador, and Peru.

0\. [http://www.youtube.com/watch?feature=player_embedded&v=Y...](http://www.youtube.com/watch?feature=player_embedded&v=YtJzn8A725w)

</comment></comment><comment><USER7> This is pretty cool !

I worked on a similar problem during my bachelor thesis[1] : I wrote an algorithm to remove clouds from NDVI images (used for deforestation detection[2]). We used fourrier, moving windows and some ugly hacks to detect and interpolate cloudy data. There are some details in my report.

[1] <http://ape.iict.ch/teaching/DiplomaReports/2009_Rebetez.pdf>

[2] <http://terra-i.org/terra-i.html>

</comment><comment><USER8> shamelessplug: Actually MODIS scans Earth using different wave lengths. The near infrared channel can be used to detect clouds and even to distinguish them from ice. Using a little recursive AviSynth Script I was able to produce an animation of daily changes in the European part of the Arctic with last year's data. It starts with all the clouds and then adds each day's cloud free pixels. The goal was to visualize how Kara Sea melted out within a few days. Enjoy: <http://www.youtube.com/watch?v=j-EDFs8f_78> /shamelessplug

</comment><comment><USER9> Cool. I hope they do it separately for winter and summer so as to give an idea of typical snow/ice cover.

<comment><USER6> Author here.

We're doing almost the opposite – as little non-permanent snow and ice as we can manage. The reason is simply that we want to make this as useful as possible as a general-purpose base layer, and people usually want to see spring/summer growth. It looks subjectively right even in regions where it's only around for a minority of the year.

If you're interested in seasonal dynamics, I recommend Blue Marble[0]. It's really good work – we're in touch with some of the people who made it, and they're sharp folks. But it's half the resolution that we're aiming for, and has some areas of distracting interpolation artifacts. Our main goal is accuracy, but we're also going for aesthetics in a way that Blue Marble wasn't.

0\. <http://earthobservatory.nasa.gov/Features/BlueMarble/>

<comment><USER9> Thanks for response.

I think what you are doing makes sense for most purposes and I look forward to seeing the final layers.

I'm especially interested in snow cover because of a side project of mine (hillmap.com) that is targeted at backcountry travelers (ski tourers, hikers etc...especially winter travelers since it does things like avalanche terrain analysis in a canvas overlay).

Blue marble is cool and there are some overlays from NOAA etc but winter satellite photos good enough to answer questions like "is this typically an open snow field or heinous bushwhack" or "does this lake freeze over" would be really useful for planing trips in winter or colder climates.

If you guys (or someone) hosted the daily datasets it would be possible to do the processing client side in a canvas for a user defined time periods which would be an awesome tool.

<comment><USER6> Hmm. I don't know of any specific product that does what you need (high resolution and near-realtime is usually an expensive combination), but I would definitely look through the National Snow and Ice Data Center's projects: <http://nsidc.org>

</comment></comment></comment></comment><comment><USER10> This is interesting, but very low on detail. For example, was another modis product used for clouds or was it based on a simple EVI/water cloud mask? Is this MOD09A1, 500m or 250m? Lastly, why or how is this MODIS layer going to compliment existing Landsat or DigitalGlobe?

</comment><comment><USER11> looks pretty cool. great work. I especially loved the fact that your mehod does not blur the edges significantly and the color profiles are pretty good.

I have a few questions you haven't mentioned in your blog and would appreciate it if you can answer them here.

is there some sort of public ftp server you can log in and get say the last 2 days' maps of any given coordinate ? and if so can you share the address ?

additionally, are the image coordinates that come with the images really that accurate that you can do pixel comparisons over time without doing any sort of registration ?

</comment><comment><USER12> Wouldn't the clouds still interfere with the averages though? That is areas that have lots of clouds would seem whiter than they really are? It seems to look alright though.

<comment><USER13> They detect the images with clouds, then average the rest.

<comment><USER12> Ok that makes sense. I thought they were using this as a replacement for filtering out pictures with clouds.

<comment><USER6> Well, we're actually filtering out _pixels_ with clouds. That's what makes it seamless. Or, really, it's extremely seamy, but all the seams are very subtle and between individual pixels instead of larger regions.

<comment><USER14> How do you know the difference between a cloud and a snowy/white sand area of ground?

<comment><USER10> There is a lot of work done for this in the scientific community, there are many algorithms. (is <http://modis-atmos.gsfc.nasa.gov/MOD06_L2/>) The most basic way is to look at the reflectivity, which must be very high, and the temperature, which must be very low. In this case, however, they probably do simply throw out all the snowy/white areas.</comment></comment></comment></comment></comment></comment>


Coronavirus: Would you volunteer to be exposed? These Stanford grads did - <AUTHOR> https://www.mercurynews.com/2020/04/25/coronavirus-would-you-volunteer-to-be-exposed-these-stanford-grads-did/ <comment><USER2> I would but I have a young child and spouse. It's not even so much the risk of serious medical complications for me, it's the complications involved in isolating myself, if that were even possible. It's one thing to increase your risk of exposure with a family; it's another to deliberately infect yourself. Definitely not saying it's morally wrong necessarily, just that I haven't quite figured out a way to do it in which my family would feel ok with it or understand.

<comment><USER3> I volunteered yesterday after seeing this article. To be clear, this is a very early expression of interest and there is no specific human challenge trial which is ready to begin at this time. Consequently, the exact trial implementation details are to be determined.

That said, I would be shocked if any such trial didn't involve the isolation of subjects in provided accommodations for the full duration of the study. It would be necessary on ethical grounds for the purpose of community safety. Obviously, that doesn't mean you should volunteer (it is still a risk to your health and extended isolation from your family would suck), but they aren't just going to infect you and then send you home to come back in a few weeks.

</comment></comment><comment><USER4> This is a no-brainer. I am a health 46 year old male. I have a living will, do not resuscitate order, all my organs are to be donated, and the leftovers will go to my local medical college. If it were a part of a well organized medical study whose findings would be accessible or open source in some way (aka not for a pharmaceutical or university's own profit) then I'd gladly get be exposed. Where do I sign up?

</comment><comment><USER5> Hats off to them.

</comment><comment><USER6> I saw this on Reddit and volunteered immediately.

It is an ethical no-brainer, with the one caveat that the study is run well.

I am not sure about this article though. It focuses on these young biologists who like me have not actually done anything yet, and suggests low volunteer numbers.

Thinking of this as a fringe thing may undermine the effort. I think you would likely get on the order of 10M-100M global volunteers for something like this from all walks of life, and it's so obvious that it's worth considering that it just reads wrong to me.

My impression from listening to the CEO of Moderna and others that most people are more worried about the safety of the vaccine and the speed to ramp up manufacturing, not the efficacy. (Source: [https://www.youtube.com/watch?v=XvYiuoJ_lrI](https://www.youtube.com/watch?v=XvYiuoJ_lrI))

So while saving even 1 month makes an enormous difference, I am unsure how much human challenge studies change the timeline of an actual vaccine.

</comment><comment><USER7> "Volunteer" shouldn't be the word here.

It should be "paid".

If the pay was $10k per participant, the world would happily pay 100 people for each of 10 vaccine trials.

The people would understand the risk they were taking and be happy that the $10k was worth it for them. Countries would be happy that the payment was good value for money for finding a vaccine for their population.

"Volunteering" is in my mind ethically wrong - you are paying people in 'goodwill', which doesn't and shouldn't cover the risk satisfactorily.

<comment><USER8> This 100%! The companies sure as hell aren't "volunteering" to make the vaccines.

</comment></comment><comment><USER9> This is really inspiring.

</comment><comment><USER10> Exposed to SARS-CoV-2? Absolutely, no problem.

Exposed to god-knows-what in their untested vaccine? Absolutely not, even five years after release ("my body, my choice"). There is a long history of contaminants in biologics, and vaccines in particular. Problems like GBS (Guillain-Barre Syndrome), tumors, polio, and who knows what from PCV. If I recall correctly, wasn't SV-40 injected into 25 million Americans, and perhaps hundreds of millions world-wide? Well-tested and analyzed vaccines like BCG I have no problem with, but being a guinea pig for whatever was cooked up in a rush over the last few weeks? Count me out.

The headline has it backwards -- the more significant (unbounded) risk is from the therapy, not the SARS-CoV-2 exposure.

<comment><USER11> It sounds to me like your risk assessment is a little unbalanced.

We also have no idea what the medium and long term effects of being infected with SARS-CoV-2 are, so why are you happy to be exposed to it?

<comment><USER10> Because coming from a natural source, namely other people, I can estimate risk probabilities for a range of outcomes, in the short term. Highly pathogenic viruses in general have a tendency to become attenuated as they spread, due to evolutionary pressure. In the medium and long terms, there are two main benefits to the virus versus an experimental vaccine. One is that there are no known long-term effects (aside from scarring) from other closely-related viruses, and two is that because tens of millions (or more) of other people have been (or will be) infected by it, there is enough of a population for serious focus and work to be done on dealing with it. Lastly, it isn't unreasonable to assume that practically everyone will be exposed to it anyway.

Vaccines, on the other hand, especially experimental ones, have been historically known to suffer from contamination (biological or otherwise), and result in strange, hard-to-diagnose problems. These problems are suffered by a tiny population (the experimental group), with no broad societal, medical, or research support -- which makes sense, since the highest societal priority is typically to help as many people as possible. The three main concerns with the vaccines themselves are that (a) there's no biological pressure to attenuate negative effects, (b) the biologic components themselves may infect the patient, without any point of comparison commensurate with widespread viruses in the field, and (c) the other ingredients (stabilizers, preservatives, etc.) in vaccines are often toxic in their own right. In the past it has taken many years, even a decade or more, to get it all right.

<comment><USER10> As a footnote, I came across a couple interesting papers on the topic of vaccine contamination from around 2012. They talk about the usual development time being 8-10 years, and about a few recent cases of vaccine contamination.

Extraneous agent detection in vaccines: [https://www.researchgate.net/profile/Attila_Farsang_Dr/publi...](https://www.researchgate.net/profile/Attila_Farsang_Dr/publication/224939093_Extraneous_agent_detection_in_vaccines_- _A_review_of_technical_aspects/links/59ea4ba2aca272cddddb7cce/Extraneous- agent-detection-in-vaccines-A-review-of-technical-aspects.pdf)

Detection of Avian Retroviruses in Vaccines: [https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3647912/](https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3647912/)</comment></comment></comment></comment>


Relearn CSS layout - <AUTHOR> https://every-layout.dev/ <comment><USER2> To me an evident thing in UI development is that separating stylesheet from layout isn't really a thing anymore and the benefits of this separation aren't really that clear.

Things like SwiftUI and React are showing that declarative UIs can be built by tying the style to the layout and allow for much better accessibility, tooling, overall thinking of how UIs work.

So to me CSS feels a bit outdated since big companies are definitely moving away from this separation. How does HN feel about this?

<comment><USER3> I work as a web developer for an enterprise-level software company.

Experimented a bit with CSS-in-JS, which is designed to get rid of this separation, and I found it to ultimately be harder to maintain than SCSS. This process was also what got me hooked on BEM after being initially pretty skeptical about whether it had any real value.

I now believe that BEM would meet the needs of most teams, with the exception of a few massive software houses like Facebook. And most companies don't fall into the Facebook category, even if they think they do.

I've also taken some time to reflect on older companies I've worked for, particularly some work I did at Oracle, which was for a reasonably large team spread across several continents. I think BEM would have been good enough for us there as well.

I would propose the following test: Is your front end in a monorepo? If so, BEM is probably good enough to solve any problems with scope and style conflicts. If your code can fit in a monorepo, I think its _unlikely_ you will ever have a legitimate reason to duplicate a component name in multiple places.

Take it or leave it, just my experience, I'm sure other people would advocate different things. But it's by no means a settled debate, different people/orgs have come to different conclusions. It's just that one side writes a lot more blog posts.

<comment><USER4> Show us a pastebin of your compiled CSS. I can tell you from now your CSS is bloated with the uncountable properties and classes that repeat the same fixes and structures. You can program functional CSS and get better in way.

<comment><USER5> But does bloated CSS matter?

If a human isn't going to read the CSS and the computer handles it without performance problem, I say no.

Those are of course two quite important ifs!

<comment><USER4> It matters.

First, not all users need your huge CSS file, in terms of downloading. Specially when they're on mobile phones and cache is crap.

A ~9000 rules CSS file will load and become COSSM slower than one that has 1000 or 10. It is linear increment. Make a test to see it for yourself.

A bloated CSS is more network time. Therefore, slower loading.

A bloated CSS will contain slower selectors, therefore slower rendering time and painting speed.

When you count all these things, you will see radical speed performance.

<comment><USER5> Maybe. You need to _measure_ these things and get a feel for the _actual_ performance impact to make informed decisions.

Rule 1 of performance: Your intuitions are _not_ reliable.

<comment><USER6> Upthread, this commenter did post specific measurements from production projects.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> I've written a series of very similar articles, and seeing as some of the ones in this site don't seem to be available yet, and otherwise as another point of view, they may be of interest to anyone looking at this: [https://ctidd.com/2017/css-ui-patterns/content](https://ctidd.com/2017/css- ui-patterns/content)

</comment><comment><AUTHOR> Saw this awesome project on Lobsters. I went ahead and ported these components to generalized, composable Styled Components. There's also an npm package at `every-layout`.

[https://github.com/aarohmankad/every- layout](https://github.com/aarohmankad/every-layout)

<comment><USER8> You mean "React Components" right? Nice effort, but please mention that these components are supposed to work with React. If we now use the word "Component" as a synonym for React, you make it look like there are no other frameworks than React.

<comment><USER9> No, he meant Styled Components, a popular library for styling React components.

<comment><USER8> I see, didn't know about this. Thanks for pointing it out!

</comment></comment></comment></comment><comment><USER10> Out of curiosity, why doesn't the stack layout use flexbox? It seems like flexbox is the perfect fit for such a layout.

<comment><USER11> Flex is great for one directional layout within a box. It is not great for two dimensions which most layout is concerned with.

<comment><USER12> The stack is not two dimensional.

<comment><USER11> Has nothing to do with what we're talking about.

</comment></comment></comment></comment><comment><USER13> started reading some of the ideas and got put-off almost immediately. 'margin- top'? the owl-selector? Really? Why do we keep making our life more difficult than it should be? CSS is such a beautiful and interesting tool, yet we still decide to misuse it in trying to be too smart.

( margin-top: you start dealing with parents inheriting the margin - which is an old quirk of CSS - it's a side-effect you need to control, so the usage of margin-top should always be avoided and margin-bottom should be the preferred solution owl selector: performance implications - it's fairly bad from a performance POV to use it. Also, we live in a world where we have control over how the layout is generated, we should avoid using generic selectors Source: I've been doing frontend and focused on CSS for over 10 years )

<comment><USER14> > so the usage of margin-top should always be avoided

Not really if you consider sibling layouts, e.g.: [https://matthewjamestaylor.com/css-margin-top-vs- bottom](https://matthewjamestaylor.com/css-margin-top-vs-bottom)

> owl selector: performance implications - it's fairly bad from a performance > POV to use it.

Arguing about "CSS performance" is futile when the real cause of bloatedness is mostly JavaScript these days (also: [http://alistapart.com/article/axiomatic-css-and- lobotomized-...](http://alistapart.com/article/axiomatic-css-and-lobotomized- owls)).

The owl-selector can actually be quite elegant, but becomes a burden if you have lots of side-by-side blocks (which would always need to set their margin- top to 0).

<comment><USER15> I was suprised the degree to which selector performance is a negligible overhead in normal use these days.

Was browsing through the docs for some Vue+CSS library or another recently, and the author had done quite a lot of research into this, was interesting.

They were heavily using the square bracket html-attribute selector notation, although I'm not sure if it performs better now, or if modern processors are just that much faster.

</comment></comment></comment><comment><USER16> This is great.

I would prefer that browser compatability is mentioned, for my own purposes that would be IE11.

Perhaps set a baseline of what browsers are considered in the intro and then highlight deviance as it occurs.

<comment><USER17> Suzy grids 2 is an amazing tool for ie11 and everything above it. So I can use one codebase for everything.

Yes, it is float based but my code is at the correct level of abstraction.

</comment></comment><comment><USER4> To me this way to CSS development is outdated. I will never program like this anymore. I only do functional/utilitarian CSS.

<comment><USER18> NOTE: I think this refers to the approach implemented by libraries like:

* [https://tailwindcss.com/](https://tailwindcss.com/)

* [http://tachyons.io/](http://tachyons.io/)

<comment><USER4> Also: * [http://minid.net/2019/04/07/the-css-utilitarian- methodology/](http://minid.net/2019/04/07/the-css-utilitarian-methodology/) * [https://github.com/meerita/utilcss](https://github.com/meerita/utilcss)

</comment></comment></comment><comment><USER19> Having been doing full-stack for over 15 years now, I have never seen the owl selector before. It's almost a perfect solution to a problem I regularly have.

A quick google didn't reveal any browser support for it though. Anyone got a resource for that? I can see that the adjacent selector is supported on 98% of global browsers, but I would not be surprised if there were some issues combining it with * + _

<comment><USER20> It's worth noting that * is incredibly inefficient, especially near the front of your selector, because of how the browsers generally handle element styling. It may be better now than in the past, but it's best to avoid it for the most part.

</comment></comment><comment><USER21> The knowledge contained in the articles is very good but I got the feeling that it was written for an audience that already undertands the problems being solved. The Stack for instance is written in a language that only really makes sense if you've spent a lot of time with CSS and contains some extraneous paragraphs. I only mention this as the problems and solutions being explored are very valuable to learn but I think it could be written simpler and more succinctly so that meaning isn't lost for new-comers.

I'd be happy to contribute if it was open to suggestions.

<comment><USER16> Bear in mind the tutorial is prefixed "Relearn..."

Though I'd class myself as a "full stack developer" css for a long time was the 2nd class citizen, with most of my time spent on learning to use front end frameworks in their idiomatic way, the "it depends" peculiarities of SQL and RDBMSs and making inroads on the vast tomb that represents architectuliary sound back ends.

So an article focussed on improving my "it's only css but it works" knowledge is one of the best things I've seen on HN in quite some time :)

<comment><USER22> A good full stack developer should have double the salary of a frontend/backend developer. Do you find this is the case? You need to be an expert at both roles plus have a third skill connecting them together.

<comment><USER16> I think there's often a leeway given to the full stack dev that they have strengths and limitations. I haven't got to the point where I could compete with the true / good front end dev with my skills.

Even at the backend you have the application backend (c# or whatever) and then sql/rdbms. If you are that good perhaps you deserve thrice the pay by this logic ;).

Jokes aside, at the last good company I worked for where I knew other people's pay, I was compensated for the entirety of my skills compared to the good front end dev. We earned the same, and I was quite happy with that.

Jack of all trades...

<comment><USER22> I've been a backend developer for years and at times a frontend developer.

I've applied to a few full stack positions and the amount of specific knowledge in various topics they require seems much greater than either role separately.

<comment><USER23> When hiring or interviewing we tend to build up a big list of skills so the job looks impressive and attracts talent. Don't take the requirements too seriously.

Ideally the person doing the hiring is just measuring your knowledge. But I know many interviewers just try to eliminate candidates.

</comment></comment></comment></comment></comment></comment><comment><USER24> This website is one of the accessiblest things (for screen readers) out there. I have never seen alt text for layout images. This is well beyond amazing.

</comment><comment><USER25> Uh huh, what about "the vertically centered div" and the ever important "span vertically centered within the parent"

</comment><comment><USER26> There is more than way to do all of these layouts. I don't have time to learn all of them, I just want my content to look great on all devices. I also want to stick to the specifications of HTML as it applies to all the browsers that do HTML5 - so no Internet Explorer. Sticking to the specs means no hacks and the likelihood that someone can make sense of my code in ten years time and not think 'why did they do this?'.

For this reason I will be sticking with CSS Grid. CSS Grid is supported in all HTML5 browsers, so that means everything except the depreciated Internet Explorer.

To get my CSS Grid versions to work I will also be using CSS Variables defined in media queries to make things responsive. I don't need to have lots of fixed breakpoints as I use fonts that scale in such a way that lines don't get too long to read on really big screens.

For the CSS variables I have fallbacks which are the desktop defaults. So although 'mobile first' I can get a deluxe mobile experience but code for desktop in the first instance.

With pseudo classes I can add icons, usually Unicode symbols or SVG, SVG defined in CSS variables.

Since I can do this with CSS Grid and only have Internet Explorer be 'of concern', I can write HTML5 with no superfluous markup. That means no div, span or even class attributes. I have got out of the mindset of using container wrappers for content and just putting neat content where it needs to go using CSS Grid.

You could look at my HTML and think I had just swapped the div for article, aside and section. Or for figure. Or for main, header and footer. But that is not the case, I find that if I am using the right elements and pay attention to the structure of my content it just naturally styles itself with CSS Grid, no additional markup needed.

Also not needed are clever things with calc. If I find myself doing that then it is a sign that I have got it wrong and that there is a simpler solution I have overlooked. I also rarely use pixels. It is ems or viewer units all the way, again no need to think of what a pixel actually is.

I find that writing HTML and styling it without the hacks makes my code pretty alien compared to how the rest of the world is doing it. Anyone can make stuff complicated for reasons of backward compatibility, keeping it concise and simple is a different craft.

For the above reasons I am disappointed by these layout modules, a lot of work has gone into it but at times we need to question what we take for granted. Everything is a div. I look at the examples and see that if, e.g., the image is put in a figure and given a figcaption then the structure is there for it to effortlessly be given layout with CSS Grid, no container elements needed.

At some stage we need to stop looking at content as placeholder examples and stop using generic containers.

<comment><USER27> > if I am using the right elements and pay attention to the structure of my > content it just naturally styles itself with CSS Grid

Why is that? Does Grid treat 'article'and 'section' differently than it treats plain 'div'?

I thought that the purpose of 'article' etc. was purely semantic, saying something about the meaning and purpose of content inside them, not how they should be laid out on the page.

<comment><USER26> What I have learned just from having a go is that document outlines matter too, so I just think of whatever I am writing in terms of sections, articles and asides. I don't actually ever think of adding a 'div', there is just no actual use case for them.

Typically with a 'section' the first line inside it for me is a heading. So on the outline there are no 'unnamed sections'. Save with 'nav' and other content blocks, I usually find that there does need to be a heading in there anyway.

So Grid does not care what the elements are, however, that form fieldset won't work in CSS Grid and there may be a couple of other edge cases. Now here is the important thing to know - have too many nested divs and it makes CSS Grid very difficult, almost pointless.

So, imagine a form. You can have just label followed by input, label followed by input with some submit button at the end. This can be put into CSS grid and styled beautifully with no effort. It goes responsive effortlessly as well. There is nothing to it.

But then, in real life you are working with some legacy code where there are divs around each form element and divs grouping the labels and the inputs and an outer wrapper with spans around the required field asterisks, everything with class attributes on it.

It is hard to imagine if you are used to that type of markup that you don't need any of it!

But that is the case. You can write ultra lean HTML.

Then when it comes to actual content, e.g. a blog article, you realise that the WYSIWYG paradigm is doing us no favours. It has no structure even if it looks okay.

So I use the article and section elements to just get my writing neatly organised, with headings at the top of each. This is more about just writing content neatly than presentation.

The div makes sense if you are copying stuff from old tutorials, but it never makes sense with content, but it sneaks in there. It is so baked in with things like the Wordpress Gutenberg blocks thing where some people have staked the whole company on new ways of writing out of spec bad HTML. If you check the manual you will see it is the element of last resort and just isn't needed with CSS Grid layout.

Before CSS Grid layout you did need the div to make wrappers for centering stuff. But now you don't. But people have got so used to using it that it has got stuck in the mindset, a groupthink that will look silly in a decade or so.

I also style the elements, never needing classes. But with no div wrappers these are all sensible looking to me but would horrify someone doing BEM notation. Here is an example that gives you an idea...

        body > footer > nav > ul {
          display: grid;
          grid-auto-flow: var(--footer-nav-ul-auto-flow, column);
          grid-gap: .25em;
          justify-items: var(--footer-nav-ul-justify-items, left);
          padding: 0;
        }

So that is for some responsive footer links, they go across the page on desktop and the other way on a small screen. Best practice would say that I add 'footer-links' as a class to the footer links. Best practice says the 'body > footer > nav > ul' selector is 'too complicated' as it uses four rather than three (max) selectors. But that is how I like to read my CSS these days, with no preprocessor, no compiling, just spelt out.

Now this example is not a portable component but that is the point, the document structure is relatively flat and quite predictable.

<comment><USER7> If seems like you discount portability as a concern, and if that's appropriate for your use case, that's a fair decision of course. But there are many use cases for which that's a priority.

The concern the BEM and component-based CSS approaches aim to address is the composition of arbitrary chunks of DOM without implicit side effects. By having chunks of DOM explicitly opt in via classes to being styled in a given way, they never accidentally receive styles they weren't meant to, and they're fully portable to arbitrary contexts.

In something like an web application as opposed to a document-oriented website, the ability to compose components and avoid quirks of things that randomly break or look different inside other things is beneficial. Using a component in a new place shouldn't (in the application development context) require adding new selectors for it because it's not "where" your selectors expected it to be.

<comment><USER26> When it comes to portability I find that a class for the component is all that is needed. So that is at the root element of the component and with everything inside classless. So '.component > nav > ul' might be how I would style navigation inside the component, knowing it would not inherit styles from the body defined classes for header/footer navigation.

The BEM type of examples you will normally see will have everything as a div, I just avoid div elements not out of some prejudice against them but because I am out of the mindset to think to use them.

A lot of what I am saying here does fall apart on over complicated commercial projects though where the CSS is 'add to' and you can't just strip everything out to do it stupidly simplified.

I am also not a fan of monolith stylesheets with resets and frameworks adding thousands of lines of CSS. The idea that you should need 30000 lines of CSS for a product page is just silly, but even some of the best websites are doing that sort of thing.

In one of my pet projects that I am not quite happy with yet (wording could be better), I create a lot of content from JSON data using templates done as 'template' the element. The approach of using simple selectors works well when it comes to taking a template, changing elements within it such as the title and adding rows of data to it. I have struggled with over complex toolkits that create stuff, e.g. the Wordpress Gutenberg editor, but I find vanilla javascript (no compiling) with full feature HTML5 (all the elements) and the compound selectors work great. At one level the rest of the world is way ahead of me on these mega complex build tools but then I wonder if they are really needed.

Anyway back to it!

</comment></comment></comment></comment></comment><comment><USER28> "Web browsers helpfully apply default CSS styles..." Totally disagree with the idea that this is 'helpful.' Pretty site though. I think there's some good stuff here - but it's not how I'd teach it. Side-note: I love how wappalyzer says 'zero technologies detected.' That's rad. "Each layout in Every Layout is intrinsically responsive." Everything is intrinsically responsive before you force it not to be. Big respect for tackling this though. Lots of good stuff and just a bit of maybe not great stuff.

</comment><comment><USER29> What's the best resource (book, videos etc.,) to learn css these days?

<comment><USER30> Hey once you're past the fundamentals check these two cool games out. They teach how to quickly grasp the most difficult parts of CSS - the layout.

[https://flexboxfroggy.com/](https://flexboxfroggy.com/) [https://codepip.com/games/grid-garden/](https://codepip.com/games/grid- garden/)

I wish all learning was this fun.

<comment><USER31> Wow, that grid-garden game is great.

</comment></comment></comment><comment><USER32> I'm not sure if the creators will read this, but on [https://every- layout.dev/rudiments/axioms/](https://every-layout.dev/rudiments/axioms/)

> At the time of conceiving the axiom, you make not have pictured this > specific visual effect.

I'm pretty sure it should be "may" instead of "make".

</comment><comment><USER33> >[https://every-layout.dev/layouts/cluster/](https://every- layout.dev/layouts/cluster/)

>The Cluster layout is available in the full version of Every Layout, which is still in production. All of the currently available layouts are marked "read now" in the index page.

where is production? I can't find it

<comment><USER34> It's _still in production_ meaning: they are not available yet, they are being written.

<comment><USER27> Another way of saying that would be that they are still in "development"

</comment></comment></comment><comment><USER35> Poor quality articles. They use flexbox and provide no fallback for older browsers. They could use at least non-responsive layout for desktop resolution for older browsers. Probably the reason why they didn't do it is lack of knowledge of CSS.

<comment><USER36> Flexbox has been supported by all browsers for years now, even by IE11. What on earth do you need to support if you cannot use flexbox?

<comment><USER35> Caniuse says that IE11 has a lot of bugs regarding flexbox. Firefox supports flexbox only since 2013-2014. So it would make sense to add a simple non- responsive fallback for older browsers.

Also, if I remember correctly, the default browser in Windows 7 is IE9. It makes sense to support default browser in the most popular desktop OS.

Some of older browsers, released in 2012-2014 support flexbox only with vendor prefixes, but the article doesn't has rules with prefix. As frontend devs tend to copy the code without much thinking, we cannot expect that they will add the prefixes or fallback code themselves. So it will be author's responsibility for web sites being less accessible in different browsers.

<comment><USER37> caniuse.com also has the combined global market share of IE 6-10 as being only 0.46%, which is completely insignificant for most websites. And I've personally been using flexbox on IE 11 for years with very few issues.

> Some of older browsers, released in 2012-2014 support flexbox only with > vendor prefixes

Again, these browsers represent a tiny fraction of the total market. Firefox and Chrome auto-update by default, so there is no reason that someone should be on a version from 2012.

These days it simply doesn't make sense to have a fallback for flexbox unless you're specifically targeting older versions of IE. (And even then, I've had some luck getting flexbox layouts to work on IE 10, even though it's more effort.)

<comment><USER38> Global market share stats are applicable for global target websites. Consider any medical equipment company for example - their clients will browse the catalog from archaic, unmaintained PCs they have laying around.

Always get data about browser market share from your client if they have it, otherwise you're simply in for an uncomfortable surprise one stats start coming in.

</comment></comment></comment></comment></comment><comment><USER35> The code examples are overengineered. For example, the code generator for stack uses rem units and CSS variables, while it could be written without them and have better cross browser support (and the code would be easier to read and maintain in long-term perspective). The author just wants to use modern CSS features without clear rationale for this.

Rem units can cause issues in long term. For example, imagine if a sidebar widget is coded using rems. When later the main font size is changed, margins within widget will change its size, although the font size in it is fixed and didn't change. There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it. He just uses his authority to push his personal preferences to frontend developers who tend to copy the code from tutorials without much thinking.

I recommend using pixels for projects that are going to be maintained and developed in the long term.

<comment><USER39> Rem is great. It allows uniform scaling of all UI elements under a parent along with them font size.

<comment><USER35> Where is this used? If a user wants to make everything larger then they can use zoom in a browser that works with any units (except for vx, vh, vmin, vmax that break zoom).

<comment><USER39> Designers or developers.</comment></comment></comment></comment>


A timeless Bootstrap theme built for the modern web - <AUTHOR> http://code.divshot.com/geo-bootstrap/ <comment><USER2> I feel I've just been rickrolled but I did enjoy it.

Before this, was grey. Grey was good. I kinda miss ncsa mosaic.

</comment><comment><USER3> Christmas dinner with the family is gonna be _awkward_ this year.

</comment><comment><USER4> This is fun. I love that this exists. Thank you internet :)

</comment><comment><USER5> Hammer-Time.

<comment><USER6> Hammer-Timeless.

</comment></comment><comment><USER7> could this work as a user-style?</comment>


Ask HN: Honing programming skills in a "Blue box" - <AUTHOR>

After reading several good reviews of the book "Talent Code" (among others, the review on Derek Sivers' blog) I decided to give the book a shot. One thing that intrigued me was the information that supposedly, Brazilian soccer players practice futsal (a game similar to soccer, with a smaller field, fewer players, and a smaller, heavier ball) as this game "compresses soccer's essential skills into a small box" and  allows the players to improve their soccer skills faster compared with practicing soccer.
The book also mentions the "Blue box" (http://en.wikipedia.org/wiki/Link_Trainer) as a practice device of similar nature for piloting airplanes.
So the question is obvious, is there something similar for programming? The only thing I can think of are competitions such as Project Euler but I somehow feel that these are not exactly "Blue boxes". <comment><USER2> This is a really great question, but I can't really see a corollary in programming. Software is a much wider field than soccer. Contest problems could be similar, or running through a textbook like How To Design Programs. In reality, the best thing is probably to find some smaller projects with reasonable constraints on a simple platform, that way you can build software without spending a lot of time dealing with infrastructure concerns, and just focus on architecture, algorithms, etc.

<comment><USER3> This is probably the best thing to do. If you can reduce the problem to a single, limited domain, you can focus your energy on just that one. As you feel more confortable, you can introduce others. Even in general I think it's a good idea to split things up and tackle them individually.</comment></comment>


Ask HN: Free calorie count API? - <AUTHOR>

Does anyone know of any open APIs for retrieving calorie details about various types of food? <comment><USER2> Not an API, but a public data set:

<http://www.ars.usda.gov/Services/docs.htm?docid=8964>

</comment><comment><USER3> I haven't used it but had the Fat Secret site bookmarked for a while. They have an API here: <http://platform.fatsecret.com/> Let us know how it looks once you try it.</comment>


Hospitals Stand to Lose Billions Under 'Medicare for All' - <AUTHOR> https://www.nytimes.com/2019/04/21/health/medicare-for-all-hospitals.html <comment><USER2> >> _One hospital would get about $4,200 from Medicare for removing someone's gallbladder. The same hospital would get $7,400 from commercial insurers._

That's roughly double. Now, are Medicare lower because private insurance subsidizes them or hospitals can actually make it happen (survive) with half price billing?

<comment><USER3> A hospital wants to keep its facility 100% busy, because facilities have a fixed-cost component. Like an airline that offers cheaper seats to some travelers to fill the plane.

<comment><USER2> OK, but:

Medicare spending: $705.9 billion in 2017

Medicaid spending: $581.9 billion

Private health insurance spending: $1,183.9 billion

Out of pocket: $365.5 billion

[https://www.cms.gov/research-statistics-data-and- systems/sta...](https://www.cms.gov/research-statistics-data-and- systems/statistics-trends-and-reports/nationalhealthexpenddata/nhe-fact- sheet.html) as you see Medicare+Medicaid make a nice chunk of health care spending. Airlines lower prices as a last minute resort, they'd go bankrupt if half (or a nice %) of seats were to be sold at half price.

<comment><USER3> Hm. Airlines _raise_ the prices at the last minute. They estimate how many seats will go unfilled and offer cheap seats first/early.</comment></comment></comment></comment>


In-Memory Computing at Scale: When to Choose and How to Effectively Use JEMalloc - <AUTHOR> http://highscalability.com/blog/2015/3/17/in-memory-computing-at-aerospike-scale-when-to-choose-and-ho.html <comment><USER2> The main issues it was able to solve for Aerospike were critical. It added debugging capabilities that allowed telling the difference between a memory leak vs. memory fragmentation (which can seem the same to an untrained eye). It mitigated and minimized fragmentation to a great degree, allowing better RAM utilization. It also allowed Aerospike to get the most out of multi-CPU, multi-core, multithreaded system performance.

<comment><USER3> This paper was a good read. I recently have done some work using libhugetlbfs to use huge pages for an application and you might want to consider using an Arena backed by huge pages. For very large structures TLB misses can really add up, and huge pages can improve performance by a large margin for workloads where lots of large buffers are being accessed and scanned. If tests suggest that you should go this route on your workload, I would suggest managing the pages using libhugetlbfs directly instead of transparent huge pages.

<comment><USER4> Thanks for the comments! I'll check out "libhugetblfs".

On the CentOS 6.4 / Linux 2.6.32-358.11.1 kernel systems described in the paper, Transparent Huge Pages were enabled, and according to all my investigations, THP was working automatically and effectively as expected.

Specifically, correlating the "AnonHugePages" numbers between "/proc/meminfo" (system-wide) and "/proc/<PID>/smaps" (for the Aerospike database daemon), showed substantial amounts of the process VM was in huge pages, and the page table space ("VmPTE" in "/proc/<PID>/status") was not excessive.

Do you have a compelling use-case / metrics for manually controlling huge pages vs. simply relying on THP managed by the kernel?

</comment></comment></comment><comment><USER5> This is a good overview of the different mallocs available today, and why one may care.</comment>


TypeScript 3.6 - <AUTHOR> https://devblogs.microsoft.com/typescript/announcing-typescript-3-6/ <comment><USER2> I've been using Typescript for the past year and it's definitely one of the best typing systems I've used (Rust might be up there too - once I've conquered the battle of the borrow checker). The way it handles nullable references and understands code to ensure I'm using values correctly, and the editor integration. Microsoft, I'm impressed!

Yes it takes me "slightly" longer to write code initially, but that time is recouped almost straight away by the intellisense suggestions, refactoring, and code checking. My code often "just works" the first or second time.

Therefore after using Typescript for a couple of projects, I was excited to start adding type hints into our backend Python code, but I was quite disappointed by the value that they added. Perhaps I'd just become spoilt by Typescript.

<comment><USER3> Yes, Python's type system is nowhere near Typescript, and are closer to docblock annotations.

<comment><USER4> How? How it's not close to typescript? I mean what are features that python's type annotation (and mypy) lacks in comparison to typescript?

<comment><USER5> Was battling it today. Latest stable release of python mind you 3.7.3. We have to move structured data around from a legacy system and integrate it with our new website. Perfect opertunity for types. This also includes trying to use mypy.

      * it doesn't track the state of the variable. If I get a value thats Optional[int] there is no way to say 'if a is not None:' it will still complain that the variable could be none
     * even with the mypy experimental TypedDict they're basically unusable IMO
     * there is no 'keyof'

* there is no way to constrain to specific strings (or other primitives). I don't understand what literals are supposed to be but they aren't useful for us

Coming from typescript it's been very lackluster.

<comment><USER6> I agree that mypy can be a bit lacking, but to address a couple of your mypy woes:

\- TypedDict is an option but if you can, dataclasses work much better

\- mypy does refine Optional[T] to T with an if check. Maybe you need to futz with the compiler options?

\- Does Literal["foo"] not work? I've been using it with pydantic for de- serializing a tagged union of dicts and also for function args.

e.g.,

        def call_to_service(api_type: Literal["users", "teams", "orgs") -> None: ...

<comment><USER5> The problem I had with Literal["foo"] is that at least according to mypy "foo" is a string and it was expecting Literal["foo"].

I think you're right, something must be mixed up. But then again this is the latest version of python and mypy, on intellij, so I'm not sure what I did wrong, it's using otherwise default options.

</comment></comment></comment></comment></comment></comment><comment><USER7> Typescript has massively improved my quality of life working on JS projects. I occasionally run into constructs that are difficult to type but most of the time TS just works. Thanks to all the people behind this project for all your work!

<comment><USER8>
        interface IntMap {
          [name: string]: int
        }

        interface StringMap {
          [name: string]: string
        }

I really feel something like that should come standard so I didn't have to rewrite it so many times when coding in the wild.

<comment><USER9> These are:

        type IntMap = Record<string, int>;

        type StringMap = Record<string, string>;

</comment></comment></comment><comment><USER10> I feel like I'm the only one, but I don't care for Typescript.

After working with it for a while, the type checker ends up being painful to work with. I'm using React, and it's difficult to write higher order components that are correctly typed. Additionally, probably related, styled components often get messed up with the type system.

<comment><USER11> Personally I prefer to not use typescript on react (I don't have any experience on it and it seems like a hassle). I use it on mobx / redux instead.

However it's a godsend for nodejs.

<comment><USER12> It's not really a hassle at all and adds great value with compile time checking of proptypes etc. Give it a go. If you use MobX especially you should find it really quite straightforward - I'm not sure what typing Redux is like these days, didn't used to be much fun but I've not used Redux for about 3 years

</comment></comment></comment><comment><USER13> TypeScript is such a fundamental milestone in the web and javascript community. (coming from Microsoft too!) I really do hope front end communities converge on typescript in an idiomatic manner.

<comment><USER14> There are many nice modern languages that compile to JavaScript. Personally, I like [Haxe]([https://haxe.org/](https://haxe.org/)), which compiles to many other target platforms/languages as well.

Here's a [comparison of Haxe and TypeScript]([https://blog.onthewings.net/2015/08/05/typescript-vs- haxe/](https://blog.onthewings.net/2015/08/05/typescript-vs-haxe/)).

<comment><USER15> I'm all for more new and innovative languages, but I think the key thing about TypeScript is not that it compiles to JavaScript, but (to quote basarat's great free book[1]) that "TypeScript is just JavaScript with docs".

TypeScript is a strict superset of JavaScript, so all our real-world JavaScript _is_ TypeScript already — you can literally just change the file extension from .js to .ts.

Now, our existing JS code probably isn't _great_ TypeScript, since it doesn't leverage those great machine-and-human-readable docs (the type system).

So, compared to code written from the beginning with TypeScript, our existing code doesn't go as far toward reducing the likelihood that we humans miss something while programming, and introduce a bug. And we probably won't get all the automated assistance that we could be getting from our machines, in terms of auto-complete, as-you-type errors and warnings, automatic imports, etc.

But for projects coming from JavaScript, it's hard to overstate the importance of being able to start from a place where all your existing code works like it always has, and you can choose the right mix of when/if to upgrade your legacy JavaScript code to TypeScript.

I think that design decision is probably the key to TypeScript's explosive adoption and popularity. A lot of languages could give you strong typing, and the increased code correctness and massively improved tooling that comes along with that — but I don't know of any others that literally require no code changes to start adopting them.

Of course, the choice to remain a superset of JavaScript does place some significant limitations on what kinds of cool improvements TypeScript can add. It can't break JavaScript code so lots of cool things one might imagine won't be possible. Still, a great tradeoff IMO.

[1]: [https://github.com/basarat/typescript- book](https://github.com/basarat/typescript-book)

<comment><USER16> _> TypeScript is a strict superset of JavaScript_

I had the impression this has been debunked already.

[http://blog.jonasbandi.net/2016/10/myth-of- superset.html](http://blog.jonasbandi.net/2016/10/myth-of-superset.html)

<comment><USER15> My own understanding is that a few persons have made comments or blog posts along the line of, "Look at this convoluted edge case I created of valid JavaScript that isn't valid TypesScript! Ha! Gotcha!"

There may be some cases like that (though I've never seen one in the real world, since I started working with TypeScript three years ago). And there have been and will be more bugs in TypeScript and its compiler, etc.

Such claims might be true in some pedantic sense, but aren't really meaningful unless you are in some kind of internet flame-war thread on Reddit or something.

In the real world, for the purposes of writing software, Microsoft's claim[1] that "TypeScript is a typed superset of JavaScript" is generally true.

[1]: [https://www.typescriptlang.org](https://www.typescriptlang.org)

EDIT: Maybe I shouldn't have said "strict" superset. That might have just been me accidentally editorializing.

EDIT 2: After reading the post you linked, and its (good) comment thread, I understand where he was coming from, but as he notes in his update at the top, it mainly boils down to different interpretations of what "superset" means in this case. I think in the end his assessment is the same as mine above.

</comment></comment></comment></comment></comment><comment><USER17> Nothing has improved my day-to-day work life more in the last 5 years than typescript.

It's joy. Just, joy.

</comment><comment><USER18> I've noticed there's a lot of talk on twitter about making TypeScript be an agreed upon best practice for frontend web developers. I'm glad TypeScript is doing well because there are certainly a lot of talented and dedicated developers working on it, but I really don't want to use static typing, even if there is a lot of type inference happening. I will need to make sure I don't plan on finding job or gig opportunities at the types of companies that are going require the use of TypeScript.

<comment><USER19> Do you believe static typing is harmful (to the type of company you want to join), or is this a personal preference (which is totally valid)? Honestly curious.

<comment><USER20> I am starting to wonder if the preference static vs dynamic is some kind of character trait like introvert vs extrovert. I personally prefer static typing and use it to my advantage during development but I know very smart people who hate static typing and think it impedes them. Both sides have valid arguments but seem to prioritize things differently.

However I think it's important to have used both for a while so you can make a good decision what you prefer.

<comment><USER21> I think it depends a lot on previous experience, what type of thing you are developing, and your tooling. I'm very comfortable and happy bouncing between C# in Unity, React and JS, and Haskell for more CS / intellectual curiosities. For me it's more about fit and choosing the right tool for the job.

All things being equal I prefer something like Haskell because it is very clean and expressive. But I hate excessive types when you are dealing with generics 3 level deep or when you have these funky type signatures dealing with monad transformers. It's just too many layers of abstraction that takes you away from the actual data / parameters.

When I'm writing something small I find typing slows me down. But when writing something bigger, working in a team, or working on a codebase for a longer period of time the typing acts as documentation. Typing something and having Intellisense tell you what is in a class is extremely helpful. Otherwise you have to jump to the file or look through documentation.

For me it's less about the errors it catches and more about the time saving of not having to read through code that I am calling in order to understand what I need to pass to it.

In general. strong typing is great when you are working with other people's code and 3rd party libraries, but excessive overhead when you just want to experiment and crank out something small.

<comment><USER22> Fwiw we have a relatively large Scala codebase that's exceptionally bug-free, performant.and easy to modify and haven't had to reach for a lot of the extremely abstract FP patterns that warrant the most blog posts. Simple immutability, garden variety monads (IO, Either, Option) get you a long way and are simple to understand.

</comment></comment></comment></comment></comment><comment><USER23> I was really hoping optional chaining would be in, but turns out that's scheduled for the next minor release, 3.7.

The generator improvements are appreciated, though I wish it went even further and supported uses like redux-saga better (so the return type of a yield expression could depend on the type of the value that was yielded).

<comment><USER15> Oh, it's good to hear that feature is coming in 3.7! That's something I really miss on a regular basis.

Where did you learn it's scheduled for 3.7?

<comment><USER24> [https://github.com/microsoft/TypeScript/issues/16#issuecomme...](https://github.com/microsoft/TypeScript/issues/16#issuecomment-515160784)

</comment></comment></comment><comment><USER25> I know typescript is really popular around here. And I do like it for autocompletion and refactoring. But am I the only one who thinks typescript makes code unreadable? It looks so messy. I can understand a piece of normal js way faster than the same code with types. Don't have this problem with, for example, java. Maybe it's the syntax with the colons or the fact that I'm used to types appearing before the name instead of after...

<comment><USER26> I applaud Microsoft for popularizing gradual typing , bringing types to the js world is an enormous task, both technical and (js-)societal.

Regarding your syntax criticism: I quite agree. I really really like the path chosen by Haskell. Types are obviously a major part of Haskell, but there you just separate the type signature from the implementation.

      emap :: (DynGraph gr) => (b -> c) -> gr a b -> gr a c
      emap f = gmap (\(p,v,l,s)->(map1 f p,v,l,map1 f s))
        where
          map1 g = map (first g)

(Of course there are other helping things like type synonyms, which TS also supports)

      type UPath   = [UNode]

<comment><USER27> There are a lot of languages where even if you don't know that language, you can figure out what's happening. I have no idea what your example is supposed to do.

<comment><USER28> That's because it's taken from a library that deals with graphs[1]. I had to look it up, because I had no idea what it does either and I know Haskell. Here's a better example of what he meant in Elm, a language that looks a lot like Haskell: [https://github.com/bryanjenningz/25-elm- examples/blob/master...](https://github.com/bryanjenningz/25-elm- examples/blob/master/18-editable-todos.elm)

[1]: [http://hackage.haskell.org/package/fgl-18.104.22.168/docs/Data- Gra...](http://hackage.haskell.org/package/fgl-22.214.171.124/docs/Data-Graph- Inductive-Graph.html)

</comment></comment></comment></comment><comment><USER29> Is anyone else using javascript + jsdoc + .d.ts files, and using typescript as a kind of linter?

I'm really enjoying this setup, I get to use tools that work on JS source code without sticking them in a build typeline. I find it easier to read as well - the function declarations are nice and short as all the type annotations are in a comment above. Also one less transpilation step.

<comment><USER30> I do this extensively with Flow comment syntax at work and it's great. I tried it w/ Typescript on a side project recently, but I found it to be a bit limited (e.g. @callback doesn't play well with RORO pattern) and the syntax is a bit clunky.

But having runnable code without a build step is definitely a very big plus for me.

<comment><USER29> I never use the callback tag, I tend to just do:

      /** @param {(x: X) => Y} f */

Works fine. If you can let me know a RORO pattern you had trouble typing I might be able to help.

<comment><USER30> The problem with @param is that it requires a binding name

I ended up doing this instead:

        /**
        @typedef {{x: string}} FooArgs
        @typedef {{y: string}} FooResult
        @type {function(FooArgs): FooResult}
        */
        export const foo = ({x}) => ({y: x});

It works, but the double curly feels a bit clunky. Compare to Flow:

        /*::
        type FooArgs = {x: string};
        type FooResult = {y: string};
        type Foo = (FooArgs) => FooResult;
        */
        export const foo /*: Foo */ = ({x}) => ({y: x});

In Flow, the declaration ends up looking essentially the same between comment syntax and non-comment syntax.

With TS, RORO ends up looking like Flow (but with weirder indentation on large enough structs), whereas I'd prefer to express regular functions in terms of @callback, @param and @returns since that's more in line w/ the spirit of jsdoc. Not a huge deal, in any case, considering the upsides of comment syntax.

<comment><USER29> index.d.ts:

        type FooArgs = {x: string}
        type FooResult = {y: string}
        type Foo = (_: FooArgs) => FooResult

index.js:

        /// <reference path="index.d.ts"/>
        /** @type {Foo} */
        export const foo = ({x}) => ({y: x})

Works as well

<comment><USER30> Good point!

</comment></comment></comment></comment></comment></comment><comment><USER31> I think I got off to a bad start with Typescript. Decided to add it to on the frontend of a bog standard Vue + Vuex erp app.

Its in quite a bad state with regard to how you have to structure the code to ensure Typescript doesn't throw linting errors (and even then I found the intellisense gained was not much more powerful than what my IDE already provides).

My conclusion has been that TypeScript maybe great for extremely large frontend apps, where you want to do a lot of data wrangling on the client itself (with defined Entities etc...).

Kind of a shame really since I'm using .NET core on the backend and loving it

<comment><USER32> > Its in quite a bad state with regard to how you have to structure the code > to ensure Typescript doesn't throw linting errors (and even then I found the > intellisense gained was not much more powerful than what my IDE already > provides).

Can you expand on this?

I currently write my apps in .net core/Vue/Typescript and use the same stack for small or large so I might be able to assist

</comment></comment><comment><USER33> While I think that TS offers probably the best type system out ther, eg way better than Go's, I'd love to see a more balanced view on TS in discussion threads like this one.

TS is a must for long-term code which should be maintainable in several years by teams. Any lead engineer with responsibility for some crucial app and dev team not using TS is doing something wrong. But using TS comes at a cost. Even when you are savvy in TS you won't bang out code like with pure JS.

But especially in prototyping phases you need this fast-paced coding. And using TS or any type system slows you down, even when you are familiar with typed languages. Often your final code faced many iterations and I sometimes like to introduce TS later, usually at a point where I just need types but not always and as default from the first key press. In early stages I still try to test ideas, algorithms and their general feasibility and a fast 'mind-to-code' interface is crucial and types would stay in the way then.

Further, finding the right type can take some time, just google what type a React's children prop should be and find long discussions. Welcome to the TS- what-type-is-actually-xy-rabbit-hole. And declaring everything as any shouldn't be the answer.

A big drawback are also TS error messages which are super hard to grasp. You get there and you even find tutorials just for understanding TS error messages but it's unecessarily infuriating.

Moreover, VSCode, its TS language server are amazing pieces of tech but here you face also strange behaviours. Types get full Intellisense support while interfaces don't which doesn't make sense. So you need still to go the definition yourself and it's not that IDE-like feeling you hoped for or people told you.

In my setups, I use TS instead of Babel but use both JS and TS files in one code base depending on the requirements and situation.

So, my message is, yes TS is great, has probably the best type system but the tonality by its community/users needs to be much more balanced and less fanboy-ish. I just can't take devs serious who praise TS to death. This is just not true. More, maintainable code is also not just created by a type system but also sane architectures (eg React) and many other factors. Types won't make bad code maintainable. So, types have their place but not everything in TS-land is shiny.

<comment><USER34> I wouldn't exactly call what TypeScript has the best type system out there. It's deliberately unsound, doesn't enforce full static type-checking, _and_ doesn't provide for runtime checks (there are third-party libraries, but if you're bringing up third parties one might as well argue that JavaScript has a great type system because TypeScript exists).

A lot of it is due to the project's overwhelming priority being as easy to interop with JS as possible, but I've found that quite a few of TypeScript's fancier features are sugar that's entirely up to the developer to enforce.

<comment><USER33> Disagree. TS' type system is fully featured compared to others and what you described as an disadvantage is actually an advantage or TS' killer feature: you can gradually convert a dynamic code base into a static one where needed. IDK of any other language that allows this.

<comment><USER34> Fully featured compared to what, exactly? If you say Java I might just have to laugh.

Obviously the compatibility with JS is TypeScript's "killer feature", but it's a killer feature that has very explicit costs you're ignoring for some reason. You cannot have a truly excellent type system while trying to maintain the level of compatibility with a dynamic, weakly typed language that TypeScript does, something that the language team acknowledges themselves[0]. I don't quite see how one can call a deliberately unsound type system "the best".

0: [https://www.typescriptlang.org/docs/handbook/type- compatibil...](https://www.typescriptlang.org/docs/handbook/type- compatibility.html)

<comment><USER33> Not going to discuss this further. You have a dogmatic view on what is an excellent type system.

</comment></comment></comment></comment></comment><comment><USER35> Typescript only solves one of Javascript's two main problems. What really makes JS an abysmal experience is it's lack of a standard library. Compile-to- JS languages are in a unique position to solve this problem so I urge Microsoft to focus on a curated set of reliable libraries which can constitute a stdlib for JS. There are plenty out there already so it shouldn't be difficult.

<comment><USER36> I feel like lodash and date-fns is like 80% of what I want out of a standard library. I mostly use the built-in fetch but Axios is nice too.

I also tend to use js-cookie and uri.js because the browser has horrible APIs for working with cookies and urls.

</comment></comment><comment><USER37> JS was designed to be dynamically typed, just as Python and others, it is at the root of those languages. I can totally imagine that with all the big web apps of today type safety is a thing for some people working in large code bases. But that doesn't mean all dynamically typed languages need to perish.

Why not create a beautiful statically typed language from scratch that compiles to WebAssembly? Why do we have to introduce a type system on top of an old and flawed language? I mean, maybe you'll get some type safety with TS, although it won't be 100%, but what about the future? How long will this toy technology stay?

For me, this is so typical for the JS community, jumping the boat in a whim. And IMHO this creates the famous Javascript fatigue. Learning disposable things. Therefore I moved back to C++ after 6 years of web development, learning things that actually make sense and that I can use for years to come. Not having to work with all those temporary black boxes that are praised by the community.

<comment><USER38> >For me, this is so typical for the JS community, jumping the boat in a whim.

This is Microsoft's product, the company famous for keeping legacy going, hardly the 'JS community'

</comment></comment><comment><USER39> If anyone here has switched from TypeScript to Flow or vice versa, care to comment on how that's been working out? I use flow at work, and I am starting to really love it, but it seems like most people prefer TypeScript to flow.

</comment><comment><USER40> Typescript is only language I came across, where documentation is in release notes, so to learn about feature you have to crawl all of them and there is nowhere else to find it.

</comment><comment><USER41> I love that static typing has come to the Javascript ecosystem and I hope that some of these concepts make their way upstream into future versions of ECMAScript.

</comment><comment><USER42> typescript is the best thing that happened with web development within 2010-2020.

</comment><comment><USER43> Nice to see the TypeScript Playground ([https://typescript- play.js.org](https://typescript-play.js.org)) getting some love.

Makes it easier to see what all options are available in TSC.

<comment><USER44> Frustrating, though, that there's no good repl for TypeScript.

<comment><USER45> I've used ts-node, with pretty good results.

[https://www.npmjs.com/package/ts-node](https://www.npmjs.com/package/ts-node)

<comment><USER43> Ts-Node is great. Startup times are slow though. 30x slower. Example for same script using node vs tsnode: "user 0.11s" "user 0m2.839s".

Am I doing something dumb?

<comment><USER44> Ts-node is honestly pretty terrible. By-default you need to disable some errors that make sense in code but not in a repl. "You just imported this thing but didn't use it yet, ERROR", which means that nobody uses the thing. Granted, I'm pretty spoiled by how excellent ipython is, but clearly no one actually uses ts-node. It doesn't even remember history between sessions, and they have no interest in making that work, even deferring to rlwrap.

<comment><USER43> Interesting. I haven't used it as a repl. Just for running ts scripts directly so I don't have to do a 2 step compile/execute.

</comment></comment></comment></comment></comment></comment><comment><USER46> Nice, finally, there are typed generators. That could possibly enable us to write something like do-notation in Haskell in a type-safe way.

</comment><comment><USER47> TS is probably the best solution to JS problems today. And something like project Deno may even push it one step further.

</comment><comment><USER48> > For those unfamiliar, TypeScript is a

Finally, a release notes that explains what the product is!

</comment><comment><USER49> Disclaimer: I'm currently interning at Microsoft.

Y'know, I can't think of many companies that have as much support for open source programming language development. Between Roslyn, TypeScript, what's left of F#, the Language Server Protocol, Chakra, V8, etc., Microsoft has a veritable powerhouse of compilers and PL development. Google has Go and Dart, but as far as I can tell, the development process is contained in Google mailing lists. Apple has Swift and LLVM and Mozilla has Rust, but each of those footprints isn't as large as the combo of .NET and TypeScript.

I mean, ffs, Richard Stallman is coming to speak at Microsoft. Well, Microsoft Research. But still. Stallman. That's insane.

<comment><USER21> > what's left of F#

Has it been abandoned? What did you mean by this?

<comment><USER50> Plain OCaml is still a better and more powerful language. F# is like a poor relative to it. The only good thing of it is .NET integration. It lacks so many features of OCaml.

<comment><USER51> And OCaml lacks features that F# has. Like proper multicore support, computation expressions, unit of measure, operator overloading.

<comment><USER52> > computation expressions, unit of measure, operator overloading.

We have `let` operators instead.

And F# doesn't have proper overloading, it has an SML-like hack working for built-in types only, and only within a function, as far as I understand. It needs typeclasses for proper overloading. There is an ongoing work on Modular Implicits for proper overloading (and even dependent types in core language), but they are not there yet.</comment></comment></comment></comment></comment>


Nodebox 2 Beta (like Processing, but with Python/Jython) - <AUTHOR> http://beta.nodebox.net/wiki/Welcome

<comment><USER2> It's quit exiting because

1\. Works under Windows now

2\. Runs on the same interop-able platform as Processing.</comment>


Google Wave Now Open to Everyone - <AUTHOR> http://techcrunch.com/2010/05/19/google-wave-open/

<comment><USER2> At the dayjob we have 2 geographically separate teams of about 4 people each working together. We tried to use Wave last year and it was a cluster.

Even if it's improved 10x, you're going to be hard pressed to get anyone from my company to try it again anytime soon.

If you're going to launch early and iterate you've got to try harder to keep the buzz respectable.

Harder for a company like Google, obviously, but with the state Wave was in last year they could have done without the advanced PR push and conference launch.

<comment><USER3> Sure, but they said it was a developer preview. They never suggested you use it for general or work purposes yet.

</comment></comment><comment><AUTHOR> I am a member of a small startup. We use it for all of our brainstorming. So far, it has only improved. We don't even think about using something else.

Maybe we are the exception. But it has helped us an incredible amount.

<comment><USER4> As an initial cut, I'm thinking shared to-do list (with multimedia, wiki, and real-time features) is kick-ass enough to use it.

</comment></comment><comment><USER5> The invite only thing was a really bad idea. If it was meant to be a developer preview it definitely wasn't widely percieved that way. If it was an attempt to build up a following in the way gmail did then it was a total flop. People are bored of invites now.

<comment><USER6> I think it's just a classic network effect problem. Invites worked for gmail because you could still continue to interact with everyone who had an email address.

With Wave, you not only had to be invited, but you could only communicate with the small set of other people who had been invited. I used it exactly once and gave up on it.

</comment></comment><comment><USER7> I still think that Wave was nice as an idea, but that the implementation of it was poor. Unfortunately many people have completely dismissed it due to the slow and buggy user experience, but with more effort put into making a fast and ergonomic UI design it could stage a comeback.

</comment><comment><USER8> Hmm. I'm an Apps Premier customer and I don't see it in the control panel yet...

[http://googleenterprise.blogspot.com/2010/05/google-wave- lab...](http://googleenterprise.blogspot.com/2010/05/google-wave-labs- available-today-to.html)

<comment><AUTHOR> Probably hasn't gotten rolled to your particular server yet.

<comment><USER9> You need to add it as a service from the list of labs products (add more services from Google Apps dashboard for premier account admins). Took a couple minutes after the announcement to start showing up here.

</comment></comment></comment><comment><USER10> There's already a frontpage news regarding this... Why the dupes?

</comment><comment><USER11> I'm the founder of Braintrust, I wonder what I need to do now to differentiate from Wave...

</comment><comment><USER12> Did wave just not have critical mass or was it just not well received by the users?

</comment><comment><USER13> Totally unrelated... Where can I sell the domain name wave.io .... Thoughts?

</comment><comment><USER14> I think the basic failing of wave was that it only solved the easy problems and largely ducked the big problems. No amount of technological wizardry and demo-friendly glitz and glam can make up for failing to meet a need.

The problems that Google Wave tackled were immediacy of communication and inclusiveness. But these are not problems worth solving, between email, IM, wikis, even twitter, nobody has much of a problem with immediacy or inclusiveness. It takes a click of a button to forward an email thread. _The_ problem is information overload, increasing the signal to noise ratio of communication, providing proper contextualization and summarization of information, wave didn't tackle that problem.

</comment><comment><USER15> Blog spam: [http://googlewave.blogspot.com/2010/05/google-wave- available...](http://googlewave.blogspot.com/2010/05/google-wave-available- for-everyone.html)

<comment><USER16> The TechCrunch post provides more information than that link. If you just wanted to help people find the source so they could judge for themselves, say something like "source" instead of "blog spam".

</comment></comment><comment><USER4> I am very interested in Wave as a freeform tool for distributed team collaboration.

But I am very cautious about trying one little thing, seeing if it works, then adapting. Hell if I would come up with some big Wave solution for the team to use and expect it to work correctly.

More worryingly is putting internal team data on Google servers. Can't we have a local sever copy to play around with? (I asked the Google Product Owner for this in an email and got the typical bupkis response) I thought we were all just one big open family around here. If I could play around keeping the data local, I could develop and evolve systems that I could then share with the rest of the world. If not -- that's going to hamper adoption, at least in this area.

I am very optimistic about Wave long-term. Short-term is another matter completely.

<comment><USER17> My guess is that Wave is tied to Google's production infrastructure. So nobody can give you a local copy of wave without also giving you a local copy of everything from our storage technologies to our job scheduling infrastructure.

That ain't going to happen.

<comment><USER4> LOL I hope not! It's probably a little too much for my quad-core.

I was thinking I read somewhere that there was a reference implementation of the XMPP server spec in Java somewhere at Google. I'm not sure if that's the version that the production team is using. Like I said, nobody ever got back to me. A simple explanation would have been great.

As it is, I'm conflicted because of this. The spec is complex enough to make a server implementation extremely non-trivial. In addition, plug-ins on Google may not work on other servers.

The cookies aren't ready yet.</comment></comment></comment>


The ~250000 deplomatic cables in html searchable format - <AUTHOR> http://statelogs.owni.fr/

<comment><USER2> Is this all of them? It seems like it's not. Searching for "China" turns up about 6 results, and "hacking" or "hackers" turns up nothing at all.</comment>