'I'm not having children because I want to save the planet' - <AUTHOR> http://www.bbc.com/news/av/stories-43699464/i-m-not-having-children-because-i-want-to-save-the-planet <comment><USER2> Every time I hear a rational, intelligent person expounding why they decided not to procreate, I have to think about the opening scene of Idiocracy: [https://www.youtube.com/watch?v=YwZ0ZUy7P3E](https://www.youtube.com/watch?v=YwZ0ZUy7P3E)

Don't get me wrong, everybody is free to make their own decisions (and I would be the last demanding from anybody to go through parenthood), but sometimes it seems as if intelligence is not an evolutionary advantage.

There are whole subcultures of people who spend their life breeding, while especially the DNA lines of intelligent, working women just seem to end there. And it does not help that there are all these seemingly rational argumentation lines against children, e.g. about environmental impact. If you can pass on your education (and maybe some intelligence-related DNA), it may help society more overall in the end. Think of a big birthday party of an educated grandparent you may have visited - this procreation thing is an exponential function.

<comment><USER3> I get it. But it's their children battle. (Not to mention that Idiocracy is not coming, general intelligence seems to be not decreasing, despite the claims to the contrary.) Why should the people who decide not to have kids be held responsible for the failure of evolution? They didn't invent or promote the mechanism..

In my view, to say "you should have kids because then stupid people will win" is as much a rationalization to have kids like "I do not have kids to avoid environmental disaster" might be a rationalization for something else.

<comment><USER2> I'm not blaming anybody, everyone has freedom to decide. It is better to be no parent than a parent who never wanted to be in this role.

I want to point out that the evolutionary mechanisms are always active, and intelligent humans rationalizing against procreation (something that primarily educated humans seem to do) are part of the evolutionary game.

</comment></comment></comment><comment><USER4> Hm. I always think these statements are a bit weird and somewhat trying to hide something else.

I don't want children because I really don't want to have children. I think children are a ton of work and I really don't think I'd get enough out of it to make it worth the investment. It's a bit of a rational look at things, but that's how I feel about it too. Being gay complicates the whole process anyway.

I often get weird responses from people if I tell them this, as if I gave them a slap in the face, so I get why people would hide behind the environmentalist point of view.

<comment><USER5> I think age, or the stage of life you are at changes the way you think about these things radically. The same way we think we know everything when we are in our teens and the whole "adult" world is clueless. When we are young adults (20 to 35) we tend to think we will never want children, but some people later find that they change their mind. I personally believe you should follow your natural instincts (easier said than done).

<comment><USER6> I fully expect life at advanced age to be more fulfilling with children than without. Even complaining that they never return your calls would probably beat asking unpleasant what if questions. But is that really worth adding a multiple of your personal footprint to the problems of _all_ future generations?

</comment></comment></comment><comment><USER7> "Don't have a lot of kids, it's bad for the environment" is an objectively pro-dysgenic argument.

People with a low IQ will not understand the argument and no one with low conscientiousness will care about it. "Don't have kids, for sustainability" is just an argument that the children of low-IQ low-conscientiousness people should inherit the Earth.

It's an unsustainable practice. It's also the answer to the commentor below asking, _" If you're not having children, who are you saving the planet for?"_

Smart people need to have more children. Areas of the earth that pollute terribly by dumping garbage into rivers, etc, need to stop. Rich nations need to stop feeding poor nations until they have refugee-creating population explosions, and people need to get over how mean that sounds if they actually want to save the planet.

<comment><USER3> > "Don't have kids, for sustainability" is just an argument that the children > of low-IQ low-conscientiousness people should inherit the Earth.

I'll play devil's advocate and say, maybe they should. Who do you think has a lower ecological footprint - a homeless alcoholic or a successful scientist? There is even a theory that posits that intelligence evolved in order to increase entropy faster.

I have nothing against intelligence; it's a gift, as far as I can tell. But the claim that intelligent people (with few exceptions) are somehow going to live more sustainably is just ridiculous.

<comment><USER8> I don't think it's ridiculous. Assuming that one component of "intelligent behavior" is the ability to think "further into the future," that is, not purely beholden to feeling good in the here and now, intelligent people are more likely to make more sustainable choices (if only for their own sake).

</comment></comment></comment><comment><USER9> If you're not having children, who are you saving the planet for?

<comment><USER10> Animals, plants and other beautiful things. Saving it for life in general does not sound too bad? If it goes between leaving a dead rock in space, or keeping this lively rock around albeit without humans, that does not sound too bad. You can turn your question upside-down. Why should there be humans around to enjoy it in order for it to be a thing to strive for?

<comment><USER11> Earth's gonna get hit by another big meteorite at some point. When we get to that point, any species that hasn't been lifted off the planet by humans (or whatever equivalent is around at that point) are gonna be wiped out regardless. We're the best hope for a continued existence in the long run, for all life.

And if the argument is that animals are happier without humans around, you should watch some nature documentaries. Nature is brutal.

<comment><USER12> Even without meteorite: 1 billion years from now the Sun will output enough energy to make it a lot less enjoyable.

5 billions years from now the Earth is no more.

So long term if you want Earth based life to endure you need it to start getting the fuck out and spread. At the moment it seems the best positioned for this are humans.

</comment></comment></comment></comment><comment><USER13> _" having one fewer child (an average for developed countries of 58.6 tonnes CO2-equivalent (tCO2e) emission reductions per year), living car-free (2.4 tCO2e saved per year), avoiding airplane travel (1.6 tCO2e saved per roundtrip transatlantic flight) and eating a plant-based diet (0.8 tCO2e saved per year)."_

