The More Gender Equality, the Fewer Women in STEM - <AUTHOR> https://www.theatlantic.com/science/archive/2018/02/the-more-gender-equality-the-fewer-women-in-stem/553592/?utm_source=atlfb&single_page=true <comment><USER2> This article cites the same research that was discussed on HN a while ago as its basis: [https://news.ycombinator.com/item?id=16407678](https://news.ycombinator.com/item?id=16407678)

</comment><comment><USER3> One reason could be - in poor/developing countries STEM is understood as the escape path from the poverty, while in developed countries people seem assured in their future even if they go in humanities or any other non-tech field - thus following their interests/hobbies rather than the need.

EDIT: unintentional tl;dr as it seems :)

<comment><USER4> this would not only explain why less women go into stem, but also why more guys go into it, as it is common for a guy to feel the onus of securing financial safety for his family.

And not gonna lie, even I, a guy, picked STEM partly because I see it as the best escape route from this country, I would have picked something more fun and less demanding otherwise

<comment><USER5> > it is common for a guy to feel the onus of securing financial safety for his > family

In other words, this is _not_ about what the article claims (girls are just not interested, presumably for biological reasons) but about expectations hammered into all of us by society.

</comment></comment></comment><comment><USER6> Whenever such studies or analyses come up in the media, I find that people are often eager to jump to causative conclusions on the lines of "oh females must have a natural inclination towards 'softer' fields" or (as in case of this article) "In wealthy nations, they believe that they have the freedom to pursue those alternatives and not worry so much that they pay less." However, even if we ignore the obvious correlation vs causation fallacy at play here, these conclusions conveniently ignore a million other societal factors that affect such decisions. For instance, as much of a gender-equality-utopia Scandinavian countries are, they're certainly not free of gender roles and the societal institutions that enforce those. While of course anecdotal, several of my friends from these countries have talked about how they faced invisible, passive-aggressive forms of bullying from fellow students (a large majority of them reportedly female) for having 'geeky' interests such as math. When presented with other options that may eventually be equally or slightly less fulfilling, but come without the social pressure, it makes sense to most people to go with the flow. So much for "natural inclinations"...

<comment><USER4> are you implying that male students who go for stem don't face bullying akin to being "geeky" or "nerds"? Please...

<comment><USER7> I would emphatically say that this isn't a thing in 2018.

<comment><USER8> How could you even know that it wasn't? Besides, kids never got bullied for wanting to become engineers, kids got bullied for all of the hyper-focused interests and trait expressions that makes them in to _good_ engineers.

<comment><USER7> Because the cultural zeitgeist is pretty much entirely _for_ the things stereotypically dumped on in past decades. Because STEM's importance is axiomatic in the same culture. Because the arts/humanities/SocSci outgroup is far more universally derided upon (the merits of that derision are not relevant to this discussion).

<comment><USER8> The culture you're describing sounds like something that might arise in SV, but trust me it doesn't really describe America... Propaganda campaigns rarely set what kids think is cool.

The impact of all of these weird pro-STEM programs is a really complicated discussion, but let me suggest that it doesn't really make high school any easier for the vast majority. (The social structure of kids doesn't really look to DuPont for ideas about which way is up...) Your response almost reminds me of how some people are feeling left out of minority help programs ("what did I do to deserve a landscape devoid of scholarships," that kind of thing.) without realizing exactly how little help those programs really provide. In a sense, overestimating the effectiveness of a response to privilege so harshly that you think the privilege has been reversed.

<comment><USER7> >The culture you're describing sounds like something that might arise in SV, but trust me it doesn't really describe America... Propaganda campaigns rarely set what kids think is cool.

I didn't mention my geographic location (Toronto) or the root causes of the cultural shift (I can't speak to that), so these are some strange assumptions to make. I'm also not really following the rest of your argument, tbh.

In any case, I stand by my argument that this:

>are you implying that male students who go for stem don't face bullying akin to being "geeky" or "nerds"? Please...

is a fairly tall order in 2018. Positioning yourself as someone who seeks a career in STEM, regardless of your gender, is not marking yourself out for bullying, and hasn't been for a long time.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> This, and similar research I'd seen before seems to point to women being equal or better at STEM than men (and also being better at non-STEM stuff), but actively avoiding it as a low-status role when they have better options.

Slightly baffling to see this celebrated by men in these careers as some kind of vindication.

The data appears to be saying you (we) suck, but that's a win if you think the data was going to show that one gender sucked (and you ignore that you secretly thought it was them).

<comment><USER10> > Slightly baffling to see this celebrated by men in these careers as some > kind of vindication.

An amusing and insightful observation.

I would say it's baffling until you realize that the alternative is that the whole the gap in female STEM employment continues to be attributed solely to male sexism. It's better to be perceived as stupid than evil.

Also, are we all now in agreement that there are likely cognitive differences between men and women, and that it is beneficial to explore those differences scientifically? Honest question.

edit: missing word

<comment><USER11>
      > are we all now in agreement that there are likely
      > cognitive differences between men and women

Alas, far from it I am afraid. Which is very puzzling. Not many will argue that men and women have different physiology, different physical build. But god forbid from making the assumption that cognitive interests may also differ.

<comment><USER12> Do you have relevant scientific literature to back that claim ?

