oberstein

No, I recognize it's a hard problem, that's why we should be devoting significant resources to doing things now.

I get the point about unintended consequences with cascading problems (and cascading solutions to the new problems) (https://news.ycombinator.com/item?id=2743879) but the odds of screwing up here are much less than screwing up on AGI, whose work has already significantly started and may be completed first anyway making this whole discussion moot. Geoengineering is risky, but it's not as risky as other things, including inaction, which as the status quo guarantees loss of thousands of lives. Even if the climate change alarmists' greatest fears come true we still easily have 50 years to try things on smaller scales before time is up. Anyway I think it's a lot more feasible for a strong nation to lead a technological solution than to convince all strong nations to curb their development. Call it a plan B if you must, but at some point I expect climate change alarmists are going to say something like "China and Russia and India aren't playing ball hard enough, their emissions are still causing global warming that will end humanity in x years unless they immediately reduce to the levels of the USA and the EU whose combined efforts bought us y years but it's still not enough, so it's time for war to make them."

When you have treated all symptoms and stopped them from arising again, the disease is effectively cured even if you still carry it. The final solution will be complete mastery over our planetary weather, it's better we do that sooner than later. Tsunami and earthquake deaths total far above terrorism deaths, we only need funding to fight terrorism to the extent that they get in the way of building to that final solution. Even if we "fix" the climate change disease (say perhaps by wiping out industrial-era and beyond humanity, the disease?) those other natural phenomena will still be killing many.

I'm a fan of: http://stanford.edu/~moore/Boon_To_Man.html

Near the end: "If mankind had to choose between a warmer or a cooler climate, humans, most other animals and, after adjustment, most plants would be better off with higher temperatures. Not all animals or plants would prosper under these conditions; many are adapted to the current weather and might have difficulty making the transition. Society might wish to help natural systems and various species adapt to warmer temperatures (or cooler, should that occur). Whether the climate will warm is far from certain; that it will change is unquestionable."

Buy iron, dump in ocean. (https://en.wikipedia.org/wiki/Iron_fertilization) Donate to geoengineering efforts and lobbying against insane moratoriums against geoengineering efforts.

"Runtime", or "REPL" time, or "doc time" are all ways you can just "look at it". Do you think knowing "x" is type "Foo" tells you anything about what you can do with "x", other than use it where you can use "Foo"s? You need to figure out what you can do with "Foo" by reading the docs around "Foo". Yeah, I know a priori I can call a method on Foo that returns an int and pass that to other int-taking methods, but is that what I want to do? Which method returning an int do I want to call? You need to look at what "Foo" is to determine this. Rich's example is HttpRequestServlet in https://www.youtube.com/watch?v=VSdnJDO-xdg I'd recommend watching that and ignoring me. A lot of the issues he raises, as contextfree points out, are around OOP rather than static typing in general so take these as my views and not necessarily his...

If "Foo" is just dynamic data, perhaps in a map, composed of other data, and it's values all the way down, any of those three points of time are easy ways to look at "Foo" and can generally be faster than reading a JavaDoc page or ctrl+spacing figuring out what you have access to and what it all means and what you want to do with the data and code associated with "Foo". Since you're going to be looking at the thing you want anyway, I find it very uncommon in practice that I accidentally divide a string by 2. Static typing would let me know before I run the thing that I was an idiot (maybe, see next paragraph), but I'll find out almost as quickly when the code I just worked on (either in the REPL, which is very nice, but even from the starting state) actually does what I want -- you do that regardless of static/dynamic typing, right? You don't just write code and never verify it does what you want, trusting that it compiled is good enough? Anyway when I run it, I'll immediately hit a runtime error (which can be handled in Lisp in ways way more flexible than exceptions in other languages) and realize my stupidity. So I don't find that particular situation or class of bugs very compelling.

Nor do the presence of declared types alone guarantee my safety -- I need to know about any conversion rules, too, that may let a String be converted to an int for division purposes, or if there is operator overloading that could be in play. Conversion rules and operator overloading are interesting regardless of the static/dynamic typing situation because too much or too few can lead to annoyances and bugs. Java lets you concatenate ints into strings with "+", Python doesn't, but Python lets you duplicate strings with "*".

What I have run into in both static and dynamic languages is division-by-zero errors, which, unless you go all the way to something like Shen that supports dependent typing, your type system with "int" declarations will not help you with. I've run into errors (in both static and dynamic languages) parsing string contents to extract bits of data. I've run into errors around the timings of async operations. I've run into null pointer exceptions (though much less frequently in dynamic languages, maybe once the Option type is in wider use I can rely on that too but its issue is poisoning the AST). I've run into logic errors where I thought the system should be in state C but instead it transitioned to state E. The bugs that take the longest to diagnose and fix are simply due to not understanding the problem well enough and having an incorrect routine coded, so I have to figure out if it's a logic error or an off-by-one error or simply using the wrong function because it had a suggestive name and I didn't read through the doc all the way. Rich made an interesting point in one of his talks that all bugs have both passed your type checker (if you have one) and your test suite. My point is that I'm not convinced static typing as I'm given in the languages I work in is worth it for any reasons beyond performance because I don't see any other improvements like making me more productive or writing less bugs. I'm not opposed to types and schemas themselves in general, just static typing. I'd rather see pushes towards full dependent typing and systems like TLA+ (which has seen more industry usage than Haskell) and Coq than things like core.typed in Clojure.

The last point I'd raise is that I agree with you developer efficiency is more important than code efficiency. But this has been one of the mainstay arguments from the pro dynamic typing camp for many decades, with static typing advocates conceding that yes the developer will be more productive in a dynamic language but the performance is terrible for anything serious. If you want to argue static typing was actually more efficient all along from a developer perspective than dynamic typing, you have a lot of work to do. I'm not particularly interested in that argument (at least today) but the point still needs to be raised.

I doubt Rich will ever push for it, but stranger things have happened. Types get in the way of data. When you ask a request "What's in you?" in Clojure you can just look at the data and find out. In Java you can ctrl+space in your IDE and look for public methods that by convention start with 'get', and then for the return values of those things also look for things that start with 'get', but that's a pretty impoverished way to get at the data. Try printing it out and you're likely to just get a memory address, great. So what do types buy you? Sometimes performance, but if that were always true then all static languages should be about as fast as C. The other thing is this "certainty" mentioned, and that certainty is just that you didn't make a typo or spelling error, woop-dee-doo, those are among the fewest sets of errors dynamic programming language users run in to, especially when you change your workflow to take advantage of the nature of dynamic languages, and a more valuable certainty is that this piece of data you have isn't going to change underneath you. You have to go all the way to Haskell (I'd argue Shen) to get real benefits of typing beyond performance and typo-protection, and most programmers are unwilling to do that for very good reasons.

Any goal by the President must be fulfilled within 8 years at most, otherwise there's no chance. See for instance https://en.wikipedia.org/wiki/Lunar_outpost_%28NASA%29 initiated by Bush and killed by Obama.

Greater than any technological or Presidential initiative challenge is the challenge of culture and media. Human lives matter a whole lot more now than they did during the Apollo missions, and a disaster resulting in the deaths of astronauts is the worst thing that can happen to NASA. As long as it is subject to public scrutiny and criticism that affects its budget and goals, it will continue in the fashion of the medical industry -- accepting all the consequences of do-nothing neglect instead of doing something that carries the risk of the deaths of a few individuals. In the medical industry, hundreds of deaths some of which could have been averted with not-yet-FDA-approved surgeries or drugs; in the space industry, the always looming threat of an extinction-level asteroid or other existential threats.

And as long as they do pop up scary warnings when the DV certificates change possibly due to a MitM attack it'll be even more fine.

Pretty hard to imagine people here aren't familiar with Lovelace. I'd rather see more things named after https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist... or https://en.wikipedia.org/wiki/Kateryna_Yushchenko_%28scienti... or https://en.wikipedia.org/wiki/Barbara_Liskov

Liberals simultaneously believe they can outlaw guns but they can't outlaw drugs. Hypocrisy can be fun to notice in your hated enemy, but sometimes you have to dig into the details of each idea separately without analogies to similar surface level ideas.

There was no censorship on saying a lot of things the puritans didn't like said, but the consequences of saying them could be your life. Nowadays the consequences for saying what you can't say are merely limited to loss of job and any future career in your field and the only media exposure being to solidify how evil you are. See: https://handleshaus.wordpress.com/2013/12/26/bullied-and-bad...

Just another instance of dunning-kruger. When he's older and had more interactions with lower IQ people, he may come to terms with his gifts...

But magic powers at 30.

Flooding the country with Arab speaking immigrants with the goal that some will filter up to the TLA agencies to help with surveillance on their former countrymen is ludicrous. If you want the numbers of Arabic speakers increased, you teach the language or hire existing talent. In any case, machine translation is pretty good these days -- even if Google doesn't perform that well on Arabic. Encryption is a much bigger barrier than language.

I was an October baby, so I started "a year late". I only had one good friend a year above me, we got out of touch when he went to Junior High while I was stuck in 6th grade. My other friends were in the same year and considering the older friend grew up to have lots of legal problems, I'm not disappointed on that end.

I do wish I had finished a year earlier, though. It would have meant cheaper college and would have also meant starting a career sooner, which for me is above $100k/yr. It would have also increased the chance of my mother still being alive since she died right after I was hired and I think if she didn't have to work until the end because I'd have been paying her bills she'd still be around.

I'd suggest going with what your kids want. If they want to learn, go for it. If they're perfectly happy with pre-school/daycare, or have lots of friends in that age group, maybe reconsider. They'll make new friends regardless of the grade, though.

Batman was pretty bad, but you can't use any game from Bethesda to further your argument. It's pretty well known that if you don't want a super buggy Bethesda experience, wait for the game of the year edition.

The data should speak for themselves. Unfortunately people who don't know statistics think they can't, because as we found out from emails, the data were "manipulated" via statistical methods: https://en.wikipedia.org/wiki/Climatic_Research_Unit_email_c... Honestly I'd rather we press scientists of all sorts for all their source code and modeling tool configurations including the raw data that hasn't been post-processed to hell in an "acceptable" way (recalling that the statistics involved in generating p-values were "acceptable" for psych journals until recently).

Is there potential evidence you could imagine that would change your mind about that premise? I agree with GP that inequality is fine if the basic needs of everyone are met, I also go further and agree with Paul Graham that inequality is a sign of a healthy economy (http://paulgraham.com/inequality.html). I also find nothing wrong with inherited wealth because I love my heirs and want them to have an easier life than I did, I want them to have some silver lining if I pass, I'm in this for more than just myself. I thought about it for a few minutes and one piece of evidence that might make me reconsider your side is if you could show rising inequality (in an environment with an absolute basic-needs-met floor or not) leads to falling access of the basics like food, shelter, knowledge, and useful technology like penicillin. That would be a potential downside to increased inequality that I would care about -- I don't particularly care about the potential downside of increased inequality leading to increased envy since you don't treat envy by giving in to it.

But like, how are you supposed to move when you have no car, no job, no computer, are 20 miles from the nearest city with things like libraries in it, and use up enough a fraction of your parents' monthly income (or whatever other source that lets you physically live day-to-day) such that they don't have much in savings to loan you?

As 'successful' people we can see many ways out of these arbitrary situations, even if you tie our hands behind our backs with something like "and no plan that involves your current professional skills like acquiring any old computer and doing software dev". We can also execute on our plans. For us, being poor is a choice, many of us started out that way to begin with and chose to do better than our parents. For a lot of others, it's really a lack of capability in not only seeing ways out but also precisely following instructions someone else gave them to get out. As the saying goes, you can lead a horse to fresh water... All the opportunities in the world are useless to you if you don't have the capacity to see them or execute on them.

You kind of need an AI God to bootstrap that. At least, that's the easiest way to get from here (needing a money concept) to there (not needing a money concept).

Is IQ a resource?

You don't really need it when reading tutorials either. Rainbow, simple matching, or manually counting parens is very much helpful when you're editing code, not so much when you're reading, at least if the code follows standard formatting idioms. You really get used to it: http://www.loper-os.org/wp-content/parphobia.png I would even argue you don't even absolutely need matching despite its helpfulness since Lisp was done and is done on many primitive editors without such features including pen and paper. As a first order approximation, you have just as many parens (braces, brackets) as a C-like language, the opening one is just on the other side, and C too can be done just fine with primitive editors.

Very neat demo, I hope it gets integrated into the major Clojure IDEs soon as it could make the onboarding experience smoother. I'm happy with just vim though -- I never liked the fashion of editors inserting/deleting/replacing non-whitespace characters (even that took a while to get used to) when they think they can to 'help' me.

It's pretty expensive, my own informal surveying of people with kids suggests the 'good' childcare places are basically equivalent of an extra one-bedroom apartment per month per kid. Relative to historical standards, you had not only the housewife, but grandparents, other relatives, and even your neighbors in the immediate community to help share the burden.

Some other perspectives on "rehabilitation": it's easy to associate that word with treatments like Anders Breivik's, which to many (most?) Americans seems insane and they feel he should just be shot. A variant of 2 is that "rehabilitation" in a prison setting makes no sense not because of moral failings but because the methods just make it more likely the prisoner is institutionalized instead. This is the case with many mentally ill people who are stable, on medication, etc., but in efforts beyond that to "rehabilitate" by e.g. giving them housing near the facilities or part-time (less than 10 hours a week) work (with 30% of all income they take unless you can move out) they end up locking them in with dependence. Another variant of 2, people for the most part are either "habilitated" already or not before prison and after prison. Many types of crimes that result in prison sentences aren't really indicative of a person in need of "rehabilitation", just a person that made a mistake (like submitting too much to vices like greed). The time in prison acts as a deterrent to help bolster weak wills, but if those who end up there anyway change at all it will only be from forced introspection as their normal life falls away for a while. They don't need much prison time or "rehabilitation", just incentive not to do what they did again. And on the other side, there's the feeling that people like Breivik could never be "rehabilitated" and in fact weren't "habilitated" to begin with. Better to shoot those people, or, failing that, at least make their lifetime in prison unenjoyable.

I think you can get people to agree to other mandates of the justice system beyond pure punishment as deterrent if your other mandate is more specific, detailed, and limited than "rehabilitation". For instance, lowering remission rates, or keeping employment rates pre and post prison similar...

Here's a classic "OMG I can hear him moving around" recording that works with the cheapest of headphones: https://www.youtube.com/watch?v=IUDTlvagjJA Most of the audio experience quality comes out of the production phase, and artists can put as much or little effort into that as possible and consider several mediums of listening (headphones, TV, surround, concert, vinyl) and make tradeoffs for the medium's particular experience.

I don't know about double blind trials but people do tests on their own. It's further complicated though because the hardware you use could be optimized for certain types of music, e.g. have a read through http://arstechnica.com/gadgets/2014/07/some-of-the-worlds-mo...

And I was commenting on the general nature of Firefox, not this particular button.

Then we have no argument there. I thought you were commenting on the general nature of the Pocket feature, which is also probably complicated given it's its own separate thing, and my reply was just echoing that you only need to understand and audit the layer that talks to the black box. In this case, a button response handler.

I found https://hg.mozilla.org/mozilla-central/file/tip/browser/comp... within 5 minutes of looking. It's very readable, I spent another 5-10 minutes reading it. This is the first time in memory I've looked at Firefox's code, so I didn't even know where to find it, though I'm sure I've browsed bits of the codebase before for some reason. I first browsed to their files, went to 'browser', and since we're talking about the button I thought 'components' was a good next choice, and hey, a pocket directory. Lucky? Maybe. Reading through the component tells me the initial claim of nothing important happening until you click the button seems accurate, except that functions are exposed publicly so other bits of Firefox could probably get at them without user interaction, and when you do click on it (L165) it'll prompt you to sign up at about:pocket-signup before doing anything. If I wanted to get rid of this, googling seems to say you can override default components with some extra effort. I build Firefox from source (Gentoo) so it would be simpler to just add a patch to the build process that removes the whole directory and deletes the dir line from moz.build.

This is just static human analysis, it didn't take much time or skill. But static analysis isn't the only thing you can do, as I initially said "verify". Active verification by monitoring and alerting works great, and if you can do rebuilds like you can with Firefox then you have even greater control. If I were particularly concerned about something happening without my knowledge (with or without the button) I'd use what I learned from reading the code to monitor my network for outreaches to pocket's website. Of course I can't be fully certain some other code doesn't send all my visited sites to some other IP (or maybe an IRC server) that is then harvested by pocket asynchronously... But as you say, it's very unlikely for such malicious and underhanded code to be there.

Stick a printf/file write/breakpoint at the root of the code path if you want continuous verification that the code path never executes except by clicking the button. This isn't hard.

You don't have to understand it in this case, you just have to make sure that code path isn't invoked by anything other than clicking the button. This can be pretty easily verified.

Hell, the investor themselves can demand this service. Call it empathy building, and remember, if you don't work 80 hours this week you get to go join the salt mine devs!