[http://iopscience.iop.org/article/10.1088/1748-9326/aa7541](http://iopscience.iop.org/article/10.1088/1748-9326/aa7541)

[https://motherboard.vice.com/en_us/article/3kn5z9/stop- telli...](https://motherboard.vice.com/en_us/article/3kn5z9/stop-telling- people-not-to-have-kids-to-save-the-planet)

<comment><USER14> From the study :

"For the action 'have one fewer child,' we relied on a study which quantified future emissions of descendants "

Now imagine people taking the plane, say 40 times in their life : 40 _1.6 = 64 and living car free half during, say 40 years : 2.4_ 0.5 * 40 = 48 => total = 64+48=112.

So by changing the way of life, you can make _as much_ as your "one child fewer" proposal. What I say is that the "one child" scenario is not much better than changing the way we live.

<comment><USER15> And very piously hope that the said children will be as ecologically minded, because society as it is is definitely not going that path. Everything in society will encourage away from a simple life.

</comment></comment></comment><comment><USER16> I used to work with a guy who said he used to have this mentality, and now he's older and childless, he deeply regrets it.

<comment><USER17> There are also a lot of people who regret having children, which causes a lot of misery too. Children are certainly a gap-filler for a lot of people, but imo there's nothing wrong with being content with other people having them, and plenty of ways to interact / benefit from them (aka "society.")

</comment></comment><comment><USER18> Save the planet? Its what humans are doing on the planet rather than having more humans, just because a small number of people dont want children to save the planet is not going to stop all the other humans from polluting it. Its an ineffective solution, its better to have fewer children and educate people on meat pollution and carbon output.

What I fear most is intelligent people having fewer children creating a even dumber society.

</comment><comment><USER19> Why people are so short sighted and focus only on the numbers instead of seeing the root cause?

The root cause is how we live and treat our enviorment, our society with it's consumerims uses mostly non regenerable energy sources to produce mountain of useless junk that breaks fast or it's out of fashion, driving big polluting cars and eating lots of meat that leads for deforestation to provide land for the crops that are eaten by billions of animals that are slaughtered every year and many other irational things the modern man is doing to it's planet, it's home.

Reducing the numbers while keeping this insanity going will no help much, it will only slighly delay the inevitable.

</comment><comment><USER20> Save the planet for whom?

I guess I should appreciate when people choose to leave more resources for my DNA to exploit. I plan to make the most of the sentience that my genetic ancestors wrested from the muck.

</comment><comment><USER21> Why on earth is the decision of a random woman not having children on the BBC?

<comment><USER8> Headlines and articles essentially identical to this one have occurred a number of times throughout the years, like you point out, largely focusing on one person or a small group of people.

I'm unsure how much viewership and engagement they expect to get from these articles, but they obviously think it's a story that other people should at least read (if not live by). At the expense of other matters, naturally.

</comment></comment><comment><USER22> According to this: [https://en.wikipedia.org/wiki/Tragedy_of_the_commons](https://en.wikipedia.org/wiki/Tragedy_of_the_commons)

She won't save the planet acting this way

</comment><comment><USER23> 100 billion could, without problem, live on this planet using nuclear energy and vertical farming.

<comment><USER24> 100 Billion, all farting at least once a day, and you might have the biggest global warming ever.

</comment></comment><comment><USER25> Well if she finds having children not to be attractive, that's fine. But I doubt that further decline of birthrates in the West will stop overpopulation.

<comment><USER26> Overpopulation isn't ultimately the problem, but rather over-consumption of finite resources. If people consume resources in an unbounded way, then population doesn't matter. The energy consumption of someone in the US is roughly 30x that of someone in Bangladesh for instance. With advances in technology, particularly in automation, we will be able to industrialise to a greater extent, and consume more.

</comment></comment><comment><USER27> It's an interesting question of whether someone (e.g. my future childhood)) will produce more value than they consume.

Obviously, selfishly, my own child is inherently invaluable to me. But that kid could also grow up to make a positive change in the world, or at least make the change which leads to a positive change in the world.

On the other hand, consumption in Western countries is already and increasingly way too far in excess of what's necessary or healthy. So if my kid ends up simply getting by in life, even raising them to be "eco-conscious" wouldn't be nearly enough to offset the normal bite each person takes out of the environmental pie. And that's just trying to break even.

I'm optimistic about this and do plan on having kids, but the goal is to raise them to make a real positive change in the world, at a high level. That way the cost they incur on the world will be seen as a worthwhile investment, not a waste of resources!

</comment><comment><USER28> Unfortunately this amounts to unreciprocated virtue. Ultimately I believe all the demographic optimism will be confounded as we are effectively selecting for women who are broodier (and similar for men). Having met women who 'just love' the feeling of having a baby inside them. It's not something learned.

</comment><comment><USER29> Millions of species flourish and procreate without destroying the planet. Their populations rise and fall in harmony with other species and the resources nature provides. Only one species is destroying the planet, and it's not because we're acting like animals (procreating and such).

It's because we're acting like humans.

We grow food where it's not supposed to. We survive disease, natural disasters, shortages. We live too damn long—not only as a species but as individuals. Think of one natural check or balance we haven't either turned off or are actively working to. Even minor inconveniences like boredom or unwanted facial hair we're putting coal to flame to destroy.

If you want to save the planet, have lots of babies, live a simple life, and die young. And if you're wondering where I got this from, watch Disney's The Jungle Book. It's all you need to know.

<comment><USER30> > die young

No thanks, I'll just not have babies.

</comment></comment><comment><USER31> Fine, but people that don't give a shit still reproduce. Result: More kids that don't give a shit, and less that do.

She could better have 10 kids, so her kids can "out-vote" the kids that don't give a shit, and they can put their head together to make a real change.

<comment><USER32> If voting habits were genetic we could replace natural selection with electoral selection. In a sense, Europe experimented with that in the first half of the 20th century, didn't go well.

</comment></comment><comment><USER33> To think one persons' action on not having one or two kids will save the planet. Must think highly of themselves to think it will make a difference.

<comment><USER34> Do you recycle?

<comment><USER35> Do you recycle anything other than tin and glass?

<comment><USER36> Yes? Newsprint, cardboard, plastic, metal, coloured glass, clear glass and food waste go into seperate containers. Also batteries and lightbulbs are collected seperately.

<comment><USER35> Congratulations. Outside of tin, and glass, most things on that list take more energy to recycle than to just grow and/or extract from the ground. Keep that good-feel-but-otherwise-non-ecologically energy flowing.

</comment></comment></comment></comment></comment><comment><USER37> Intelligence and conscientiousness are > 50% heritable. Political attitudes, including environmentalism, are also highly heritable. Adult intelligence is between 70-80% based on genetic factors.

Articles like this are encouraging the most intelligent and highly conscientious of us not to have children and, in the long run, will destroy the planet rather than save it.

The right attitude is one of stewardship: we have a sacred duty to preserve the planet and a sacred duty to produce intelligent, thoughtful children to enjoy that planet and to carry on our work.

</comment><comment><USER38> We should develop a model, but wouldn't it be more efficient to have children and educate them rather than letting others influence our future?

</comment><comment><USER39> I missed that opportunity. Now my only option is to populate earth (mars and everything else if possible) with better humans than i am.

</comment><comment><USER40> Just making up to 2 children is having a similar impact. 2 is just bellow population renewable rate. Is everybody was having 2 children world population would slowly shrink.

The real deal nowadays are people having 3 or more children. Once you realize that we are consuming 1.5 times what the earth can renew every year, it is a complete non-sense to make more than 2 children.

</comment><comment><USER41> HCOL areas probably make this viewpoint more common than it otherwise would be. It's hard enough living in Bath as a couple on the median wage, and having children makes things very difficult financially.

Choosing between living in a really nice city and having kids is a difficult choice.

</comment><comment><USER42> Good job, more space for people who don't care about the planet or anything outside their tribe

<comment><USER43> That's what I'm thinking, my 7 year old is very pro environment. It's easy to offset his carbon footprint as a child and he's been interested in conservation from a young age. 10/10 would recommend

</comment></comment><comment><USER44> I'm not having children because they are awful creatures, and even worse the grow up to become adult humans.

I am doing it for selfish reasons, it's cheaper not to have them and the entitled shits would never look after me in retirement, so why bother?!

<comment><USER24> We are the result of our choices ;-)

</comment></comment><comment><USER45> I negotiated with my wife to only have biological children below the replacement rate barring unexpected twins, etc. If we want more kids than this, we will adopt.

</comment><comment><USER46> Are there a disproportionate amount of people in the tech industry that end up making this decision?

</comment><comment><USER44> [http://vhemt.org/](http://vhemt.org/)</comment>


Reusing Old Hardware - <AUTHOR> https://www.honestrepair.net/index.php/2018/10/24/reusing-old-hardware/ <comment><USER2> The author is not wrong, there is a lot of old hardware out there that is still more than serviceable for many things. But the loaded cost (power, maintenance, space, etc) of running servers at "home" can be way more than the $10 a month for a droplet on Digital Ocean.

What I'm saying is that the math isn't as straight forward as it might appear.

That said, it is now pretty straight forward to build a 'nano-datacenter' consisting of an enclosure, thermo-electric cooling, rack, switch, UPS, a server providing NAS storage and a couple or 6 servers providing compute. Plug its PDU into the socket where your dryer used to plug in out in the garage.

<comment><USER3> Indeed! I used to run various services on my older generation hardware, but I realised that I was spending more than $70 a month on electricity to do so!

It's much cheaper using a couple $5 VPSes for services. The only hardware left at home that is on 24/7 is my NAS, which is because 20TB of storage costs too much in the cloud.

<comment><USER4> Have you considered Google Suite? [https://gsuite.google.com/](https://gsuite.google.com/)

You'll need a domain name to associate (and handle email, etc), and while technically you need 5 users to have unlimited storage, at the moment it doesn't seem to be enforced and a single user does have it.

Currently I'm storing ~50TB for $10/month. At this price and having 100Mbps Internet connection, I only turn on the NAS for local backups.

<comment><USER5> That's great, but what happens when Google kills the offering or suspends your account for violating their TOS?

</comment></comment></comment></comment><comment><USER6> Sadly many of these old beige boxes weren't very well designed for efficient low power consumption. Always ask yourself whether a Raspberry Pi style platform, or even a jail-broken old phone couldn't run that workload just as well on a fraction of the old banger's power budget. Most often the answer is yes.

<comment><USER7> out of nowhere : is there any effort to build/tune linux kernel (or gnu/linux os) so that it consumes the least energy possible. (besides powertop and alike).

<comment><USER8> [https://wiki.ubuntu.com/Kernel/PowerManagement/PowerSavingTw...](https://wiki.ubuntu.com/Kernel/PowerManagement/PowerSavingTweaks)

</comment></comment></comment><comment><USER9> I really would not say that a 2007 Xeon is in any way comparable to something newer. Something that old is just a waste of watt-hours.

But if you skip forward a few years, a 2012-2013 quad socket, eight core Xeon machine that was many thousands of dollars is still quite useful. If you want to lab your own xen or kvm hypervisor stuff on a machine with 32 cores and 256GB of RAM you can do it for under $1000, if you know where to look, and can tolerate a 500W load addition to your electrical bill.

<comment><USER10> I've been planning to buy a used high-end Xeon server circa 2015, harvest the CPU's and RAM, stick them on a workstation motherboard and add some silent cooling solution. That way i'll have a 20+ core, 128+GB workstation for about 2k euro.

Electricity and heat is no issue for me as electricity is included in the rent of my office, and we currently use electric heaters to keep the office warm...

<comment><USER11> Couldn't you build a low-end threadripper or really nice Zen system for less with far more power?

<comment><USER10> Haven't done any research yet, but it wouldn't surprise me if a 2 year old high-end Xeon outperforms a low-end threadripper on my typical workload.

Also: a 2 year old server can be bought for about 1k, you can't get the core count and amount of RAM new for that price.

</comment></comment></comment></comment><comment><USER12> My take on this is a small SmartOS cluster running on 3 x Thinkpad T430s - each with the DVD drive removed and two SSDs installed as a ZFS mirror.

The whole cluster idles at 150 watts and each node is backed by it's own dedicated battery. Upstream I have about 4 hours on an APC unit which also protects the router and modem from outages.

My own little cloud for under $1,200.

<comment><USER13> Nice.

Do you have any guides you wrote or used that you can recommend? I'm looking at getting SmartOS set up at home as well, but I know I've got a lot to learn.

<comment><USER12> It sort of just works. Get yourself a big USB thumb drive (I use 8 and 16G) and boot off it. You'll answer a few questions to install.

I like the Thinkpads because they are so cheap ($200-300) gets you an i7 and 8-12GB RAM. The CPUs are compatible with SmartOS for KVM guests.

All that said, I really should write a definitive guide of how to operate SmartOS coming from the linux ecosystem.

</comment></comment></comment><comment><USER14> The main issue with repurposing random x86 hardware is power. This means that anything NetBurst based is just garbage, but on th other hand random Core2 based corporate SFF desktop (which you can get for less than 40EUR) is perfectly serviceable as home internet gateway/whatever server. You want SFF desktop because it is designed to be reliable, it is usually cheap and relatively quiet.

<comment><USER9> Anecdotally I see companies throwing out dell and hp 4th gen core i5/i7 sff desktops from 2012-2013, straight into electronics recycling, all the time now. One of those with 8GB of ram makes a totally fine Linux workstation.

</comment></comment><comment><USER15> The part comparing "Intel Xeon E3 1320 V6" [sic] with older "Intel Xeon E5620" as having the same memory bandwidth, same TDP, more L3 cache, etc., so having "the same performance characteristics" is just plain crazy.

1\. Xeon E3 1320 never existed. Was it meant to be 1230?

2\. Does DDR4-2400 really have "the same performance characteristics" as DDR3-800 (even after accounting for having 3 channels instead of 2)?

3\. How can a 3.5 GHz processor be "the same performance characteristics" as 2.4 GHz one (1.5x more)? Add IPC on top of that.

<comment><USER16> 3) GHz cannot be used as a speed comparison outside of the same generation of CPUs. A 10 year old 3.5GHz gets nowhere near the same compute power as a modern day 2.4GHz.

<comment><USER17> For a lot of basic operations, this is often false.

I have an application I'm working on and tested it across three different generations of CPUS going ~10 years back.

The code was written in C and the fundamental steps were to: mmap() two arrays of structs from a sata 3 SSD, compare the two, and write the intersection to a block of memory. The data size of each array was multiple gigabytes and the operation took more than a full second.

The ~10 year old low powered Xeon L5640 beat the higher-speed ~5 year old Xeon E5-2667 v2, and was only slightly beaten by the 3 year old i7-4790k. In short, they all ran at roughly the same speed.

I would say that this is because of the limits of the SSDs, but then I tested by holding that data in memory rather than disk, then ran the intersection. Same result.

This is a very basic operation that tests the performance of the CPU and memory. And for operations like these (ie: not using SSE2, AVX, etc), the perceived performance difference to the vast majority of people for a secondary home machine may be negligible.

<comment><USER18> That really depends on your load. I once feared a huge performance regression when a test took 2 minutes instead of 40s. Turned out one instance ran on a i7-6xxx machine, and the other on a i7-9x0. Normalizing for the different clock, the newer CPU had a 20% better IPC.

Disclaimer: I don't recall exact numbers, but they should be somewhat close to those given.

</comment></comment></comment></comment><comment><USER19> Reusing old hardware is all fun and games, but please remember to make regular, offsite (online!) backups of your important stuff. Hardware will fail at some point, and I'm not even talking about the obvious risk of house fires/flooding...

<comment><USER20> This. Having old hardware running various services in the basement is handy, saves money (unless they use a ton of electricity), but the second stuff breaks down you will be screwed unless you have a backup somewhere.

</comment></comment><comment><USER21> The site is "currently unavailable in your country", I can't even read the article. Tell me about openness.

<comment><USER22> Have fun: [http://archive.is/v25ID](http://archive.is/v25ID)

</comment></comment><comment><USER23> I have an old IBM System x3550 M3 running in my attic.

It cost me $50 + a new ssd. It's been great fun to play with. 12Gig of ram and 16 threads so it can do more than enough for me. I found it a bit slow for game hosting but for the price I can't complain.

I also have a couple of cheap VPS, but having a server on the same network is much snappier and I can throw large files around with ease.

</comment><comment><USER24> I love old hardware. I have a Pentium II box I've been upgrading for fun. It dual boots Win98 and OpenBSD from two CF cards, and can serve many contemporary application stacks. It's enjoyable knowing these big old chips can still turn out a lot of functionality even if it's just recreational.

<comment><USER25> What do you use windows 98 for? I always loved the os and have a box that runs an nes emulator.

<comment><USER24> Sorry for the late reply.

I adore Windows 98. I spent most of my time on 95 but 98, especially SE, really polished the experience on a then-modern OS.

I mostly use 98 for nostalgia sake, playing old games, testing old software, and observing how things used to be.

I find it fun to firewall it off and connect to the internet with IE and old Firefox versions - finding what works and what doesn't. It helps provide some perspective and entertainment. It's incredible how interoperable Win 98 can still be with your modern devices.

Eventually I'll upgrade the Pentium II to an AMD K6-2 and see how it goes!

</comment></comment></comment><comment><USER26> This is what they give me instead of any page on their site:

"OOOPS… We're sorry for the inconvenience,

It looks like HonestRepair accounts are currently unavailable in your country, but keep checking back!"

Way to go. Not in the countries we like? You can't even read our blog. Go away.

</comment><comment><USER27> My new HDD started having problems in just 1.5 years.I just salvaged an old HDD from my dad's 9 year old laptop (Dell Vostro) and used it.

This old laptop is what I would go to whenever I was between laptops. It's a C2D, 4GB RAM. I installed debian with i3 and it was good enough for browsing internet, to do random coding stuff, reading PDFs, watching movies (although it would run hot). Also I played a lot of Roller Coaster Tycoon[1] on it. Man, I love RCT!! I just might plug in an SSD in it during the next windfall.

[1]: [https://github.com/OpenRCT2/OpenRCT2](https://github.com/OpenRCT2/OpenRCT2)

</comment><comment><USER28> Anyone know what happened to Edna? Hasn't been updated in years unfortunately & I'm wondering if it's still safe to run online. [https://github.com/thedod/edna](https://github.com/thedod/edna)

It looks like AudioStreamer that OP listed but I prefer to play my music with vlc (or whichever 3rd party player)

<comment><USER28> oh so I found this, anyone tried it?

[https://github.com/thedjinn/nedna](https://github.com/thedjinn/nedna)

</comment></comment><comment><USER29> I personaly use Chromebook C710 as my main computer. Works just fine with 6GiB RAM and stock HDD. Never liked cutting edge hardware.</comment>


Years and lessons working at ThoughtWorks - <AUTHOR> https://www.thekua.com/atwork/2016/04/12-years-12-lessons-working-at-thoughtworks/ <comment><USER2> I love reading "lessons learned" type posts.

The ones I like best here are:

#5 Architects make the best decisions when they code. Amen.

#10 Appreciate that everyone has different strengths - that's how a team becomes more than its parts.

Here are my lessons learned from 25 years of SW development: [http://henrikwarne.com/2015/04/16/lessons-learned-in- softwar...](http://henrikwarne.com/2015/04/16/lessons-learned-in-software- development/)

<comment><USER3> > #5 Architects make the best decisions when they code.

It's not just a matter of coding, it's about the right kind of coding.

I like to have architects be pareto-programmers, that is they get to 80% of of the solution so that they can hand off the rest to a less-experienced team member. They can solve the hard part of the problem without getting stuck making it productionized and provide an opportunity for mentoring.

There's two other code related tasks that are important: code reviews and commit reviews. They give views at different "heights". We have fairly good tooling around the former; I'd love a tool that gave me an email every morning that had X number of random commits distributed over the total committers as best as possible while showing me who hasn't committed for a while.

<comment><USER4> As a team member, pareto programmers are the worst. They do all the fun interesting work, then raise their hands and push the important work on the team. They refusw to take ownership of their features, create a mess for you to clean up because they certainly missed a detail or two, and just generally suck to work with.

The worst is when they say "This is your code man. I'm just helping you out a bit."

No. Finish the fucking feature so I can focus on my fucking feature without having to tripple check all your damn work.

<comment><USER5> I get your frustration, but I've also seen some pretty bad code where junior developers were given too much freedom to do the "fun, interesting" work. When concerns were raised during pull request reviews, the inevitable answer was "not gonna change it -- approve it now because my sprint is in danger".

<comment><USER6> You just hand them fun, interesting work that doesn't do too much damage to the company when it fails. In practice, this means that your most senior people end up doing work that is very interesting, yet very arcane.

I mean, anyone senior around here should know that it's precisely making something production ready, as opposed to just 'work in theory', is one of the hardest parts of software: Who hasn't seen some code that mostly works, but is operationally unusable? Something that works with 1 server, but when you put it in 20, it all blows up? It's not about the nice presentation, or the talk where you explain how you turned MongoDB into a queue, but about making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable.

The sad part is, the world is so full of powerpoint architects and projects that don't provide any real value that many people have never seen a system work right. And that's why we see tons of SV companies that are built around tire fires: Nobody in charge of anything has ever seen a system that we shouldn't be embarrassed of.

<comment><USER7> > _but about making a system that works almost all the time, but when it doesn > 't, it is not the end of the world, and easily fixable_

This is exactly where senior architects make all their money.

</comment></comment></comment></comment></comment></comment><comment><USER8> I worked with some ThoughtWorks consultants a few years ago, and I would say the author here is probably a diamond in the rough. This was a very good read.

ThoughtWorks needs to read this and particularly heed point #9. The primary goal of theirs during our month—or so—long consultation seemed to be to force a team of 40+ developers down a rigid and dogmatic path of TDD. They also advocated pair programming, but a lot of us (I'm extrapolating "a lot" from the unanimity of the few I was close to and talked to about this) felt like they were really just winging it; like they were apprentice developers barely learning the concepts of TDD and pair programming at the same time they were charging to purportedly teach us.

It was a frustrating and fruitless endeavor that taught our team basically one thing; don't work with ThoughtWorks again.

<comment><USER9> Ex-ThoughtWorker here. Pat is indeed a respected voice in this space, even amongst ThoughtWorkers, but he is not the only diamond. I learned pair programming and TDD from many colleagues over three years and four major projects. In all that time, there was exactly one individual whom I thought was a waste of space. On the whole, ThoughtWorks' typical approach to agile (note: lower-case 'a') development is firmly grounded in the pragmatics of what used to be called Extreme Programming, not Scrum-type dogma.

I'm sorry you had a bad experience in your brief engagement with TW. I believe it to be atypical, and I hope you'll have occasion to reconsider your -- not un-dogmatic -- conclusion.

</comment></comment><comment><USER10> ThoughtWorks hired me this month. The culture is _excellent_ and matches up with these 12 lessons. I'd add a 13th lesson about combining individual empowerment with teamwork.

If you're interested in working with ThoughtWorks, I'm happy to help and connect you with the right contacts. Email email@example.com.

<comment><USER11> Are they still traveling a lot at TW? I don't want to live in a hotel for 4 days a week, so I declined when they approached me.

<comment><USER12> Well, traveling really depends on project. But you can actually ask for non- travel project.

I would recommend talking to the recruiter and let them know your preferences before declining.

<comment><USER11> > you can actually ask for non-travel project

Interesting, thanks. At my current job they try to staff local as much as possible, there is no formal hierarchy and we also have 20% time, so my standards are high. Traveling too much would be a no go for me.

</comment></comment></comment></comment><comment><USER13> _Although not all pair programming environments are healthy, I do believe that when it works well, teams tend to have better collaborative cultures. Many developers prefer the anti-pattern of (long lived) branch-based development because it defers feedback and sources of potential conflict._

Ugh, such a false dichotomy. Does anyone actually think [http://nvie.com/posts/a-successful-git-branching- model/](http://nvie.com/posts/a-successful-git-branching-model/) is a good idea?

Instead, compare to any one of hundreds of successful examples on github, all using feature branch based models.

Thoughtworks (and other consultancies that take the CD book to heart) would have everyone pair programming and committing directly to master. This simply doesn't scale beyond a small team. It also actively discourages collaboration across teams, because there is no process in place to review external contributions.

<comment><USER9> "[P]aired programming is about optimizing for the team" (source: [http://goodrequirements.com/2013/pair- programming/](http://goodrequirements.com/2013/pair-programming/)). Long-lived feature branches optimize for the individual. A useful alternative is described at [http://paulhammant.com/blog/branch_by_abstraction.html](http://paulhammant.com/blog/branch_by_abstraction.html).

What is your definition of "small"? The projects I worked on at ThoughtWorks for over three years numbered in the dozens of developers, all pairing, and all committing directly to master.

</comment></comment><comment><USER14> I worked at place where they had multiple vendors work on the same project, client prbly din't want get locked in with one vendor.

Thoughtworks was one of the implementors and I was with another vendor. Thoughtworks had 'agile coaches' on the team who would dictate process and alienate anyone who wasn't from thoughtworks, only thoughtworks employees had access to their 'mingle' project planner where they would do all the planning. One of the main objectives of these 'agile coaches/architects' was to make sure they lock down this big client for future projects by integrating themselves deeply into clients processes and alienating everyone else. Their commercial products like mingle are explicitly designed with this in mind. Their 'take over' phase also involved binging in lots of young consultants who would work really long hours, most of them on my project were fresh college graduates from their bangalore/pune office bought overseas on L1 visas who work 12-14 hr days.

Anyone who questions them would be labeled not 'agile' enough and by extension a liability to the project. I left the project shortly because it was not my battle to fight. Employees who worked there associated agile with consulting company scam. It was disappointing to see agile methodology being coopted by consulting companies for their own ulterior motives.

Thoughtworks was just another consulting company who uses 'agile' to out maneuver their competitors. I always wondered why thoughtworks is considered to be different from other companies in the class like accenture/ibm. I've never used a product or opensource project made by Thoughtworks.

This was about 7-8 yrs ago so things might be different now, not sure if they still doing their agile stickh.

<comment><USER15> Atleast two signatories if Agile Manifest has stated that the movement has lost its way [1][2].

I think it never had a chance. With the old waterfall model, projcet managers had some power : they could continuosly interrupt engineers and ask them to do more and more since project went in one trajectory for years. They were justified since the engineers had plenty of 'downtime'. Engineers had some power, the project never changed direction and they could work out the design and implement it carefully, managing technical risk.

When Agile came along, the idea was to change direction every two weeks, but within the two weeks the team does not take on any distractions. I suspect this delicate balance of power was created, not out of a sense of fairness, but for efficiency. But when the people in power saw this they said : 'I will take these parts of the methodology that are useful to me and ignore these parts that are not useful'. Cue the 50 point stories, sprint abortions, mid- sprint story additions etc. Question the reasoning and you are labelled anti- agile. I suppose this was the only way it _could_ go.

[1] [http://blog.toolshed.com/2015/05/the-failure-of- agile.html](http://blog.toolshed.com/2015/05/the-failure-of-agile.html)

[2] [https://pragdave.me/blog/2014/03/04/time-to-kill- agile/](https://pragdave.me/blog/2014/03/04/time-to-kill-agile/)

<comment><USER16> " Engineers had some power, the project never changed direction and they could work out the design and implement it carefully, managing technical risk."

I've seen the opposite more often: Many a waterfall had poor assumptions made up front without a lot of technical risk management afterwards beyond "helicopter parenting" from architects.

Most successful agile teams I run into, engineers hold most if not all of the power to design and implement - the product owner wields ultimate power over function and priority.

"When Agile came along, the idea was to change direction every two weeks, but within the two weeks the team does not take on any distractions. "

That's Scrum's approach. Modern XP Shops I've tended to see adopt iterationless approaches, where there is a retro and planning session every week or so, but not really to recognize "iterations" per se. Features are delivered when they're delivered, deployments and releases are automated so they can happen whenever the product owner wants.

Biggest point of success, however is to eliminate project management as we usually know it. There's a product owner, and a product manager and they are usually an empowered customer paired with someone that knows how to build "products", ie. A focus on learning and testing rather than the certainty demanded of most projects. Project managers become at best glue players that protect the team from organizational antibodies.

</comment></comment></comment><comment><USER17> > People won't risk making mistakes if they feel they will do a bad job, lose > respect from their colleagues or potentially hurt other people in that > process.

This such an important and overlooked aspect to learning. Also one of the best things I experienced when working for a startup. For whatever reason I found the environment much more conducive to experimentation and failure. A working POC could change the direction of a project. Most things didn't seem possible anyway, so why not try?

Now at $BIGCO projects take a long time to start and are generally not full of surprises. A change in direction would probably be perceived as a negative of not thinking out your design more carefully.

</comment><comment><USER18> > Everyone can be a leader.

This seems like a naive point of view. In any real organisation people naturally form hierarchies, even if they're implicit and unstated. It's just human nature. Then if someone lower in the hierarchy starts to suddenly act like a leader they'll have other people who are notionally higher than them in the hierarchy stomp on them, quelling the usurper initiative in order to maintain their own position in the social hierarchy.

This is such a deep part of human nature that people don't even know they're doing it. It's well documented in psychology texts but for some reason people deny it happens in their own workplace. Yet I've observed it happening in every workplace I've ever been in.

<comment><USER19> Yep, I agree. In pretty much every organization I've worked in, some engineers are more equal than others.

If you're a golden child, you'll have praise heaped upon you for whatever you do. If you're not one of them, you can take charge and go above & beyond if you want... but probably no one will care. So at least for me, I really question the value of doing those things nowadays. I just do my work, try hard to do a good job, help out if I'm asked, and that's that.

The worst aspect of this dynamic is when you see one of the "more equal" people doing something that's going to cause pain and trouble down the road, but you know nobody is gonna listen. That's life as an engineer I guess.

</comment></comment><comment><USER20> If the author is reading this, the social sharing buttons on that page are very annoying. On my browser/resolution it covers up the first character of every line it touches, which makes reading the article without resizing the window nigh impossible.

</comment><comment><USER21> I believe TW can be a great experience for many devs. But hey, don't trust posts of their own people on the matter. This is a company where it's standard practice for big wigs to post not only technical content, but also "evangelising" stuff to attract other employees. Read glassdoor reviews from current/ex employees and check how it feels for you.

Some people love it to the point of religious fervour, while other hate it as if it murdered their mom savagely. So make sure it looks right for you before applying for a job there.

</comment><comment><USER22>
        Architects make the best decisions when they code

        In the Tech Lead courses I run, I advocate for Tech
        Leads to spend at least 30% of their time coding.
        Spending time with the code helps build trust, respect
        and a current understanding of the system. Making
        architectural decisions without regard for the
        constraints of the current system are often bad decisions.

I really hate it when people don't know the difference between an architect and a tech lead. I'm happy that you gave your tech lead a title bump if that's what you want to do, but there is a difference. If you have your architects coding you are wasting time and money. Hire another programmer and have your architect do what they are supposed to.

<comment><USER23> Titles and job roles vary enough across the industry that I'm pretty sure there isn't a canonical, obviously correct meaning to things like "architect".

<comment><USER22> I agree that job descriptions can vary. The article says "Architects make the best decisions when they code" and then goes on about having "tech leads" code.

In a startup the CIO / CTO can be coders (they may be the other partner in a 2 person company). But in a company that is 12 years old, they should be at the point that they have high level/high talent people doing those jobs.

So I would expect that they have a CEO that runs the company and a CIO that runs IT and architects that do systems / application architecture. Not spending a day and a half each week cranking out code.

<comment><USER24> The argument I imagine (and that I agree with) is that if you aren't in touch with the code you begin to lose touch (esp. in this fast-moving industry) and you become an ivory-towered twit that your teammates can't relate to and begin to resent.

I am a fairly experienced JS dev and I can't imagine retiring to a hands-off architect role in that world, because there are so many tool choices and options in terms of programming style (even languages that compile to JS), so I feel like I need to be regularly writing 'app code' to know how to advise my teammates well.

Saying 'though shalt write TypeScript and use these libraries, and these OOP practices, and structure your app in this way' would feel fairly obnoxious if I wasn't working with the team, with those technologies to write actual code myself. If my teammates instead wanted to do functional programming in Elm, and all I could offer was hypotheticals as to why that was a bad idea, I really wouldn't expect my teammate's respect, and would expect them to be quite-rightly put-out.

<comment><USER22> There is a difference between the two. As an architect you would need to keep up with what the different tool sets (compilers, transpilers, frameworks, database interfaces, etc, ) and what's going on in those spaces. Understand why your currently chosen toolset is working and where their roadmap is and how well your company is on that roadmap.

Whats the new universe of tool in your space, is one of them going to help you? Is it something you should pilot/plan for, keep an eye on or ignore?

You need to focus on that and figure that out. Having you work on tickets or new features isn't the best use of your time. Working out how it all works (and works well) together and where the holes are is your prime function.

Let's talk about the "Thou shalt". That's when you lead the education process. Why AstroScript is the way, what it will do, how it will work, how it scales, etc. You get some level of buyin and once that's done the team rocks and rolls in that effort. You want to help out with the first set of features fine, but once they get going let them go and get out of their way. You then look for the next thing down the road.

Hey your team wants to do Elm? Is that in the plan, have all the little nuances been looked at, does it scale, etc. etc. Yes, then go that way. No? Then it's up to you to either close the gaps with Elm or put the ship back on track. That's what architects do.

I understand people ending up as "white board architects". They suck, they happen. You can be "hands on", be an advisory, be a resource, be involved with the team. But you shouldn't be cutting daily code.

Lastly, I want to repeat that the original article is about a company that is 12 years old. Well past a few developers, a company that wants and should be on a growth path. Scout around and look at some Y successes that are $100+ million companies. Track their architect(s) down and ask what they do. If they are spending 30% of their time doing app-dev write back to me. Happy to treat you to dinner anywhere in Philly.

<comment><USER25> I like what you've written.

What are your lessons learned on how Architects should keep up (and avoid becoming whiteboard architects)?

My personal realization is that it is necessary to be hands on to understand new technology rather than just reading up documentation and others' opinions on such technology.

<comment><USER22> Sorry about the delay, OBE in my day job.

One of the best things was posted by sheepmullet

        Don't give them any actual authority.

Actually this is good for any architect. The ability to achieve consensus across all the groups gets you the buy-in that you need. It also ferrets out the detractors that are going to spend the next decade throwing rocks at the decision.

Next is go make friends with the operations people. Learn how operations works and what they do, how they monitor, how they keep things running. While they appear to be BOFH like, when they get the idea that you are listening to them, they will help you out. Make sure someone from OPS is on your consensus team. I had a white board architect (WBA) work for me and I made him get signature approval from OPS on everything he proposed. After awhile he got it and became less of a WBA.

Do lots of proof of concepts to see if what you are thinking about will work. In the past I've had a cadre of co-ops / interns do the grunt work. They are always excited about working with a new technology.

(If you are in the Philly Area, call Drexel University. You can get co-op students year round in either 3 or 6 month increments. Pro tip: Don't hire them until after they graduate. If you don't send the co-op back to the University so the Uni can get the rest of their money, they will stop sending you co-ops. )

The other advantage of co-ops is that you can afford to go down some dead ends. It's a win-win, you use a less expensive resource to find out bad news, the co-op gets to put "Worked on Astroscript at major company" on their resume. It's very freeing because you can then take on someone from the outside going "Hey lets do Elm", assign an co-op to do most of the grunt work rather than burning your time up.

You can be as hands on as you want. I've always found that getting some new tool installed is a huge mess. Need this library and that version of something else, these scripts don't work, etc. So my co-ops do that. Once it's spun up and running and their first mini-Proof Of Concept is working then I'll get involved with a larger POC and get my hands dirty.

(An aside on the install mess. When we get ready to start the "Moving to Astroscript" to the internal consensus cycle, I assign a co-op to package it. They put together a clean setup process for both Operations and the Dev Manager to sign off. Nothing kills a project faster than the people you want approval from not being able to spin it up to look at it.)

It's mostly lots and lots of talking to people about what their pain points are, what direction the business is going in, thinking about planned and unplanned pivots, etc. Always be thinking about a Plan B.

My check list for new things (in order) * What business value does this bring (ROI) * How does operations run this * What is the Disaster Recovery Plan * What is the opportunity cost * What is the internal friction * What is the external friction with our partners

Other things that may help:

Start a series of brown bag sessions (your call if the bags contain lunch or beer) and present out to anyone what you are thinking about. ( Tip: Master the ability to create a 50 minute long Powerpoint in 30 minutes. )

Talk to other architects / users that are using the tools, designs, etc. and see what they are finding out. Be ready to share back what you find. "Hey our review and POC of Astroscript figured out that getting any useful logging out of it was impossible, so we are punting"

Be a nice person. And remember, someday you may end up working for one of those co-ops.

<comment><USER25> Thanks for sharing :)</comment></comment></comment></comment></comment></comment></comment></comment>


Gas Companies Are Abandoning Their Wells, Leaving Them to Leak Methane Forever - <AUTHOR> https://www.bloomberg.com/news/features/2020-09-17/abandoned-gas-wells-are-left-to-spew-methane-for-eternity <comment><USER2> Identifying leaking well sites is getting a little more attention in the industry than the article suggests, at least for active wells. See, e.g., Kairos Aerospace's work in the Permian Basin. You can get a peek at what they're doing in Matt Gordon's PyCon talk: [https://youtu.be/WQkM3ppuhWo](https://youtu.be/WQkM3ppuhWo)

<comment><USER3> There are satellite remote sensing efforts as well.

[https://www.bbc.com/news/science- environment-54210367](https://www.bbc.com/news/science-environment-54210367)

</comment></comment><comment><USER4> That would perfectly explains why California has the 2nd largest man-made methane output in the nation.

Four-Corner, New Mexico seems to be #1.

</comment><comment><USER5> This is from Bloomberg, so most people with tight controls on their information sources will multiply the information by zero first¹.

A more reliable source describing methane leaks in oil and gas: [https://www.wsj.com/articles/the-leaks-that-threaten-the- cle...](https://www.wsj.com/articles/the-leaks-that-threaten-the-clean-image- of-natural-gas-11565280375)

¹ i.e. your posterior after supplied by this information is equal to your prior

<comment><USER6> ...and the journal is not?...

<comment><USER5> Depends on your own weights. I do not consider the WSJ generally non- authoritative¹.

Exceptions:

\- Opinion section I weight zero

\- Republican/Democratic political strategy I weight low

¹ I weight Bloomberg zero across the board

<comment><USER7> If you're discussing authoritative, AP is what all these news rooms use, same as Bloomberg.</comment></comment></comment></comment>


Why Asm.js Bothers Me - <AUTHOR> http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html

<comment><USER2> > OdinMonkey is a hammer that will kill incentive to optimize JavaScript that > humans write.

Eh, I'm not worried about this. Many apps will have no reason to migrate to asm.js, and for as long as some big and important apps are written in JavaScript, there will be incentive to optimize plain JavaScript.

JavaScript and other dynamically-typed languages exist because in many cases they are the best and most convenient way to write apps. But suppose this weren't true; suppose that in the long-term developers started favoring statically-typed languages for web apps, either because of performance or because of usability (Eclipse-like IDE convenience; hard to provide in a dynamic language). Is the author saying that we should artificially prop up usage of dynamic languages by taking away some of the inherent performance benefits of static languages? That doesn't sound like the best way to achieve technical excellence in the long term.

In the marketplace of ideas and technologies, let things succeed or fail based on their demonstrated merit, rather than trying to pick winners and losers based on our preconceptions.

> Somebody might say that [my proposed bytecode] does not run everywhere. > Nope. It does run everywhere: just take JavaScript and write a simple one > pass translator from this bytecode to JavaScript.

You can think of asm.js as just that; a one-pass translator of an implicitly- defined bytecode to JavaScript. If you want to view/edit it as a more traditional-looking byte-code, you can easily implement a YourBytecode<->asm.js compiler. It just so happens that asm.js is a backward- compatible representation, so works more conveniently as the standardized wire encoding.

(I have not studied the asm.js spec in detail, but I've seen pcwalton describe it as an alternate encoding of LLVM bitcode, so I suspect that the idea of implementing a YourBytecode<->asm.js compiler is actually reasonable given the asm.js definition).

<comment><USER3> I should qualify my statement with some caveats:

* asm.js has a very primitive type system, unlike LLVM bitcode. I think this is better for a distribution format; the complex types make sense for compiler IR optimizations but not so much for distribution after the optimizations are already done.

* asm.js doesn't have goto, unlike LLVM bitcode. I'm told that this doesn't seem to matter much in practice, as the Relooper is quite refined now. However, I'm certainly willing to believe that there are some oddly-shaped CFG's that this will hurt. Perhaps JS will need goto.

* asm.js doesn't have 64-bit types. This is unquestionably unfortunate, as it will need 64-bit types to achieve native parity. (Of course, JS needs 64-bit types anyway—it's important on the server, for instance.)

* asm.js doesn't have SIMD, unlike LLVM which has support for SIMD with its vector types. This will need to be added on to be competitive on some workloads. This is a good opportunity for collaboration between Dart and JS, as Brendan pointed out.

Regarding the original post, (and speaking only for myself, not my employer) I actually agree with mraleph to some degree. From an aesthetic point of view I don't like the subset approach as much as anyone. But if V8 doesn't implement asm.js AOT compilation, ignores the "use asm" directive, and achieves the same performance as Odin, then that's actually a good outcome in my mind. At least asm.js will have fulfilled the role of an informal standard that engines and compiler writers alike can agree to target for maximum performance.

<comment><USER4> > Perhaps JS will need goto

I was under the impression that labeled break/continue were the equivalent.

<comment><USER5> Yes, they are equivalent (AFAICT). You can generate irreducible control flow that will still require breaks to exit loops.

However, it is possible to eliminate (even in the irreducible case) all gotos, switches, breaks, and continues from a structured program.

goto's can always be transformed into conditional statements or loops.

break/continue can be eliminated by an extension of the control flow elimination, and use of variables + conditional flow.

A real world implementation can be found here: <http://gcc.gnu.org/ml/gcc- patches/2002-05/msg00109.html>

(it was never merged, we decided we were fine with goto/switch/break/continue)

</comment></comment></comment></comment><comment><USER6> "the first danger that I sense: OdinMonkey is a hammer that will kill incentive to optimize JavaScript that humans write. Why waste time optimizing normal, dynamic, fluid like water JavaScript if you can just ask people that they write something more structured and easier for compiler to recognize? "

I'm eagerly awaiting the day I can write single-threaded Go or Java, have it turned into asm.js and never have to write another line of yucky Javascript again. I like this proposed alternate future.

<comment><USER7> If something like asm.js could possibly kill the incentive to optimize handwritten code, we'd still be writing everything in assembly.

Asm.js is aptly named, because it's targeted at small, tightly-looped, extremely performance-critical operations over large amounts of homogeneous data. That's one of the few things people still use assembly language for on the desktop. That's all asm.js really is: a compiler hint that you've gotten desperate for cycles, so here are some coding conventions that will make things easier to optimize.

<comment><USER8> I think you're completely missing the point of asm.js. It's not possible to build small portions of your app with this really (no JS object access, no strings, etc), and it's not intended for that either way. It's really just a way of compiling C and C++ applications to run in the browser efficiently.

<comment><USER7> Actually, you can build small portions of an app with it. That's pretty much all you can do with it, for the very reasons you stated: no JS object access, no strings, etc. All you can do is the same stuff you'd need assembly for anyway: super-tight inner loops that work over lots and lots of raw numeric data.

That's an important part of compiling C and C++ applications to run in the browser efficiently, but it's only one small part of the puzzle. C and C++ compilers put a lot of work into optimizing this same sort of code, and asm.js gives them a path to bring some of those optimizations to the browser. But no C/C++ application, even compiled with emscripten or the like, is ever going to be compiled solely to pure asm.js. It's just one part of a larger equation.

</comment></comment></comment></comment><comment><USER9> "Please keep in mind that I used to work on V8"

In theory a V8 could optimize regular JS as fast as asm.js, but in _practice_ OdinMonkey made this code 3x to 10x faster (or more) with a couple months of effort. And to boot it is completely compatible with every JS engine, and the code generated can be cached offline for fast startup (because of the linking part), and the FFI between JS and asm.JS is trivial.

Basically this post is sour grapes. Mozilla came up with a better idea than the so-called geniuses at Google did.

<comment><USER10> That's a weird thing to say. Is the perception really that mozilla doesn't have its share of geniuses?

</comment></comment><comment><USER11> He makes a solid point regarding polyfills for asm.js: if the specification is so rigorously defined, then the only fallback a current-generation browser has on offer when encountering a "v2 asm.js" is to treat it like regular Javascript. That's a pretty nasty regression, and hopefully one that will be addressed.

Regardless I still prefer building on Javascript than any proposed alternative. No matter what happens next, any pristine standard is going to look like an overextended mess even in just a few years time. So why not pick the overextended mess we started with.

<comment><USER12> "So why not pick the overextended mess we started with."

What's the starting point? Javascript or assembly? NaCl gets closer to the original starting point (which predates javascript by more than 20 years)

<comment><USER13> By my count Javascript is around 5 years older than amd64. If we had gone with native client back then we'd be stuck with pre-SSE x86 or maybe they'd have been forward-looking and gone with Alpha or Itanium with emulation for "legacy" systems.

Also, why the false choice between asm.js and NaCl anyway? The article makes a pretty compelling case for "neither".

<comment><USER14> > _By my count Javascript is around 5 years older than amd64. If we had gone > with native client back then we'd be stuck with pre-SSE x86 or maybe they'd > have been forward-looking and gone with Alpha or Itanium with emulation for > "legacy" systems._

That's not really how NaCL works. Any instruction that can't break out of the jail can be whitelisted; this includes all versions of SSE.

Additionally, PNaCL can be retargeted at as-of-yet unknown architectures.

The result is that binaries would have been either shipped as PNaCL-only, or optimized for i386+SSE1 with fallback to PNaCL. As new hardware was shipped, new binaries could be targeted appropriately.

This seems reasonable to me; default to portability, provide an option for best-case performance.

<comment><USER3> How do you plan to ensure that authors test and ship working and performant PNaCl binaries if they and their users are always using the native code?

<comment><USER14> How did Apple developers ship working PPC/m68k binaries? Or PPC/x86 after that, later PPC/x86/x86-64, and armv6/armv7/armv7s on the iPhone?

<comment><USER3> Totally different. In all of those cases, the developers have access to devices that run the hardware, and they have economic incentive to target all of those devices. Whereas with your suggestion, developers ship and test native builds for all of the CPUs on the market, _plus_ one extra "portable" version for posterity, one that no immediate customers will ever use (because they'll be using the native versions for their architecture instead). I suspect developers wouldn't even ship the portable version (too much of a pain), browsers won't optimize it (because nobody will use it), and developers won't test it (because nobody will use it).

It's like saying that images are no problem for accessibility on the Web, because designers know to use alt text. Of course they know they _should_ , but we all know what the reality is. A backup "portable" version of an app is like alt text in this way. Some developers would do the right thing; many won't, and the Web will be de facto locked in to x86 and ARM forever.

<comment><USER14> That's a bit ridiculously alarmist, isn't it? Heck, you could have lead with that, rather than waiting for me to reply -- you seem to already know what you wanted to say.

Won't developers have access to PNaCL runtimes? How is this so different than Apple developers having access to the other target hardware

It comes down to toolchains and the workflow they're optimized for. With PNaCL, the portable version is the primary target of the toolchain, from which one generates other native binaries. You can still generate native binaries separately, but ideally, PNaCL would lead.

If the tools lead naturally in the right direction, then developers do follow. If you're feeling _really_ worried about it, define a distribution format that mandates a PNaCL entry.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> The author complains about having to write x = 0 in asm.js blocks where it simply means "here I declare x to be a number and not undefined". He worries that "if you remove a single + or | the code above will be rejected by the validator." But it is good: if your goal is to have a really fast code, and declared the section as such, you don't want any construct that will make it significantly slower.

Finally, author believes that the "JavaScript" code can be made "as fast" even without annotating it like in asm.js. He writes "I don't believe that anything like asm.js is needed to generate highly efficient native code" but of course he shows nowhere how something like that cab be achieved. Because it can't. Unless you somehow specify your assumptions in most of the cases you have to have the run-time checks. Which are slow.

Observe just for example:

         c = a + b;

If you haven't written before a = 0 and b = 0 you have to assume that a and be can be strings etc. You can have some code to take the int route but you have to have runtime checks. Now if you even wrote a = 0 and b = 0 and you're doing the loop in which you have a + b, you can't assume that the result will fit 32 bits. Which you don't need, unless you really want to do 32-bit arithmetic -- there are algorithms where you get the performance advantage by using it.

The asm.js annotations are a really clever way to tell to the JIT what _you_ (the programmer) expect. The sections allow you to get the nice clean pieces of clean native code, free of a lot of run-time checks. Speed and much more efficient memory use. Pure goodness.

<comment><USER7> Correct me if I'm wrong, but wouldn't the hypothetical techniques needed to enable something like "asm.js without the compiler hint" also come rather close to solving the halting problem?

<comment><USER16> The techniques need to enable something like "asm.js without the compiler hint" exist and are in use today in JIT compilation (at least to some degree). Since the source code does not generally change and the generated instructions may, you can make assumptions first and later on rewrite the instructions if your assumptions don't hold. At least that's how I understand it. If you would do AOT compilation and ship the instructions, then you may be right about the halting problem.

<comment><USER15> Checking if assumptions hold must be done regularly in run time. If you already know which assumptions always hold you have a significant advantage at the start: simpler faster and more compact code and the chance for better "global" optimizations. Postponing a lot of decisions to the run time is never good. Postponing a little can be OK. Here we're in the range of "a lot" that we can save. Like "in every damn +,-,/" of any two values in the really long calculations.

</comment></comment></comment></comment><comment><USER17> "Why asm.js is a JavaScript subset?". Simple, because Mozilla wants the benefits of the (P)NaCl approach but don't want to have to import LLVM. asm.js allows them to 1) make use of their existing JIT compiler and 2) avoid defining a new bytecode format (the benefits of this are questionable). asm.js is ugly, but it doesn't seem that much more ugly than adding a new multi- megabyte dependency to every browser.

I suppose an interesting question would be how hard would it have been to standardise on the PNaCl bytecode format and use that as the input to ${FOO}monkey

<comment><USER18> I've heard plenty of reasons Mozilla doesn't like NaCl, but that sure isn't one of them...

<comment><USER17> I'm just speculating wildly like most other people here are, but you really think it wasn't a positive for them that they could reuse the JIT they've invested in and have expertise in rather than relying on LLVM.

<comment><USER18> I don't want to speak to that. I was more referring to the notion that they didn't consider it because LLVM is a large dependency. As others have noted, emscripten uses LLVM, and it's likely that LLVM will be leverage to coerce other code in asm.js style javascript. Mozilla's reasons for not wanting NaCl have been spelled out lots of places.

</comment></comment></comment></comment><comment><USER19> I would imagine that people would rarely _write_ asm.js code, but instead they would generate it from statically typed languages (TypeScript, Dart, Haxe).

I admit asm is a bit ugly to look at. But, it's backwards compatible, and provides a way forward for getting some performance out of js in very specific cases. It's not going to be an all purpose code path for general use, and I don't think it's going to take attention away from other general js improvements.

The only thing I'm skeptical about here is whether or not Google chooses to integrate asm with Chrome (Setting aside what Apple or Microsoft ends up doing). It runs counter to the work Google has done with Dart. For that reason alone, I think there's a significant risk it won't gain traction.

I think the creation of "fast" web performance is seen as a huge carrot from the big tech companies (MS, Adobe, Google, Mozilla). Each is trying to offer it in different ways, and at the same time pulling developers into their specific dev tooling ecosystem.

It's a difficult time to pick languages/tooling. I like Haxe because I know it'll support the platform of whomever wins (asm.js, dartvm, es6, etc.)

<comment><USER20> > I would imagine that people would rarely write asm.js code, but instead they > would generate it from statically typed languages (TypeScript, Dart, Haxe).

Current asm.js is just for C/C++. Those altJS languages can't make use of asm.js (Haxe->C++->LLVM->Emscripten->asm.js might be possible but I think it's meaningless).

asm.js is the answer of Mozilla for "the web standards can't handle AAA games" but I believe this is far from an ideal solution. And I agree with the worry of the poster that this ugly hack makes JavaScript more ugly, both on the specs and VMs.

To be honest, I trembled when I saw the Math.imul proposion to see how some people are so obsessed with JavaScript...

<comment><USER21> > Current asm.js is just for C/C++

There is already asm.js support for lljs, some thoughts on support in things like JSIL (C#) and Haxe (as you mentioned).

And in principle anything that compiles to LLVM IR or C/C++ would work through emscripten.

</comment></comment></comment><comment><USER22> Without having actually done much to investigate the feasibility of this, it seems to me like someone could write a compiler infrastructure that would generate both asm.js and (P)NaCL output from the same lower-level non-JS code, since you can get to both from LLVM bytecode. Combined with a JS client library to paper over the differences between the two, developers could just write one set of low-level code and not care which fast-path execution strategy the browser implemented, and the asm.js version, along with whatever polyfill hacks were necessary to make it work, could be served to old browsers to run the same code slowly.

This is, I guess, not that different from the OP's suggestion to create a bytecode and define a one-pass transformation of that into JS.

</comment><comment><USER23> There's a valid philosophical objection here, and I found the article illuminating about the nature of Asm.js.

The strategy of making a static subset of a language that's easy to compile works great -- if it's targeted at humans! RPython, for example, means you can write the Python VM in Python, and the SmallTalk VM (or Squeak?) was written in SmallTalk using the same approach. The point is part of your code base is in this restricted language instead of C, and you can bootstrap that way.

If this language is just a compiler target and not meant to be particularly human-friendly (RPython has classes and mixins) then making it a weird subset of JavaScript is a little more dubious and without precedent that I can think of.

<comment><USER15> It's definitely not "just a compiler target," not more than the assembly language in which people still write some code by hand when there's need for that. The real world example:

<https://github.com/srijs/rusha>

(see the benchmarks -- Firefox 21 uses asm.js) and the source

<https://github.com/srijs/rusha/blob/master/rusha.js>

I don't see that the code got ugly. The calculations needed are the same, the most obvious differences from the "non-asm.js" code is the "asm.js" and a few |0 marks. And some of such |0 constructs can improve speed even on the browsers which don't do full "asm.js". So the engines will get smarter by recognizing such constructs even without the full support of "asm.js" segments. It's a win-win already.

<comment><USER24> Right, but your example here is a particularly skewed one. It's a hashing library. All it does is take integers and do arithmetic on them. Most real- world application code is not at all like that. Asm.js doesn't even support _strings_ as far as I know.

<comment><USER15> Asm.js is exactly made for things like that: the pieces of code that don't depend on "strings" but calculate a lot. And for things like this:

<http://bellard.org/jslinux/>

For "strings" the existing JITers do already the good job. You can just use JavaScript as is then.

<comment><USER24> Yes, agreed. asm.js is a great fit here. My point was that that fact doesn't generalize well to other problem areas.

Earlier you said asm.js isn't _just_ a compiler target, but if your program uses strings, or objects, or closures, or GC, then it's not going to be a good fit to use asm.js.

</comment></comment></comment></comment></comment><comment><USER25> In related news, researchers from Mozilla and UC San Diego with support from Microsoft Research have recently published another approach to typed JavaScript, named Dependent Javascript or "DJS". This isn't focused on performance so much as correctness.

1\. <http://lambda-the-ultimate.org/node/4700>

2\. <http://goto.ucsd.edu/~ravi/research/djs/>

</comment><comment><USER26> This seems to assume asm.js came first. Really it's a development build on top of what things like emacripten were already doing.

There doesn't really seem to be much criticism here of asm.js as a bytecode, only as a syntax.

</comment><comment><USER27> Compiling JavaScript down to asm.js format JavaScript might be messy, but it might lead to better performance if your compiler is better than the JIT engine.

I'm still not sure why a compact, concise, standardized bytecode format isn't being pursued. Perhaps minified, gzipped asm.js encoded JavaScript is as close as we'll ever get.

<comment><USER28> > is as close as we'll ever get.

This is the point I think the author and a lot of people are missing. It's not always about what is the best possible design, instead it is often "what we will get". Politics, ideology, and timing can often come in the way of "the best design".

I would love to use NaCl (I was cheering for it up until recently), but if only Chrome is implementing it then it's about as useful as a screwdriver that doesn't fit any screws.

asm.js is already a stronger candidate because I can use it right now and it will work everywhere. Obviously the browser vendors has to create asm.js specific optimizations for it to be truly great, but that is like fuzzing over the handle, grip and material of the screwdriver. It fits the screws, it gets the job done, it actually _works_.

What does it matter how great your technology is if it doesn't work? What does it matter if NaCl is ten times faster if I can't actually use it? From what I see, Mozilla isn't very hot on the idea of adopting NaCl, and Microsoft will probably not even touch it in this millennia.

If a client wants me to produce something, I can't use NaCl, because it won't actually run in non-chrome browsers (without installing plugins).

To me it appears that the choice is either asm.js or nothing. NaCl just isn't happening.

<comment><USER24> > asm.js is already a stronger candidate because I can use it right now and it > will work everywhere.

This is fundamentally not true. We tend to think of "better perf" as not being breaking the web, but that isn't always the case. Imagine a game written using asm.js. Plays beautifully at 30fps on Firefox. Great! And it runs on every browser, right?

Well, if it runs at _three_ FPS on Safari, then as far as the game developer and the player are concerned, no, the game doesn't run on Safari.

<comment><USER29> Does this mean that Chrome "broke the web" by being so fast while IE6 was still in circulation?

<comment><USER24> If you're going to use IE6 as the baseline that pretty much every browser was breaking the web relative to it, including later versions of IE, weren't they?

I don't recall many websites at the time only being effectively usable for perf reasons in Chrome, but my memory is a bit hazy. Certainly, there were fewer very JavaScript heavy sites, and most of HTML5 hadn't been created yet. That meant there were fewer opportunities to build web apps that _required_ fast JS. Also, Chrome wasn't as fast as it is now.

But, yes, if people were building apps then that said "only in Chrome" then that would imply that to some degree Chrome was breaking the web. Fortunately, in that case, the other browsers caught up quickly and resolved that tension.

</comment></comment></comment></comment></comment><comment><USER30> > It can't allocate normal JavaScript objects or access normal JavaScript > properties. No strings. Only arithmetic and typed arrays (a single one > actually with multiple views).

I think he is missing a core concept here. You _can_ create and modify strings, just at a lower level. An array of ints can be used as a char array, which in turn can be used as a string. You just have to interface with it at a lower level, probably implementing your own C-style strlen/strtok functions. It will be more complicated, especially if you need to accommodate unicode, but it is doable. Granted, there is no advantage to abandoning the built-in string manipulation functions except speed, but you would only use asm.js when speed absolutely matters.

At a more fundamental level, when you have access to memory through a stack and/or heap, and can create arrays of ints with which you can do normal arithmetic and load/store operations, you really can do anything. After all, that is the entirety of what _actual_ assembler code has to work with. You just have to make your own abstractions.

<comment><USER31> When I say "no strings" I mean JavaScript built-in primitive string values. I will amend the paragraph to make it explicit. It was added because I talked to people who think that just adding "use asm" on top of their node.js module will make it go as fast as C++ without realizing that asm.js is a very limited subset with its own rules.

You can surely represent a JS string as a Uint16Array or Uint8Array, but copying things in and out of emulated heap into real heap will cause penalty. You will also have to reimplement a lot of functionality that host JS engine provides. Trying to implement say a regexp engine in asm.js that would be as performant as V8's built-in on would be a challenge.

Yes, you can do anything. I don't dispute that. But you have to do it manually and sometimes you are replicating functionality that already exists in the host engine e.g. you might implement GC, but it will less efficient than builtin one.

</comment></comment><comment><USER32> Yeah, I have the same bad feeling on asm.js.

If we need c/c++=>llvm=>javascript/asm.js for performance reasons, then why not just embed llvm inside web brosers? Isn't it much easier, and much cleaner?

</comment><comment><USER33> OK, let's say that with stuff like ams.js we never get true native performance than say NaCL would give.

Isn't that also a good thing?

I wouldn't want the web as a platform to be that good that it kills all native desktop applications, essentially turning every computer into something like a Chrome Book.

Isn't that a real danger with stuff like NaCL?

<comment><USER34> > I wouldn't want the web as a platform to be that good

What? Are you so ideologically caught up that you actually wish something wont get good? It is totally reasonable to to think something isn't the right approach or a waste of time, or to not like the workflow, etc. But to actually wish that something wont get good enough to be a general solution even if it can? How does that make any sense?

<comment><USER33> > _But to actually wish that something wont get good enough to be a general > solution even if it can? How does that make any sense?_

It makes a lot of sense because things do not happen in isolation. A "good enough web platform" could bring a lot of OTHER outcomes too.

I wrote one in my comment already: all computers because Chromebooks, glorified clients.

That has other consequences: you loose control, you don't own your apps (the company does, and it can take them from you in an instant, like Google Reader), etc. Not to mention the privacy implication of ALL apps running in a web browser, getting their data remotely. Or the implications for companies and governments locking content, pushing you out, demanding a premium, etc.

<comment><USER35> I don't see that those consequences follow, at all. I see a natural evolution from where we are now to a world where people own their own servers in the cloud and run all the software on them.

Or, if you really don't want any data to go over the wire, just run all the web app servers locally.

There was a big swing from the idea that at&t would sell you a terminal that was connected to a central mainframe, to personal computers that were distributed, back to everything being centralized because the advantages of the web were compelling and centralizing things was the natural path. Things will swing back again to decentralization, but the difference this time is you will be able to access all of your data from anywhere at any time.

</comment></comment></comment></comment><comment><USER36> I find asm.js pointless. If all you need a fast numeric calculations in JavaScript, the better compiler backend would be WebCL - OpenCL binding to JavaScript.

<comment><USER37> Could you expand on this? It seems like an apples and oranges comparison.

<comment><USER36> Asm.js only allows numeric operations on emulated heap buffer. You can do much better with OpenCL on CPU device.

Asm.js intended to be used as a backend for compilers. One of OpenCL use cases is the same.

Asm.js code pretends to be a JavaScript code, OpenCL does not, but there is WebCL - a JavaScript binding standard for OpenCL.

<comment><USER37> Asm.js is still JavaScript. You can do all kinds of things that JavaScript can't do by itself if you call native code with a plug in. That's the difference. No plugin. No installation.

<comment><USER36> What's the difference between Mozilla deciding to bundle Asm.js with Firefox vs. Google deciding to bundle WebCL and WebGL with Chrome?

<comment><USER37> I refer you to <http://asmjs.org/faq.html> to understand the difference. Particularly the Question: "Why not NaCl or PNaCl instead? Are you just being stubborn about JavaScript?"

</comment></comment></comment></comment></comment></comment><comment><USER38> What bothers me about asm.js is that no one really needs it. I mean don't get me wrong, Unreal III in Firefox is pretty cool, but very very few developers will seriously consider writing a production game for the browser. So then what are we left with?

FFT implementations? OCR? Real-time fluid mechanics? Who does these things in a browser? What JS needs is to finally standardize WebSockets (across the board), to seriously consider multi-threading (not this WebWorker nonsense), to implement optional type checking (like Dart), etc, etc.

The effort that's going into asm.js should go into building better JIT compilers. We seem to be forgetting that JavaScript is a _web programming_ scripting language, not some general-purpose low-level esoteric programming language. There are so many improvements JS could make on the web-side of things (you know, where it's actually used) instead of on the "cool 3D Unreal III game-programming, bytecode-crunching, Jacobi-simulating"-side of things.

<comment><USER39> The goal of things like asm.js is to make JavaScript a general purpose, low level programming language. I'm not sure why you consider it esoteric, though.

People don't do those things in the browser because asm.js (or some alternative) isn't widespread yet. When it is, they will.

<comment><USER38> Exactly. JS was never meant to be a general-purpose language. Using the right tool for the right job is a fundamental aspect of software engineering. If you use C for writing web-apps and JavaScript for writing operating systems, you're doing something very, very wrong.

The irony here is that JavaScript isn't even a very good language, anyway. So when lambdas are implemented in a language like C++11 (to the chagrin of many programmers that shun the unnecessary complexities of recent revisions of C++), that's one thing; but when we're trying to use JS for low-level programming, that seems very silly.

And as far as your second point is concerned, I beg to differ. Java has been able to run OpenGL in the browser for ages. Flash can also do hardware- acceleration. As can Unity3D. 99% of computers have either Flash or Java installed, and yet, no serious developer (barring maybe a couple of indies) would seriously consider Java/Flash as a serious platform. I don't think HTML5/asm.js will change that.

<comment><USER40> >JS was never meant to be a general-purpose language.

The original designers and implementers of the Internet, the Web and HTML probably never envisioned the myriad of ways those technologies would be used (abused?). So what?

>Using the right tool for the right job is a fundamental aspect of software engineering.

So tell me, what is the right tool to build a cross-platform application that runs on every system, without requiring native install (and with every other benefit of a typical 'web-app')?

>If you use C for writing web-apps ...

WHY?!? How can you even say that in light of the Unreal demo that Mozilla showcased, where you have a high-performance game running on a standard browser. Given that, you still see zero potential? I don't know if browser gaming will take off, but that's irrelevant. If the browser can run a high performance game, it tells me devs can make use of that processing power to build any sort of web application that traditionally would have needed to be native. You don't see the potential in being able to build a web-based Photoshop or AutoCad?

>The irony here is that JavaScript isn't even a very good language, anyway.

You're right, it isn't, so what? HTTP isn't the best protocol, and neither is TCP, but try replacing them with any 'superior' protocol. JavaScript, like HTTP, and TCP is ubiquitous, that's its strength.

>no serious developer (barring maybe a couple of indies) would seriously consider Java/Flash as a serious platform.

I consider both serious platforms for gaming and otherwise, even with the knowledge that they will be replaced by HTML/JS on the client.

</comment></comment></comment></comment><comment><USER41> Looks like the asm.js Jedi mind trick didn't work on someone :)

</comment><comment><USER42> If it is not JavaScript, and it gains it's performance by static typing - well, we already have a language like that, and it's more production ready than asm.js - it's Dart.

<comment><USER31> Dart is not statically typed.

</comment></comment><comment><USER18> Isn't he describing Dart in his second to last section?

<comment><USER31> I am not sure what do you mean. Dart is a dynamically typed language, not a bytecode. Dart's type annotations don't even have any implications on performance and not used for optimizations by either Dart VM or dart2js.

<comment><USER43> Though, you can run the DartVM in "checked" mode which will validate all type assignments to make sure they match the types annotated in your code.</comment></comment></comment>


From getting hacked to getting VC funding – a startup story - <AUTHOR> https://medium.com/@eslamsalem/from-getting-hacked-to-getting-vc-funding-a-startup-story-3878268f6e2f <comment><AUTHOR> This is the story of young security startup from Egypt, Trying to make its way into the security SaaS world. Enjoy reading and I'm here to answer any questions.</comment>


How I found a $5,000 Google Maps XSS (by fiddling with Protobuf) - <AUTHOR> https://medium.com/@marin_m/how-i-found-a-5-000-google-maps-xss-by-fiddling-with-protobuf-963ee0d9caff <comment><USER2> Fifth posting in 9 hours. Original has 16+ comments:

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


Responsive website design cheat sheet part 1: what widths should I design for? - <AUTHOR> http://www.zingdesign.com/responsive-website-design-cheatsheet1/ <comment><USER2> Unfortunately I would disagree with this. Break points shouldn't be device specific. They should be as the name suggests, where the design breaks.

<comment><USER3> Boom exactly, If you're thinking you need device specificity don't you really mean you need to be say; feature detecting for touch and increasing UI control size for that feature.

Detect zoom levels instead of getting the device and checking its resolution scaling.

We need to address the image scaling problems with a proper specification so unfortunately we're stuck with work arounds and guessing image size for that.

</comment></comment><comment><USER4> I don't get how a design blog has that fixed-position white logo that is impossible to read once you scroll to the content.

<comment><USER5> Sounds like a cross browser issue, the fixed bar has a red background for me, Chrome, W8.</comment></comment>


Cryptocurrency trader 'forced at gunpoint to make Bitcoin transfer' - <AUTHOR> https://www.theguardian.com/uk-news/2018/jan/28/cryptocurrency-trader-forced-at-gunpoint-to-make-bitcoin-transfer <comment><USER2> Well, as secure as the blockchain is, it's still susceptible to the good ol' 5$ wrench bruteforce attack [https://xkcd.com/538/](https://xkcd.com/538/)</comment>


Functional programming in Clojure - <AUTHOR> http://mooc.cs.helsinki.fi/clojure <comment><USER2> edX also has an upcoming online course about functional programming: [https://www.edx.org/course/delftx/delftx- fp101x-introduction...](https://www.edx.org/course/delftx/delftx- fp101x-introduction-functional-2126)

<comment><USER3> A session of Martin Odersky's _Functional Programming in Scala_ is just wrapping up. I'd reccommend it as a good way to bring a more functional style to the JVM. The Edx course, being in Haskell probably is a better choice for a different audience.

This Clojure course is a clear third alternative because of Clojure's pseudo.dynamic typing versus the Scala and Haskell's strong static typing.

<comment><USER4> What's "pseudo" about Clojure's dynamic typing?

<comment><USER3> The same sort of thing that's pseudo about pseudo random numbers...usually it is indistinguishable, sometimes in the case of Clojure one is reminded that it is probably wise to keep the underlying mechanics of Java's type system in mind if one wishes to maintain an accurate mental model. In particular, it is useful to keep in mind the way in which class and interface types structure their child types within a system of static typing.

This isn't a bad thing. Being built on Java provides tremendous utility. But the way in which Java makes lumps under the Clojure language layer which blankets it gives Clojure a different flavor than say Common Lisp...and note I said "different" not better or worse.

Anyway, that's the idea I was trying to capture with the term. I wasn't disparaging Clojure, just suggesting its relation to the JVM comes at the price against Haskell style greenfield implementation.

</comment></comment></comment></comment><comment><USER5> This is the greatest introduction to clojure I have seen so far

</comment><comment><USER6> Thanks, this looks like a great course. Not quite sure how to sign-up but I'm sure I'll figure it out :)

<comment><USER7> It looks like having a github account is how you get started, then you fork the repo and run tests after each exercise. Pretty neat

<comment><USER8> You can clone a repo without an account

<comment><USER9> Yeah, and the repos have all the same tests that are used by Travis for grading. So you can run those locally too.

</comment></comment></comment></comment><comment><USER10> I'm seriously excited to get started on this. So many courses start with such extreme density, but this one appears to have done it right.

<comment><USER10> Already have learned SO much more than anywhere else over the course of a single day.

</comment></comment><comment><USER11> small typo: "No other registration is _reguired_."

<comment><USER12> That's actually a rather common error for Finns. G and Q are almost exclusively used in loanwords and foreign proper names. What's more, some Finns pronounce the name for the letter Q as "guu". I've never figured out why.

<comment><USER13> "What's more, some Finns pronounce the name for the letter Q as "guu"."

That's how we Finns pronounce it in the Finnish alphabet. From there it easily slips into other languages that we speak. So it is like Finnish-English accent thing.

</comment></comment></comment><comment><USER14> Is there a time limit to this course or is it self-paced?

<comment><USER15> There's no time limit.</comment></comment>


What I learned from building WordGap on AppEngine - <AUTHOR> http://blog.zmxv.com/2010/11/what-i-learned-from-building-wordgapcom.html

<comment><USER2> I'm not a GAE expert, but using the GAE memcache clone wouldn't be a good idea in this case? The low latency requirement should be met and it looks like that his data structure would fit well in a k/v store.

</comment><comment><USER3> I've been using AppEngine for almost a year. It's definitely come a long way, but it does still have some serious shortcomings. Most notably is support. If they could offer a level of professional support to organizations willing to pay, I would both pay whatever they wanted and would no longer have anything to complain about. AppEngine is a great product and watching it mature is fun, but frustrating at times.

<comment><USER4> The #appengine channel on Freenode is a pretty good place to ask. There are oftentimes people from Google who are working on GAE and can help you out.

Worked for me several times.

</comment></comment><comment><USER5> I still don't get why people keep on talking about how awesome App Engine deployment is.

<comment><USER4> It's painless and fast so why shouldn't it be awesome?</comment></comment>


2014 LLVM Developers' Meeting: Slides and Videos - <AUTHOR> http://llvm.org/devmtg/2014-10/

<comment><USER2> For those who are curious, Part 1 of Chandler Carruth's Pass Manager talk is avaliable here: [https://www.youtube.com/watch?v=rY02LT08-J8](https://www.youtube.com/watch?v=rY02LT08-J8) (slides: [http://llvm.org/devmtg/2014-04/PDFs/Talks/Passes.pdf](http://llvm.org/devmtg/2014-04/PDFs/Talks/Passes.pdf))

</comment><comment><USER3> Is it just a coincidence that the videos from Apple's employees are the only ones not available?

I've been waiting to see "FTL: WebKit's LLVM based JIT" for a long time

<comment><USER4> Probably for the same reason as slide 2 (Safe Harbour: this is me, not Oracle, not a commitment, etc) in [http://llvm.org/devmtg/2014-10/Slides/Hawes- Frappe.pdf](http://llvm.org/devmtg/2014-10/Slides/Hawes-Frappe.pdf) from Oracle: fear that anything that might get said will lead to legal proceedings. The slides will have been vetted, but you cannot prevent a speaker from ever saying 'we do [not] plan' (might get interpreted as "we, Apple") or something like it.

</comment></comment><comment><USER5> I refreshed the page twice, thinking that the server was under too much load to serve the CSS properly.

I was wrong.

<comment><USER6> Some people are more busy actually building stuff and happy enough with a site design that doesn't have the latest gimicks.

<comment><AUTHOR> You don't pick compilers based on whether or not their site uses CSS5.3? Bro do you even web?</comment></comment></comment>