<comment><USER13> [http://slatestarcodex.com/2017/08/07/contra-grant-on- exagger...](http://slatestarcodex.com/2017/08/07/contra-grant-on-exaggerated- differences/)

</comment></comment></comment></comment></comment><comment><USER14> Let's turn the argument on it's head.

Statistics say boys are more heavily inclined to have a STEM career. Does this mean they feel they cannot consider a career in other fields like teaching, nursing or other female-dominated fields?

As a woman I often wonder, what's so great about STEM aside from the paycheck? It depends on your bosses (or being your own if you are lucky and that way inclined), but I don't think we've shown many girls that STEM is really rewarding and it looks on TV like it involves a lot of staring at computer screens. Boring! So I expect that will change when we get to use more interactive interfaces. Also, I hope society does more work to let boys grow up feeling STEM isn't their only hope.

<comment><USER4> Yes thank you, people seem to forget that the reason why STEM gets a higher paycheck is because there's less people willing to go for it, both female and male, the paycheck is not a prize you get for being male, it's a prize you get for the sacrifice you make. Look at it this way: no one is complaining about the lack of girls in the blue collar industry.

<comment><USER15> > less people willing to go for it

Or capable. I imagine the IQ bar is set quite a bit higher for STEM-like courses and careers... Also, there's much less room for bullshit (at least in programming - your code either works, or it doesn't work, and that's really easy to verify at university and when applying to jobs - as opposed to e.g. marketing, where it's much harder to quantify someone's skill).

</comment></comment></comment><comment><USER16> Career Successful women in stem told me that she would have pursed for a different career if she wasn't the daughter of immigrants. She was destined to be an engineer or a doctor.

<comment><USER14> >engineer or a doctor

These are both STEM fields (Science, technology, engineering, mathematics). Doctor is a crossover in my view, anyway. Sounds like she would like more autonomy with her career choices, rather than not be in a STEM field.

<comment><USER17> I think GP means that she felt like engineer and doctor were the only options she could choose from, and therefore she was effectively dragooned into a STEM career. That is, if she'd been dealt a different hand, she would've preferred a career in something other than engineering or medicine.

</comment></comment></comment><comment><USER18> I would take the whole equality movement more seriously if I had been able, in the past decade, to spot a negative news article / report on women.

When you get all the time exclusively negative news about men, you could start thinking that this is a coordinated (or emergent?) campaign.

<comment><USER19> coordinated by who? By negative reports you mean 'something that women do wrong'?

<comment><USER18> If we insist on reporting by gender (that is questionable in itself) reporting must be truthful, otherwise we risk that these reports are not taken seriously.

I am sure women are better than men at a lot of things, and equally good at other things. What are men better at? We _know_ men are better at some things than women, but currently nobody is willing/interested/daring to report on this.

Does it matter who is better? It seems yes, since lots of news are talking about how much better women are.

Come on, I am extremely positive about equality; if you are starting to antagonize people like me, something is going really wrong.

</comment></comment></comment><comment><USER20> Drawing conclusions about "innate" differences between men and women from this data doesn't seem valid. There's a lot of research left to eliminate confounding effects on participation that aren't covered or investigated by the "Global Gender Gap Index" (e.g. cultural attitudes towards women in STEM, or on-the-job discrimination). Scatter-plotting two datasets available on the internet doesn't feel like enough research for me to dismiss reports from women that they are discouraged from CS before, and during, their careers.

The trendline cited in the article isn't even conclusive, either—eliminating outliers would reduce it almost to noise. Even if it were, there hasn't, to date, been any reasonable explanation for why women's "innate" biology would make them any less interested in professions whose parameters and limitations are purely human-constructed and invented in the past century. Whatever happened during the evolution of the sexes was certainly not informed by the interestingness of C++.

<comment><USER21> Evolution was opinionated enough to create measurable differences in spatial ability, personality, drives and so on, between genders and within genders. Its velocity is directly proportional to the variance that exists in the population: you need something to differentiate in order to have differential selection pressure.

Your hypothesis is in fact the radical one: that programming is somehow such an unseen before ability, that evolution until now has not evolved any machinery to repurpose for its realization. Given everything we know about the very obvious cognitive limits we do have, and where they come from, that seems implausible.

The common reasoning by the way does dismiss reports from men and women alike that all this diversity mongering has poisoned the workplace atmosphere and mostly serves to enrich and flatter the egos of people who wouldn't show up unless they got special treatment for their own demographic, with special segregated events, hiring pipelines and accolades. The old "women in X" spiel. These things are most definitely constructed, and not for the reason they advertise. The standards of evidence demanded to abolish them are sky high compared to the spurious reasoning that spawned them.

<comment><USER22> I have often wondered if one day, the skill of underwater basket weaving was suddenly prized by society as highly as STEM jobs are today....would we see the same pressure to have more more X in underwater basket weaving (where X is your underrepresented group of choice).

A follow up question then to people pursuing STEM fields....are you in it because you're interested in the subject or because of the promise of money/status? An age old question I've heard since I was a young boy.

<comment><USER23> As someone in university and talking to a lot of both genders why they want to join engineering I get a lot of nebulous answers that don't really traceback to a main character trait or reason. Which is fine you don't have a totally define answer but I am kinda perplexed by the desire to do something with seeming no reason.

As a side note I see a lot of women engineers start out as saying they want to do Biomed and the switching to something else. Not totally sure why but I find it interesting.

</comment></comment></comment></comment><comment><USER24> Iran has more women engineers and graduates overall. I'm told it can be as much as 75%. I half suspect that it's two things. The society at large is very gender unequal but applied engineering wants outcomes enough that it overcomes societal distortion to get capable women into roles for mutual benefit.

The second reason is that highly skilled Iranian women stem graduates qualify for immigration points in receiving economies like Australia.

I've worked with some, and know some. They're good. The system works for them as individuals if not in the wider sense of what we'd want in an equal society.

</comment><comment><USER25> Equality of _opportunity_ does not necessarily imply equality of _outcome_. This isn't a paradox. Why are still people still confused about this?

(Actually, people aren't confused about this, but it makes for great clickbait articles and ad revenue because it fans the flames of both sides of the argument.)

<comment><USER26> One of the many simplifications in this debate. Another one: if someone is arguing that there is a difference in the distribution of a particular character between men and women. Immediatly I read comments jumping to the conclusion "my god it says women are more/less [whatever] than men", as in "all women". Lots of people seem to be incapable of thinking in term of distributions, which makes it really hard to have any discussion.

<comment><USER27> > Lots of people seem to be incapable of thinking in term of distributions, > which makes it really hard to have any discussion.

Most people seem very capable of _thinking_ statistically, but they don't _communicate_ in distributions.

For two people communicating in good faith, the two statements (1) "Boys are taller than girls" and (2) "Anne is taller than Sean" don't prompt talk about how both can't be true at the same time, sexist. People communicate statistical differences as "absolutes", but when communicating in good faith, everybody knows what everybody means.

Look at stereotype research. Most stereotypes are statistically true. People communicate them "as if" absolute, but nobody's head explodes when individual examples don't "conform" to the stereotype. That's because people can _think_ in distributions.

That's not surprising, it's how to survive in a stochastic environment.

This gap between thought and speech only becomes problematic ("makes it really hard to have any discussion") because we can rhetorically _exploit_ the fact that most people can't explicitly communicate about distributions. Just tell them they're bigoted, and they don't know how to refute you. Yay, you win.

</comment></comment></comment><comment><USER28> It's almost like... men and women are different.

<comment><USER29> The article addresses that idea.

> The findings will likely seem controversial, since the idea that men and > women have different inherent abilities is often used as a reason...to argue > we should forget trying to recruit more women into the stem fields. > But...that's not quite what's happening here. > In wealthy nations, [women] > believe that they have the freedom to pursue [other] alternatives and not > worry so much that they pay less.

The research does not seem to find that it is gender aptitude or interest differences that accounts for the disparity in STEM graduates.

> ...the percentage of girls who did excel in science or math was still larger > than the number of women who were graduating with stem degrees. That means > there's something in even the most liberal societies that's nudging women > away from math and science, even when those are their best subjects.

<comment><USER30> > But when it comes to their relative strengths, in almost all the > countries—all except Romania and Lebanon—boys' best subject was science, and > girls' was reading

> And the more gender-equal the country, as measured by the World Economic > Forum's Global Gender Gap Index, the larger this gap between boys and girls > in having science as their best subject.

The research seems pretty clear.

> ...the percentage of girls who did excel in science or math was still larger > than the number of women who were graduating with stem degrees.

This quote is not related to whether there are interest differences or not. They may be equally good in science/math and something else and decide they want to do the other thing without that automatically implying "society is causing this preference" (and by the way, medicine is not "STEM" for some reason, but no one is becoming a doctor without strong aptitude for math/science).

If the research results I quoted above are to be believed, regarding aptitude, someone may excel in A (say girls in these countries get "very good" scores in math at the same rate as boys) and be much better in B (they excel in reading/other skills at a higher rate than boys) and it would be natural for this person to pursue B in that case, no?

</comment></comment></comment><comment><USER31> Related: [https://news.ycombinator.com/item?id=16407678](https://news.ycombinator.com/item?id=16407678)

(Upon skim, this does not seem to be a duplicate per se.)

</comment><comment><USER32> An article about this research was submitted to HN earlier today, and provoked vigorous discussion with 271 comments: [https://news.ycombinator.com/item?id=16407678](https://news.ycombinator.com/item?id=16407678)

Here's a link to the actual paper: [http://journals.sagepub.com/doi/abs/10.1177/0956797617741719](http://journals.sagepub.com/doi/abs/10.1177/0956797617741719)

</comment><comment><USER33> If you look closely at their scatter plot, you can see that the UAE, Turkey, Algeria, and Tunisia cluster in the lower right. Without them, the relationship would be considerably weaker. Is there something in particular about Middle Eastern culture that's skewing the results?

I'm not sure I understand the choice of countries in the regression either. Where are India and China, for example?

<comment><USER34> What could be so particular about the Middle Eastern culture that would result in a different treatment of women in these countries? Is it about the climate? Is it about the diet? The research must continue to resolve this mindboggling mystery.

<comment><USER33> Not sure I understand the reason for the sarcasm there.

</comment></comment></comment><comment><USER35> This phenomenon isn't entirely new. Some man have seen it as "Scandinavian gender paradox".

Still, why are we surprised? We know instinctively, that there will never web 50/50 in some fields, because man/women just don't like it as much. It's sad that some people have to pretend to agree with the feminist narrative

<comment><USER36> Except some studies have shown countries with more equal rights country have worse gender stereotypes overall. And even if the studied were to be flawed, your "men and women have different tasted" theory is pure narrative as well. No study with any solid methodology has ever shown women and men have inherently different tastes when it comes to STEMs, and it's pretty much impossible considering the intertwined nature of nature and nurture and the very cultural nature of STEMs.

</comment></comment><comment><USER36> This paradox has been highlighted at another level : a study which I read in the book "Psychologie sociale : perspective multiculturelle" by Serge Guimond showed that countries with the highest gender/sex equality in terms of RIGHTS also had the highest gender gap in terms of STEREOTYPES.

</comment><comment><USER34> Forcing people to change their interests based on an agenda only results in them being even less interested than they were in the first place. There is also the backlash to the nonstop pushing of politically-based hiring instead of meritocratic practices. Some even state "meritocracy" is outright oppressive and should never be applied.

<comment><USER36> Maybe because these people realized meritocracy is an outright lie and that in any instance there are gender/racial/class/geographical/... inequality, or even biological inequality you right-wingers are so keen to point at, so there's no way to actually talk about merit ?

<comment><USER37> A meritocracy isn't unfair by definition. It is an ideology based around what people can achieve. These achievements don't have to be grand or anything. They can be small and incremental. It is an ideology about empowering people, no matter who they are.

Even those who don't have equal capability compared to others can contribute in small ways, and so, they can indeed achieve merit based on merely doing what they can do, even if it is small.

But, it is many small things that add up to massive changes, and that is what a meritocracy is ~ just chip in where you can contribute, and you can make a difference, no matter who you are.

However, there are issues where a meritocracy cannot be of use, and that is in a system designed deliberately to exclude merit, and instead empower those who prefer there be imbalance, injustice, and unfairness. SJW ideologies which seek to belittle and mute those they consider the "enemy" are like this.

</comment></comment></comment><comment><USER38> Why are we telling women do do STEM if that's not what they want to do, we should be supporting women want to do that. For example more entry level roles and considering women for those.

<comment><USER39> Isn't treating women differently from men sexist by definition?

If we want equality, let's treat everyone equally. No special programs for any gender.

We're constantly told that men and women are the same, and that you can even switch between them any time you want, but then we hear the complaints that gender X does better/worse at task Z. This narrative doesn't make any sense to me.

<comment><USER37> Men and women obviously aren't the same, no matter how much gnashing of teeth of matter occurs, because both have their strengths in different areas, according to their overall psychology.

Men and women are psychologically-different, and no amount of trying to force a desperate sameness will change that. In fact, it might even cause people to want to be even more different than before.

The SJWs campaign for "sameness" but act like the complete opposite.

Maybe they're just in denial of who they truly are, and are unconsciously asking for help and recognition that they truly matter, but cannot help but unconsciously portray this in a destructive manner for all to see, except themselves and their blind peer group.

<comment><USER36> "men and women are different" is such a broad statement you sure could say it and then say "duh anyone who disagrees is bullshit". Here's big news : blue eyed and brown eyed people are different. As for the rest of your text, it's all just broad statements with very little scientific value, since theybare then again broad claims. Girls prefer pink, y'know. So natural.

<comment><USER40> There are consistent, globally found physical[1] and psychological differences[2] between the sexes, so it's a bit more complicated than comparing people with different eye colors.

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

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

</comment></comment></comment></comment></comment><comment><USER41> Still no charts. I don't see them communicating with me.

</comment><comment><USER42> I just discovered that where i work (Algeria) there is hidden rule in hiring new devs that wasn't known publicly it's simply no women, seriously i work with 20 men for more than two years and i just discovered that our head of recruitment doesn't hire woman at all no matter how she's talented because of so many reason most of them are racist but kind are hard to argue with him like if woman get married she will stop working and yes like 70% of this happened all time when women get married her husband will force her to stop working, even if she doesn't when she have kids she start working less hours i mean like 50% less and the big reason that they can't handle pressure at all specifically if production server is down she simply get cracked down and where i live woman never work full time never that is like freaking problem and they never work for additional hours (despite we pay for those hours). so if he invest in woman she's going to get him like 30% productivity of men.

<comment><USER43> In a free market such companies would be at disadvantage versus the ones who also attract top talent regardless of gender or race or any other demographic criteria whatsoever.

<comment><USER44> That's assuming an internal company culture couldn't be created based on shared understanding that would lead to competitive advantage. Eg, if you create a company with only black women, you may not necessarily get the very best individuals, but you could create a very unique culture. That culture could empower the whole team to work better with each other with the end result being a more productive team even though individuals may be less productive alone. It could also reduce turnover and increase job satisfaction, leading to less time spent training and cheaper and more productive overtime for the company.

Such a company could be at an advantage in a free market where there were no rules on employment discrimination.

<comment><USER45> I tend to use a simple method to analyze a post. Switch the races and genders around.

If in your post one would switch the term black woman into white man it would become "If you create a company with only white men.... you could create a very unique culture.". etc

That kind of post would cause a massive uproar for rather obvious reasons.

Yet it's interesting that these kind of posts don't.

<comment><USER44> Yeah, it's unfortunate and that kind of uproar doesn't do anybody much good. I chose black female on purpose for that reason, obviously, as it's acceptable to consider such things intellectually in today's world.

We've stopped discussing some key concepts just because it's not allowed anymore. I guess we need the bravery of enlightenment era philosophers once again - to stand up to social pressure in the name of open ideas.</comment></comment></comment></comment></comment>


To sleep or not to sleep: the ecology of sleep in artificial organisms - <AUTHOR> http://www.biomedcentral.com/1472-6785/8/10 When food and sleeping sites overlap, (simulated) animals tend to have polyphasic sleep: one nap, one bite, one nap, one bite. So human of them: reminds me of a lazy Summer afternoon.<p>This paper has numerous implications for the workplace. <comment><AUTHOR> When food and sleeping sites overlap, (simulated) animals tend to have polyphasic sleep: one nap, one bite, one nap, one bite. So human of them: reminds me of a lazy Summer afternoon.

This paper has numerous implications for the workplace.</comment>


Ubuntu Unleashed: Sun xVM VirtualBox 1.60 Just Released for Ubuntu Hardy Heron and other OSes - <AUTHOR> http://www.ubuntu-unleashed.com/2008/05/virtualbox-160-just-released-for-ubuntu.html

<comment><USER2> What's the point? Is this better than KVM?

<comment> patrickg-zill Does KVM allow you to run XP or Solaris ?

<comment><USER3> VMWare does.

<comment><USER4> Right - I don't know how VirtualBox compares with VMWare, except that the former is open source.</comment></comment></comment></comment>


Building the Golden Gate Bridge - <AUTHOR> http://mashable.com/2015/05/21/golden-gate-bridge-construction/

<comment><USER2> Compare and contrast with the eastern section of the Bay Bridge.

What happened?</comment>


Shed Skin - Python-to-C++ compiler - <AUTHOR> http://shed-skin.blogspot.com/

<comment><USER2> Already posted (on the day of the 0.3 release).

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


Proof Without Words - <AUTHOR> https://en.wikipedia.org/wiki/Proof_without_words <comment><USER2> The article only features diagram examples, but there's a lot of potential for animated proofs. There's a wonderful youtube channel for this, Think Twice: [https://www.youtube.com/channel/UC9yt3wz-6j19RwD5m5f6HSg](https://www.youtube.com/channel/UC9yt3wz-6j19RwD5m5f6HSg)</comment>


On Having No Head: Cognition Throughout Biological Systems (2016) - <AUTHOR> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4914563/ <comment><USER2> Was recently floored by Michael Levin's (one of this papers authors) talk at NIPS. Possibly the most amazing talk I have ever seen.

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

<comment><USER3> Indeed, I just watched it and it is fascinating. Thanks for sharing!

At about the 38:00 mark, during Q&A, he mentions some yet-to-be-published work by his team where it's possible to make artificial living machines that are completely unlike the organisms from which the material is sourced (if I'm transcribing his words more or less accurately).

That sounds like the stuff of science fiction. Does anyone know where to follow the progress of this kind of work?

<comment><AUTHOR> His twitter account (@drmichaellevin) is a good place to start.

<comment><USER4> I'm not sure why you're being downvoted for this. He often tweets out interesting articles on neuroscience and electrophysiology.

<comment><AUTHOR> The irony is that that's where I found this article in the first place.

</comment></comment></comment></comment></comment><comment><USER5> If you work with any kind of evolutionary system or neural networks or meta- optimizers (Like Schmidhuber's Gödel machine) there comes a point when you realize that "intelligence", whatever it is, should be _expected_ to arise. Evolution and meta-evolution proceed at the same time in life, so intelligence should be ambient in Nature. (This is what Wolfram has been talking about with his "New Kind of Science" tome, etc. Gregory Bateson also talked about this in "Steps to an Ecology of Mind: Collected Essays in Anthropology, Psychiatry, Evolution, and Epistemology" and "Mind and Nature: A Necessary Unity (Advances in Systems Theory, Complexity, and the Human Sciences)".)

Now, combine this idea, that meta-evolutionary adaptation naturally leads to ambient intelligence (put another way, living systems have as much intelligence as is adaptive, the limiting factor on the intelligence of the global ecosystem is NOT the difficulty of being intelligent because it's actually really easy to be intelligent) with the recent discovery that the oceans are a sort of naturally occuring Grey Goo[1], and it seems that the oceans themselves are intelligent.

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

> Marine phages, although microscopic and essentially unnoticed by scientists > until recently, appear to be _the most abundant and diverse form of DNA > replicating agent on the planet._ There are approximately 4x1030 phage in > oceans or 5x107 per millilitre.

From [https://en.wikipedia.org/wiki/Marine_bacteriophage](https://en.wikipedia.org/wiki/Marine_bacteriophage) . Ephasis added.

</comment><comment><USER6> Fascinating. I wonder how the principles here could be adapted to tech? I'm thinking specifically of IoT-type setups with low-powered on-device processing that are mesh networked, without needing a cloud-type backend as a 'brain'?

<comment><USER7> I'm thinking of numerical optimization that uses algorithms inspired by nature but very different from the current crop of neural networks, while still taking advantage of GPUs, gradient descent etc.

</comment></comment><comment><USER8> If a "debate" is a kind of AI/neural network activity this makes sense. The smaller groups could correspond to layers, and one would expect that the level of interchange would be higher in groups of small groups compared to single large group. In this model, a debate is "thinking" where the participants act as neurons. A recent thread on HN ([https://news.ycombinator.com/item?id=18700328](https://news.ycombinator.com/item?id=18700328)) linked to a video [https://www.youtube.com/watch?v=RjD1aLm4Thg](https://www.youtube.com/watch?v=RjD1aLm4Thg) about ion channels providing similar functionality to neurons, so maybe we humans can create "brains" as well.</comment>


How to read Haskell like Python - <AUTHOR> http://blog.ezyang.com/2011/11/how-to-read-haskell/ I prefered to learn how to write it, but I'll stick with reading skill for now ... :-) <comment><USER2> I like this, it's like when they teach you mathematics without _really_ teaching you the 100% correct version because you're not really ready yet. I imagine the approachability of a lot of Haskell material to beginners suffers from being overly correct (which, to be fair, we as developers are trained to be, haskellites doubly so).</comment>


Type safe OpenGL – Converting strings into types in D - vive-la-liberte https://maikklein.github.io/2015/11/14/Converting-strings-to-types/ <comment><AUTHOR> I'm currently doing something similar in C++ based on a project I worked on a couple of years ago. It is a wrapper around OpenGL for people like me who are tired of figuring out the specifics of the OpenGL calls every time they write something.

Goal: Easy access to shaders and its respective buffers with a bare bones visualization.

Example:

        Shader shader(fragment_shader, vertex_shader);
        verticesVBO.set(vertices);
        verticesVBO.map(shader, "inPosition", false);
        shader.bind();
        shader.setUniform("uViewMatrix", camera.view());
        shader.setUniform("uProjMatrix", camera.proj());
        shader.setUniform("uModelMatrix", modelMatrix());
        facesVBO.bind();
        glDrawElements(GL_TRIANGLES, facesVBO.length(), GL_UNSIGNED_INT, (void*) NULL);

I should clean it up and make it available as a library.

<comment><USER2> I've been fooling around with Go bindings to GL and also want to do something similar.

I still find it kind of uncomfortable that I'm copy-pasting variable names as strings between (the middle of!) the shader code string and the use sites (e.g. `setUniform` calls) -- I'd like it if I got some sort of quick compile time sanity check that those references match up. Had you considered going that far, and if so, what were your thoughts?

<comment><USER3> Not parent, but I wrote a shader introspector to reduce the pain of uniform mismatches as a (small) part of my master thesis.

My advice would be: don't do this.

If you can afford to support OpenGL 3.1+, use uniform buffer objects with the std140 layout instead. That way, you can create a strongly-typed struct in your code and access it normally on the CPU side. Uploading to the shader then is done with a single *BufferData call.

See [1] for more information.

[1] [https://www.opengl.org/wiki/Uniform_Buffer_Object](https://www.opengl.org/wiki/Uniform_Buffer_Object)

</comment></comment></comment><comment><USER4> This only seems useful for user-defined glsl types. The builtin glsl types would only have to be written out once as D types.

The general idea of "importing" types is a good one and I think this is what F# achieves with type providers. I've seen this applied to database schemas and filesystems, but never OpenGL.

<comment><USER5> Maybe its because OpenTK has type safe bindings(OpenGL, OpenCL and OpenAL) for F# and C#.. [http://www.opentk.com/](http://www.opentk.com/)

<comment><USER3> It took an awesome amount of work to get that level of type-safety. Now that this is in place, other languages could use that infrastructure to provide type-safe bindings:

[https://github.com/opentk/opentk/tree/develop/Source/Bind/Sp...](https://github.com/opentk/opentk/tree/develop/Source/Bind/Specifications)

The */override.xml files contain directives to convert the official Khronos XML specifications into type-safe versions. All you need is a code generator for your language of choice.

If anyone is interested in trying this, I encourage you to contact the developers on github (there used to be C++ and Java code generators that have since been removed.)

<comment> vive-la-liberte >there used to be C++ and Java code generators that have since been removed.

What was the reason for removal? Difficulty of maintenance? Out of scope for a C# project?

<comment><USER3> Mainly lack of an interested maintainer.

It's also a bit tricky because some .Net assumptions are hardcoded (i.e. overload resolution, generics, pointers+references), which makes it harder to generate idiomatic code for other languages. Nothing that cannot be fixed with a bit of effort if someone interested shows up, but until then it's better to generate excellent bindings for one runtime than mediocre bindings for multiple (and pretty much every runtime comes with a mediocre OpenGL binding.)</comment></comment></comment></comment></comment>


The end of privacy as I knew it - <AUTHOR> http://marcovaltas.com/2016/12/07/end-of-privacy-as-i-knew-it.html <comment><USER2> > there was no way the website would know my email just by my visit.

I'm curious. How did the furniture company get your email address, just from you clicking a link in your email? Anyone?

<comment><USER3> Maybe the wife gave used the "Tell a Friend" feature of the site.

<comment><USER4> This is one of the saddest and most orwellian aspects of today's marketing. Even if you run a tight ship, your friends are bombarded with just as much force to give up not just their information, but yours as well, undermining your efforts.

<comment><USER5> And this is one of the reasons why I have as many email addresses as I do.

</comment></comment></comment></comment><comment><USER6> I love the guy claiming that his iPad was listening to their conversations and he magically got ads related to his conversation.

I'm a little skeptical of that one.

<comment><USER7> facebook was found to be doing the same thing. Voice is just some data, companies have teams of engineers working on efficiently extracting that datastream and using it to sell you ads.

<comment><USER8> Orwell never predicted we'd be paying for the always on microphones to be installed in our homes ourselves, and be happy about them.

It seems most folks don't even see or care about where it's leading us.

Personally? It's almost ostracising to express strong opinions on this sort of thing even to our tech peers.

If you've also worked on tech which provides or enables this sort of invasion, then its hard for us not to really care about how we're doing nothing to stop it or to understand why we're not more angry.

Trying to get a dialogue going on it just makes people think you're a step away from being the crazy person with the tinfoil hat...</comment></comment></comment>


Ethnic Features extraction and recognition of human faces - <AUTHOR> https://ieeexplore.ieee.org/document/5487194 <comment><AUTHOR> I thought this was pretty disturbing, the abstract doesn't even attempt to hide that it's about surveillance of Uighurs.

> "The result indicates that the average recognition accuracy rates of > Tibetan, Uighur and Zhuang ethnic groups can reach 79% by algebraic features > and 90.95% by geometry features."

Also the introduction has some Orwellian irony:

> "The research of the ethnic facial feature is of great significance for the > science and technology and national unity. It is well known that China is a > multi-ethnic country in which all the ethnic groups are interacted and > merged with each other in thousands of years. Meanwhile, the facial features > of each ethnic group are changing. In the progress of national integration, > the national facial features has not disappeared, but evolved with new > features. It is of the practical significance for the protection of ethnic > cultures and the research of the development process to digitalize the > preservation of ethnic culture and to study and find the new features > produced in the ethnic merges."

They're 'preserving' the cultures of the group the CCP is currently actively working to destroy.

Technology companies should seriously consider their involvement in China.</comment>


MIT Hacking Medicine - Blue Button Innovation Challenge - <AUTHOR> http://hackingmedicine.mit.edu/2013/12/16/hot-off-the-presses-announcing-the-boston-blue-button-innovation-challenge/

<comment><AUTHOR> MIT H@cking Medicine is PSYCHED to announce our collaboration with the Office of the National Coordinator for Health IT, Tufts MedStart, and the White House Innovation Fellows surrounding the first Boston Blue Button Innovation Challenge! The event is taking place Friday, January 17th to Sunday, January 19th at Tufts Medical School, which is located in the Sackler Building at 145 Harrison Ave in Boston.. Also we will hold a Blue Button developer workshop on MIT's campus in Building E-62 on Friday afternoon prior to the event.</comment>


Ray Kurzweil – How the World Will Change - <AUTHOR> http://genius.com/Ray-kurzweil-how-the-world-will-change-annotated <comment><USER2> 1) Self-driving cars by 2017: 4 years ago I have "predicted" (with friends) that Singapore will be the first nation to fully embrace self-driving cars. The impact on real estate costs, and how people spend their time, will be huge. 2017 is just around the corner; I doubt that we will see a significant metropolitan area adopt self-driving cars as Ray suggests. Perhaps 2018 or 2019?

2) Personal assistant search engines by 2018: I think there will be the rise of a personal AI that will help us do many things and act as the main interface to the connected world; ONE thing this AI will do is help us perform search engines. Ray implies that this will happen in 2018. I have no idea. It seems extremely hard. I would guess 2020 or 2021?

3) Switch off our fat cells by 2020: I am scared by this. The reason is simple: there are huge economic interests around health and nutrition, and any medicine that can seamlessly help people reduce their fat and become lean is so dangerous. What will the implications be for our health?

4) Click and print designer clothes at home by 2020: I think Ray is wrong here. The ability to print clothes that have the same quality/design/motives of normal clothes is quite hard. Perhaps it will work for simple ones.

5) Full-immersion virtual realities by 2023: Wow. VR seems to be exploding these days. Just today FOVE launched their Kickstarter campaign ([https://www.kickstarter.com/projects/fove/fove-the-worlds- fi...](https://www.kickstarter.com/projects/fove/fove-the-worlds-first-eye- tracking-virtual-reality)), and it's an example of a real innovation in the field (eye tracking). However, full immersion would essentially require the ability to connect directly with the brain. Hmm... 2023? Don't know. Maybe not.

6) Vertical agriculture: why? Why should vertical agriculture take off and represent a substantial % of food produced?

7) 100% of our energy from solar by 2033: impossible. First, nuclear plants and hydroelectric plants serve some purposes in addition to simply generating electricity (military, energy storage, hydro management). Second, producing enough solar panels to meet demand WILL SIMPLY NOT BE POSSIBLE by 2033. I would more reasonably say 2045.

8) Stay young forever by 2040: well, if this is true, and if I'm still alive by 2040, I will be 63 years old, and I will never die. What a fascinating, intriguing, and scary thought. For some reason, I have big doubts on the feasibility of making this happen by 2040. I do believe though that rich people will have access to some form of DNA alteration tools that will help them achieve something very remarkable - perhaps close to the "staying young forever" promise.

I wish that, by 20XX, the world would be a better, fairer place. Inequality is becoming a huge concern for me, and the power of megacorporations and the control that they have over us is also a concern. I really wish we would measure our progress mostly by this, and not simply by looking at technological advancements.</comment>


ANN: Planet Clojure - <AUTHOR> http://planet.clojure.in/

<comment><USER2> There should be some filtering based on post content. Seriously, no one who's looking for Clojure information is interested in what my favorite albums in the 2000s are.

<comment><USER3> In that case, one should have a separate feed for items tagged 'clojure'.

That's the way almost all planets work. Keyword based filtering is not fool proof.

</comment></comment><comment><USER4> Indian domains are becoming popular. I would have expected LinkedIn to go with one.

</comment><comment><USER5> WTF is up with the right-justified text? Is this supposed to me arty minimalist cool?

It's stupid. It's a pain in the ass to read.

<comment><USER3> I am sorry, I didn't understand. What do you mean when you say that the text is "right-justified". AFAICT it is not.

If you seriously believe it's right justified, then patches are welcome :)

<comment><USER5> When I view it in firefox (with NoScript running) on KDE the text is flush right and the left side is jaggy.</comment></comment></comment>


C will never stop you from making mistakes - <AUTHOR> https://thephd.github.io/your-c-compiler-and-standard-library-will-not-help-you <comment><USER2> Trying to avoid adding warnings is a very silly form to twisted logic.

1\. People enabled warnings and -Werror because they want high quality code. 2\. Standard can't add warnings because people use -Werror

This means that not adding warnings is directly against the original reason to use -Werror in the first place! We are now avoiding warning people about dangerous things because they requested to be warned about dangerous things!

<comment><USER3> The argument also doesn't make much sense because all 3 big compilers are _already_ adding tons of warnings with each new release. Upgrading to a new compiler version and seeing screens full of warnings scroll by when compiling code that was warning-free in the previous compiler version is quite normal. Why does this affect the C committee's decision making, and why is it suddenly a problem?

<comment><USER4> If I'm following the author's argument correctly, the very influential companies who maintain very large, very old C code bases don't like what you just described -- new warning messages in code that used to not have any. They worry, then, that if the STANDARD actually mandates a warning, that is even more likely to happen, and that makes the very influential companies very sad.

Which sounds like bullshit to me.

<comment><USER5> It actually makes a little sense: Many companies are required to ship code without warnings (for example in safety-critical systems). Fixing warnings is very expensive and can introduce new bugs in code that has been running fine for decades. If you force new warnings into the compiler the result would be that these companies simply stop using newer versions of the compiler.

<comment><USER3> Part of the normal "warning hygiene" process is deciding when a new warning in old code should be fixed and when it's better to suppress it.

One my favourite warnings in this regard is gcc's misleading-indentation warning. The warning makes sense for new code written by a human, but if the code is machine generated, or decades old without showing any signs of problems caused by a "misleading indentation", then it is indeed much less risky to simply suppress that particular warning in that particular source file or library.

<comment><USER6> The problem here is that if someone dies while using your medical device and you have a "warning hygeine" process then there's a sound legal argument that you knew there were problems in the device that you chose to instead paper over and ignore. It doesn't matter that it makes sense to software engineers. What you have to consider is how a "jury of your peers" will react to you calmly and rationally explaining that a newer version of the compiler added some new warnings, but you decided that because the code has been running just fine for decades that it's totally okay to not address those warnings. It raises questions about how seriously you're actually taking software quality.

Take your "misleading indentation" warning. If you choose to ignore that warning, you're setting yourself up because I can make a great argument that you don't care that the indentation is misleading. And in fact that you're ignoring the hazards of following misleading indentation which is that another person reading your code could misread it and introduce a defect. And that in fact your policy is to allow some defects, including a possible defect which has killed the plaintiff.

<comment><USER7> Any organisation developing safety-critical code will already be following rules strict enough that they have an established deviation approval and documentation procedure.

And frankly, the idea that _people writing software where defects could kill people_ would prefer not to be shown new defects because _fixing them is an inconvenience_ is a pretty insulting view of that industry's professionalism and ethics.

<comment><USER6> And then I might ask you "so why did you apply for deviation on this warning? Warnings are bad, right? So shouldn't you fix a compiler warning if at all possible?"

And then you might reply "Well no because this particular warning would require us to change some code that's really hard to change correctly so instead of spending the time and expense eliminating a potential defect we just left it in."

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8>
      struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
      struct Bark* p_dog = p_cat;

> Most compilers warn, but this is standards-conforming ISO C code that is > required to not be rejected

Bollocks. That is a constraint violation, ISO C requires a diagnostic for it, and ISO C allows that diagnostic to be an error. The constraint is in the section "Simple assignment", which contains "One of the following shall hold:" followed by a list detailing when assignments are valid. Pointers to different structure types on the LHS vs the RHS are nowhere in that list.

<comment><USER9> What's even stupider is that I'd be willing to bet it's also UB. If it is, it means an ISO-C-compliant compiler is allowed to generate _code_ that does _absolutely anything_ ; which makes the worries over adding a warning kind of ridiculous.

<comment><USER10> I wonder if this might be a case where the assignment isn't undefined behavior, but an attempt to dereference the pointer and access the wrong struct type's members would be.

</comment></comment></comment><comment><USER11> And this is how backwards compatibility comes to kill innovation. It's a reasonable stance to keep supporting your long established users but it comes at the cost of ceding the future to the competition ( _cough_ Rust _cough_ )

<comment><USER12> Well, precisely : if people want modern/innovating/fast evolving languages, they can use Rust, Go, Elixir, etc.

I actually started using C for my side projects since two years precisely because I want very long term backward compatibility (that is, being able to leave a program for years without maintaining it, then make a small edit in it and build it with minimum pain). C is perfect for that, and I agree with the sentiment that backward compatibility is its most important feature.

<comment><USER13> > I actually started using C for my side projects since two years precisely > because I want very long term backward compatibility (that is, being able to > leave a program for years without maintaining it, then make a small edit in > it and build it with minimum pain).

Rust actually takes a very strong stance on maintaining backwards compatibility, and Go's stance is arguably even stronger in most cases. You're implying incorrectly that these languages are just breaking things left and right for no reason other than "innovation!", which isn't true.

The overwhelming majority of Rust and Go code from years ago will compile without problems today. Any code from post-1.0 that doesn't compile today was (inadvertently) relying on buggy, incorrect behaviors that have since been fixed... and even then, not all incorrect behaviors get fixed because compatibility is considered so important.

C is fine for certain applications, but no one should choose it for _side projects_ based on some notion of backwards compatibility, in my opinion. If some company is building a business application that needs "backwards compatibility" in the sense that it can run on all sorts of arcane microarchitectures and operating systems, then sure... C is still a really painful* choice, but it might be the right choice then, or if there's an existing C code base, then it probably doesn't make business sense to rewrite it any time soon.

* yes, having no protection from footguns, no real standard library, no built-in concept of asynchronous code, and very little of anything useful is definitely painful. If C is the only valid choice for a project, then it's the only valid choice, and that's what you have to do. The number of projects where you simply _can 't_ use something other than C is diminishing by the day.

<comment><USER14> Rust and Go haven't been around long enough to make those statements about them.

<comment><USER15> That and, while "backwards compatability" has been quoted as important things in these languages. I can attest to rust having issues with what is "idiomatic" rust:

[https://timidger.github.io/posts/i-cant-keep-up-with- idiomat...](https://timidger.github.io/posts/i-cant-keep-up-with-idiomatic- rust/)

there are other similar complaints around the net.

While the C and C++ code I wrote over 2 decades ago is now finally "out of date" as of 5 years ago. It took a while. Not 2-3 years.

Which is absolutely attributed to the language being new, not a design fault.

C is already "settled"

<comment><USER14> I'm learning Rust now, I don't have anything particularly against it other than the obvious, big static binaries and such, and maybe those will be fixed eventually.

I've been able to compile and run C and C++ code from 20 years ago a truly amazing number of times. It's really surprising at how easy it is to work with well written code even if it's decades old.

Will Rust and Go age that way? Maybe. Too soon to tell.

<comment><USER16> >I've been able to compile and run C and C++ code from 20 years ago a truly amazing number of times. It's really surprising at how easy it is to work with well written code even if it's decades old.

Not if you have used any third party libraries. Dependency management is a nightmare in these languages.

<comment><USER14> Not if the project is written well. Yes, dependency hell is a thing, but there are ways to deal with it and make good code. Autotools will straight up tell you version x.x.x of library y is required, and as long as that's available, the problem is solved. Dependency hell is a thing in other languages too -- try to compile a really old Java project sometime.

I spend most of my time working deep in the internals of some things that are 10+ years old running even older versions of some highly (and often badly) modified linux kernels. The well written C/C++ projects definitely stand out.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> C is a knife. You expect knives to cut you, so you handle them carefully.

Except that C is sometimes a knife with another knife hidden in the grip and it you don't handle it just right, the hidden knife will also cut you. (Thinking of libraries/other people's code)

<comment><USER18> Lol I love this analogy. It's pretty much like Darth Maul's lightsaber. Yeah, it'll cut through anything; even stuff you aren't looking at

<comment><USER15> Just like with C code, you better be force(memory) sensitive to even think of wielding the space wizard laser sword.

<comment><USER17> Ah, pointers, not as clumsy as objects; an elegant weapon for a more civilized age.

(I know objects are actually just fancy pointers)

</comment></comment></comment></comment><comment><USER19>
      int main (int argc, char* argv[]) {

          (void)argc;
          (void)argv;

          struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
          struct Bark* p_dog = p_cat;
          // :3

          return 0;
      }

Why declare main that way if you are going to discard the arguments?

Why cast the malloc? This isn't C++.

<comment><USER20> This is what you get when a person who is mostly a C++ coder (as per his bio) writes C. I cringe when I see things like

      struct Bark* p_dog = p_cat;

instead of

      struct Bark *p_dog = p_cat;

That weird affectation of C++ programmers putting the asterisk on the type and not on the declarator, where it belongs, makes my eyes bleed. I somewhat understand the reasoning, but I think it's a gross violation of the Law of Least Astonishment.

<comment><USER19> I never understood the reasoning behind this, is it that "the asterisk is part of the type, so we group it that way"?

That misses the point of the C declaration syntax: you write an expression that when used on its own will recover the basic type. So the asterisk goes with the symbol name, because that's how you dereference a pointer.

Further, it doesn't work if you want to declare more than one pointer like so:

      int* a, b;  /* wrong */
      int *a, *b; /* correct */

<comment><USER20> I think the issue is that programmers want a type "pointer to int", for example, but C doesn't directly provide that type. It has a type, int, with a modifier (asterisk) that can be applied _to a declarator_ to make it a pointer to that type.

One way to create a pointer type in C would be to declare it using typedef:

        typedef int * int_p;

then one can write:

        int_p p, q, r;

and declare three pointers to int with perfect clarity, whereas using the C++ style, we'd get:

        int* p, *q, *r;

which is very confusing, or,

        int* p;
        int* q;
        int* r;

which is very verbose. I honestly don't know how C++ programmers typically handle this situation.

I have seen some code that strikes a middle ground:

        int * p;

which is a little more clear, but doesn't address the multiple declarator situation.

So why don't C++ programmers use typedef? I don't know, other than I understand Stroustrup doesn't like it (not without reason).

(Edited for formatting and minor clarity corrections.)

<comment><USER21> This is not "C++ style"; it's just a poorly considered style perpetrated by coders who are not familiar with the grammar.

The C++ syntax is the same as C in this regard: a declaration has specifiers, and then one or more declarators.

The exception are function parameters, where you have (at most) one declarator.

> _why don 't C++ programmers use typedef?_

C++ programmers do use typedef. For instance:

      typedef std::map<from_this_type, to_this_type> from_to_map;

C++ programmers probably use typedef a bit less than they used to, because of features like _auto_.

When a C++ class/struct is declared, its name is introduced into the scope as a type name. Therefore, this C idiom is not required in C++:

      typedef struct foo { int x } foo;

that cuts down some typedefs. If you used a typedef for a C++ class that isn't just a "POD", you have issues, because the typedef name doesn't serve as an alias in all circumstances.

      typedef class x { x(); } y;

      y::y() // cannot write x constructor this way
      {
      }

<comment><USER22> It's worth noting that this nice C logic falls apart when you do something like

        f(int &a);

to mean "by reference" instead of what it should be, which is "get the address of a, and that will be an int" which is , of course, nonsense.

<comment><USER21> I don't follow. The above is not C. It's a C++ extension over C declaration syntax in such a way that the & is part of the declarator just like * .

      // Inexcusable trompe l'oeil:
      int& a, b;

      // OK;
      int &a, &b;

Here, the mistake may be harder to catch, because the expressions _a_ and _b_ are both of type _int_ , either way.

      // Intent: b is an alias of a.
      // Reality: b is a new variable, holding copy of x.

      int& a = x, b = a;

I think what you mean is that the "declaration follows use" principle falls apart for C++ references.

That is necessarily true because no operator is required at all to use a C++ reference, whereas the explicit & type construction operator is required in the declarator syntax to denote it.

However, it has little to do with the issue that & is part of the declarator and not of the type specifiers.

Declaration follows use also falls apart for function pointers in C, because while int (* pf)(int) _can_ be used as result = (* pf)(arg), it is usually just used as result = pf(arg).

Declaration follows use also falls apart for the -> notation. A pointer ptr is always being used as ptr->memb, but declared as struct foo *ptr which looks nothing like it.

And of course, arrays can be used via pointer syntax, and pointers via array syntax, also breaking declaration follows use.

Declaration follows use is only a weak principle used to help newbies get over some hurdles in C declaration syntax.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> Backwards compatibility for code is important, like progress in language evolution. I have question regarding "C has no ABI that could be affected by this, C doesn't even respect qualifiers, how are we breaking things?!"

We have language standards for changes like this like '-std=c2x' or '-std=c89' with GNU's GCC. I understand and accept the matter of avoiding breakage. Furthermore C is inherently weakly typed, contrary to C++ which is strongly typed. Something you probably should not change, because that are basic language features. But the option to set the language standard does exist for this situation, to allow changes which will affect users. So why it cannot be used here?

That is not a critic. I'm sure that have their rationale for that and know more than me.

PS: Some changes will break the ABI, in that cases we likely see a PREPROCESSOR variable or something like that which is more complicated. The GCC people used it for some changes to std::string if I remember correctly.

<comment><USER24> I was wondering this myself. Those million line codebases where they are worried about new warnings breaking things should be using a compiler already that doesn't know about the new standard, or one that allows you to set which standard their code is following. I guess I don't understand the problem. Does something like MISRA assume you are using the latest standard? I understand there are regulations involved.

</comment></comment><comment><USER25> "We will not make it easier for new programmers to write better C code." \- well, that escalated quickly

</comment><comment><USER26> one should never get in the way of a good rant.

more seriously, what I'd like to see in C (as a long-time programmer in C) is less freedom around undefined behavior. I used to feel like the biggest mistakes made in C were around pointer bugs, but you can be careful and get things like that (mostly) right. Undefined code is a lot harder to see and avoid without a very deep understanding of lots of small details.

<comment><USER27> It would be very nice if there was a special C compiler that could just warn about all occurrences of undefined behavior in a program. It doesn't even need to be able to generate code, it could just be a front-end that points out the places where undefined behavior is either being invoked, or could be invoked depending on the input to the program.

<comment><USER28> Does this piece of code have UB? Could it invoke UB depending on the input to the program?

        void count(int x)
        {
          for (int i = 0; i < x; ++i)
            printf("%d ", i);
        }

The answer to the latter question is of course "yes" \- signed integer overflow is UB, so you invoke UB by passing a negative x.

Would you like every loop to be flagged as potential UB? I don't think you'd last a single day programming in that C dialect.

<comment><USER27> You wouldn't use the compiler to build you programs, you'd just use it to detect UB.

It would be especially useful if you could specify your entry point(s), and let it find all cases where user inputs could cause UB.

I think it would be especially helpful for checking the output of compile-to-c languages.

</comment></comment></comment></comment><comment><USER29> Take a look at Zig. [https://ziglang.org/](https://ziglang.org/)

It fixes most of the C mistakes, while still giving programmers tight control over the system.

</comment><comment><USER30> The real problem with n2526 is that it proposes fixing the return types of locale functions, rather than deprecating that hot mess entirely.

</comment><comment><USER31> Please tell me if I misunderstood but this is what I thought I was reading here:

\- The author is someone quite young (undergrad age) who is serving on a C language committee (that I assume is mostly made up of people who are over 40, probably mostly over 50).

\- The author not only is donating his own time to C language committee work, but also clearly knows what he's talking about regarding C.

The article came across to me as thinly-disguised frustration/anger that the committee had no interest in making C "safer".

My take away was that the article very much fitted in with all the articles one sees being positive about Rust not just being of academic / hobbyist interest but being a serious contender for a replacement in many industry contexts.

</comment><comment><USER32> > _C will never stop you from making mistakes_

As making mistakes is nature of human, and _C_ will never stop human from making mistakes, then _C_ will preserve human be natural forever!

</comment><comment><USER33> Well, I liked the part about (* vague gesturing towards outside *)

</comment><comment><USER34> What does it mean to be the 'Project Editor' of C?

<comment><USER35> My understanding of the role is that it's their job to literally edit the standard, that is, they take the papers that have been accepted, and apply them to the standard's text to produce the next draft of the standard.

</comment></comment><comment><USER36> Actually, "C will never stop you from doing <things>".

</comment><comment><USER37> Sounds like a bad case of the tail wagging the dog to me.

</comment><comment><USER38> ...and that's a good thing.

Console homebrew. iOS jailbreaking. Android rooting. Those are only some of the freedom-enabling things this and other "insecurity" allows. It's not all bad --- and IMHO it's necessary have these "small cracks", as it keeps the balance of power from going too far in the direction of the increasingly authoritarian corporations.

I always keep this quote in mind: "Freedom is not worth having if it does not include the freedom to make mistakes."

<comment><USER39> This has nothing to do with any of that. Absolutely nobody is proposing that it shouldn't be possible to write code that reads from and writes to arbitrary registers and memory addresses, even though this obviously makes complete memory safety impossible. (I mean, there are legitimate use cases for sandboxing and VMs and what have you without escape hatches, but there are also legitimate use cases for not-that.)

This is about providing better compiler diagnostics. Such diagnostics can't catch every mistake, as long as we require the aforementioned ability to perform arbitrary operations, but they can catch a lot more mistakes than they're catching now.

</comment></comment><comment><USER40> Oh boy. The conclusion sounds pretty scathing.

</comment><comment><USER41> Yet more worshipping on the fear of change. Simply speaking. If the code is suspicious, it should be treated as such.

I am not tied to some definition of perfection but rather the practical. Developer tools help write safer code. If that code is running dangerous equipment this is even more important.

The expectations and quality needs to be raised. ESPECIALLY in operating systems, device drivers and yes code that has been running "just fine" for years.

</comment><comment><USER42> Be advised that every new C project written by experienced developers begins with `-Wall -Wextra -Wpedantic -Werror`

<comment><USER43> -Werror is a bad idea for open source projects or anything that will be compiled by people who do not know how to fix things when their shiny new compiler added a fancy warning.

-Werror=... for specific warnings might be OK in some cases.

<comment><USER42> They can just remove -Werror when compiling. It's useful enough to keep in place by default if you consider warnings bugs (and you ought to).

<comment><USER44> So would you agree that it might be a useful thing to use for local development, but not for code you want other people to compile?

</comment></comment></comment></comment><comment><USER45> This is a dumb argument. The proposal was to _add a new kind undefined behavior_ that breaks a bunch of existing code, and this is spun as _not_ helping?!

<comment><USER2> That's not what the article claims. It claims that it was only adding a warning.

</comment></comment><comment><USER46> sounds like a stealth argument for rust?

</comment><comment><USER47> If the C standard org was serious about code safety the FIRST thing they would do is PUBLISH THE STANDARD!!!!

Complaining that people don't follow the finer details of the standard while at the same time keeping the standard unavailable to the vast majority of C programmers is a travesty. When compiler writers think that its ok, to put "optimizations" in to compilers that remove vital NULL checks, because the the spec says that something may be UB that make no sense, I think to myself, What would they say If they downloaded the latest version of their favorite text editor, only to find that it would format their system disk when ever the user presses Control? When they then reached out to the maker of the text editor, the developers would answer: "Oh, on page 204 in the documentation that costs money to access it says that pressing Control, is undefined, we we are in our rights to format your system disk". Would they be ok with that and think it was fair? Thats how the C standard body is behaving!

NOBODY learns C form the C standard, and that is your fault, so don't complain about people not following it. The fact that you are also fucking it up doesn't help: ([https://news.quelsolaar.com/2020/03/16/how-one-word- broke-c/](https://news.quelsolaar.com/2020/03/16/how-one-word-broke-c/))

<comment><USER35> Isn't this situation due to ISO rules, and don't they publish a "draft" that is identical to the actual standard before hitting publish, to get around those rules?

Or maybe you're talking about something I don't understand.

<comment><USER47> Yes, but this arcane way of working isn't OK, when the entire opensource world depends on the language to produce functioning code.

<comment><USER35> While I also prefer other processes, for many people, ISO standardization is really important, and so to me it seems like they're doing the best they can, given that constraint.

</comment></comment></comment></comment><comment><USER48> Of course the language can help the programmer to write better code. High level constructs and easily available libraries that are well tested and widely used helps a lot. However, the biggest problem is not the language, it's that the programmer simply writes faulty code.

<comment><USER49> So you have two main solutions for this problem : have all programmers to never ever write faulty code, or design and use programming languages that are safer and less error prone.

One is impossible, while the other is already applied.

<comment><USER48> In my experience most bugs are due to misunderstanding requirements and simply writing faulty logic. Just a few bugs are related to the language itself.

<comment><USER50> In highr-level languages you can make a lot of faulty logic inexpressible in your code, which eliminates a ton of bugs.

<comment><USER48> That's pretty much what I wrote in the first post.

</comment></comment></comment></comment></comment><comment><USER51> A short summary.

"I tried punching myself and C let me do it. Now I am ranting how C gave me a nose bleed."

If you are using C for projects that are big and abstract then you are THE problem for picking wrong tools for your task. I killed a mosquito with a hammer but it left a hole in my wall => hammers are terrible tools.

<comment><USER52> This isn't even remotely what the post is about. It's about how the C standard is resistant even to things like warnings for provably bad code in the name of backwards compatibility ("more warnings for (maybe) working code = bad"). Did you even read the post?

</comment></comment><comment><USER53> When you demonstrate that your ECNL (equally crappy new language) merits an investment of time guaranteed not to break in perpetuity against programmers in the future and changing standards I'll make an effort to learn it. Mind, it must be as free (to use,modify,permute and as low level) ~ C. I must be able to do what I need to do without being second guessed bc it's dangerous. There are some people who know when to be dangerous and slowing us all down to the speed of the slowest bootcamp grad or most avaricious exploiter of minimal talent isn't progress. Otherwise I'll stick with the libraries I know, trust, and have written in C. This article is great mudsticking btw.

</comment><comment><USER54> Neither will Haskell, Rust, etc. The extra classes of mistakes they can prevent at compile time just aren't a meaningful volume of mistakes to make a practical difference in the lives of any developers apart from a few niche system engineering use cases.

If you think languages should facilitate type system design patterns that render large classes of application level mistakes impossible, you are just an architectural astronaut falling prey to premature abstraction and unaware that these languages aren't making your application code safer or more reliable, only more brittle to the inevitable needs to break its core abstractions to solve expanding use cases.

<comment><USER39> This is a very strong claim. Do you have evidence for it?

(Yes, I'm aware that there've been a bunch of studies that didn't find decreased "bug density" in open source repos using statically typed languages, but there've also been studies that found the opposite, and in any event the methodology behind all of these is dubious. Example saga: [https://hillelwayne.com/post/this-is-how-science- happens/](https://hillelwayne.com/post/this-is-how-science-happens/))

<comment><USER54> I disagree it's a strong claim. I think the claim that strict functional programming or type system enforcement of safety has no data supporting it significantly improves anything (defect rate, speed of development, security, etc.).

The strong claims come from evangelists of those extreme programming paradigms. You should be asking _them_ for proof that consists of more than anecdata.

It's backwards to say that essentially what is a historically validated null hypothesis with 50 years of development history on its side is "a strong claim" that requires special evidence, while giving a free pass to all the people using little more than blog posts and slick syntax to claim these extreme design patterns are demonstrably better.

If they are so much better, where are all the companies getting free lunches just by switching to these tools? How is it that the entire industry is so irrational that so few companies are willing to switch?

Superior ways of working catch on very fast, just consider the radical adoption of GitHub and no-sql data systems. Why is strict functional programming not seeing that? What mental gymnastics does it require to take as a premise that strict functional programming is "better" yet adoption rates are super low and successes are not proved with data, only anecdotes?

<comment><USER27> > It's backwards to say that essentially what is a historically validated null > hypothesis with 50 years of development history on its side is "a strong > claim" that requires special evidence

I really don't see your point here. Are you suggesting that because people have been able to write software in C for 50 years that type systems aren't useful? Because it's not like those programs are bug free. It also doesn't take into account how much effort is need to build and maintain that software.

Also not really sure what you're getting at about strict functional programming. This post was just about type checking.

> Neither will Haskell, Rust, etc.

Rust is really in no way a functional language.

<comment><USER54> I don't see _your_ point. What does the bugfreeness of historically used approaches have to do with it. The new kids on the block have to _prove_ they are better in some tangible way. The onus is not on established programming languages to prove anything.

As far as evidence is concerned, you're not going to solve problems faster, safer, cheaper, more reliably or more extensibly with Rust or Haskell than you are with C or Python, apart from some very niche exceptions.

That just an empirical observation, not an opinion.

<comment><USER27> > The onus is not on established programming languages to prove anything.

Why is there no onus on "established" programming languages (whatever that means)? It's not like production software hasn't been shipped in Rust, Haskell, OCaml, etc. Just because C is older it gets a free pass?

> As far as evidence is concerned

I would argue there's plenty of evidence that languages with better type system are valuable. What we don't have is _proof_ , but that's because nobody has figured out how to do the experiment(s).

<comment><USER55> No, it's because _either_ nobody has figured out how to do the experiments, _OR_ because their hypothesis is invalid and they merely haven't _dis_ proven it.

<comment><USER27> Sorry, I worded that poorly. What I should have said is that we don't have proof/disproof, because nobody has figured out how to do the experiment(s) needed to get there.</comment></comment></comment></comment></comment></comment></comment></comment>


How many cows does it take to make a burger? - <AUTHOR> http://www.economist.com/blogs/freeexchange/2009/10/the_world_is_flat_kind_of_gros.cfm <comment><USER2> I assume you mean "How many cows does it take to make a hamburger?" A good question with a disgusting answer. According to the same NYT article on the E. coli-ridden burger that paralyzed a children's dance instructor, "a single portion of hamburger meat is often an amalgam of various grades of meat from different parts of cows and even from different slaughterhouses." Sources vary on the precise number, but on average they report that in a single burger there are parts from 50-100 distinct cows. That number ignores the pieces of still other cows ground into the food eaten by the cows in the burger.

Better answer: Zero! Eat delicious veggie burgers instead.

<comment><USER3> "Delicious" is certainly up to interpretation. Additionally, if "meat is murder", then why so many "fake murder" products?

I don't really see what the issue is with the article. So hamburgers are a homogeneous mix of meat from multiple cows. I never had deep-seated convictions that they only came from one cow in the first place. Does a bag of frozen vegetable medley come from one plant? Does it even come from one plant per type of vegetable?

<comment><USER4> The significance of a hamburger being comprised of many different pieces of multiple cows is that it's hard to track and there are higher-risk meats than others. For example, meat that resided near the intestines/colon has a much a higher risk of e. coli contamination.

Honestly, I'm with you in my lack of concern, but probably for a different reason. It is a very small justice that meat-eaters should get e. coli from time to time.

<comment><USER3> not adhering to handling standards is a different issue than "mixing meat from different parts of the cow and different cows". And if you're going to act like that, then it's poetic justice that a lot of vegans are malnourished.

<comment><USER4> How would it be "poetic justice" for a vegan, who cares for other living things, to be malnourished? They're just being _not evil_. Of course, being vegan has all kinds of eprsonal health benefits in addition to its benefits for others. Vegans have significantly lower rates of cancer and heart disease, for example. Maybe you're one of those people who think that being trim is equivalent to being malnourished. It isn't.

On the other hand, one who pays another to torture and slaughter living creatures for his own discretionary meals is indeed making a withdrawal from his/her karmic balance, if you will.

</comment></comment></comment></comment></comment><comment><USER5> You know what's sick? The fact that we slaughter 10 billion sentient, thinking animals in the United States each year. And then we have the nerve to be appalled that a tiny sliver of that suffering is transferred to humans. There are not enough words to describe how misguided we all are.

<comment><USER3> I really don't think you can fairly call cows sentient. Along with chickens and turkeys, they are some of the dumbest creatures around. They're barely more than walking vegetables.

<comment><USER6> I had to reply as I accidentally upvoted you.

I don't want to get into meat vs veg, but considering meat as "walking vegtables" is inhumane thought.

Have you spent some time with any animals? Go spend some time with some hens/roosters and their chickens. spend a day watching - watch how the mother hen teaches her chickens to hop over obstacles and the chickens trying to find the shortest path to hop over. Watch how each individual chickens have their own personality. Watch the roosters personality - dominance/sexual drive...

My maternal grandfather had cows back in India. Every cow would respond differently. He would talk to them, The calf would listen to him(when he would milk the cow, the calf would get impatient for mumma's milk). One of the cows wouldn't allow anyone other than my grand mom/grandfather to milk her.I have more anecdotes, which helps me in connecting them animals and us animals.

So much for walking vegetables!. Perhaps you are just visiting here. Perhaps you are here for the long run, but imho, please spend a _lot of time_ reading here(searchyc for archives) before commenting.

<comment><USER7> A rat will nurture their young far more than a chicken, is much smarter, and will display more personality than a chicken ever will. OTOH, if one shows up in your kitchen I am sure you will be on the phone to the exterminator in minutes. Just because a chicken or cow is cute does not make it "special" and anthropomorphizing the activities of that animal is a pretty weak argument.

<comment><USER8> Nobody on this forum has argued for granting other animals moral consideration based on cuteness or anthropomorphism. I didn't see anyone elevating anything else over rats, either. Farm animals and rats intrinsically deserve not to be tortured.

<comment><USER3> Torture was never mentioned by anyone other than the anti-meat crowd here.

<comment><USER8> That might be because we're the only ones here who are willing to call it what it is. Meat-eaters may not want to admit that they are most often supporting unbelievable torture -- a human's worst nightmare, in fact.

Obviously, the issue of torture is implicit in discussions of meat-eating in our time, as the vast majority of meat has been tortured before it's been eaten.

<comment><USER7> There is a difference between pain response and suffering. The latter requires the consciousness to know what the future has in store for the organism. Animals can be abused, but very few of them have the level of consciousness required for the abuse to be "torture." You can pretend that animals are people too all you want, but wishing it to be true does not make it so.

<comment><USER8> evgen,

You are completely wrong when you say "very few of them" have the level of consciousness required for the abuse to be torture." All factory farmed animals are tortured physically and psychologically -- tens of billions the world over. The vast majority, if not all, of lab-tested animals are tortured physically and psychologically.

You have no idea what it is to be tortured (not that this is required to take those who have been tortured at their word). If you did, you wouldn't dismiss the torture of those with very similar central nervous systems to ours so lightly. And the fact is, torture of human animals can bring out all the fight or flight evolutionary responses and fears we have within us as a result of our completely animal history and existence. Your cavalier approach to the tremendous suffering of others is a disgrace.

Once, again, you are trying to draw arbitrary lines based on what you want to be true to justify your own behaviors, which are morally indefensible. Do the research for yourself, since you don't want to listen to reason from anyone else.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Creating Cellular Automata: Elementary Cellular Automata - <AUTHOR> http://nicholasyager.com/research/2014/05/03/cellular-automata.html

<comment><USER2> An interesting introduction. So much online writing is just that, the opening introduction leaving one wondering where the rest of the text has gone. For wandering minds this is generally Ok; the springboard has been set but I wonder if this constant stream of unfinished stories takes a toll.

<comment><USER3> If you have the time, there is a good Coursera course on the domain: [https://www.coursera.org/course/modelthinking](https://www.coursera.org/course/modelthinking)</comment></comment>


Pocco: Python port of Docco (literate-programming-style documentation) - <AUTHOR> http://fitzgen.github.com/pocco/

<comment><USER2> Oh hey! This is my project! (Actually its really Jeremy Ashkenas', I just ported it to Python).

Please fork it on GitHub and make it cooler!

</comment><comment><USER3> It's an interesting approach, and might make you more inclined to write documentation -- as it is less hassle to do so. But the end result isn't very readable, the text ends up being an API reference disguised as something else.

I prefer a "literate testing" approach, where you mix documentation with doctests. It's easier to tell a story when you show the reader what your API _does_ , instead of its internals. And you will never have to worry about keeping the examples up-to-date with your code if you make them doctests.

</comment><comment><USER4> How would i be able to add the comments on the left? So far, i was only successful in generating the source code on the right.

<comment><USER2> What language are your source files in?

Python, Ruby, Scheme, Lua, and CoffeeScript should all be supported (but it doesn't play nice with /* */ style JS, just //).

All code comments that are on their own line should become documentation on the left, for example:

        # This should become docs
        def this_is_the(code):
            ...

Take a look at the raw file on github, and compare it to the generated file: <http://github.com/fitzgen/pocco/blob/master/pocco></comment></comment>


Ask HN: Copy and paste on any device - <AUTHOR>

I find myself most of the time needing to copy a piece of text or even a link from my mobile and paste later (when I get out of the bathroom) on my PC.
Do you have the same problem? What are you using to solve this?
Thanks <comment><USER2> Good questions! I know what you mean. For websites urls, I find myself using Chrome's 'other devices' menu (at the bottom of a new tab). This of course only works since I'm logged into Chrome with my G account on all devices.

For real ctrl-c stuff, I have to admit I reside to workarounds that are far from ideal.

<comment><AUTHOR> Chrome other devices is good (used it for a wille) but I use really like to use Maxthon on my mobile

</comment></comment><comment><USER3> Use a paste service like pastebin.com or hastebin.com (you can self-host haste-server -- <https://github.com/seejohnrun/haste-server>)

<comment><AUTHOR> Very repetitive, I copy the text open paste bin paste it then go to my pc open paste bin copy if from there and paste it where I need it. I want a seamless integration that will hopefully be as simple as CTRL+c / CTRL+v

</comment></comment><comment><USER4> OneNote

[https://play.google.com/store/apps/details?id=com.microsoft....](https://play.google.com/store/apps/details?id=com.microsoft.office.onenote&hl=en)

</comment><comment><USER5> I paste it to the cloud so i can access it from everywhere.

<comment><AUTHOR> How? what app are you using?

<comment><USER5> No app. Just a simple website i run on my own server, where I can paste stuff.

You could use any of the quadrillion webservices instead. Any blog service like tumblr will do.</comment></comment></comment>