Stats on iAd for developers - <AUTHOR> http://www.crossforward.com/2010/08/25/iad-for-developers/

<comment><USER2> Is there any one-time $1 cost that companies advertise? I can't think of one.

I would say that one-time $1 products are in almost all cases unadvertisable. It's an economically inefficient use of advertising space. The best case scenario when someone sees his ad is a payoff of $0.70. That's the _ceiling_ for the value of the an ad impression, and in reality it's pretty much guaranteed to be far, far lower.

Compare that to, say, advertising a car, where the payoff of a conversion may be several thousand (in profit). Sure, the conversion rate won't be as high because it's so expensive, but the potential pay-off is so much higher that it doesn't matter.

The only ads I can see for products that cheap are consumables (like gum). There's a reason for that. Unless the ad space is seen by a niche that's incredibly likely to buy your product (yet for some reason not already own it), there are other companies that can get much more value out of that ad space, which means that there are companies willing to pay more for it than the revenue it will get you.</comment>


The New York City Subway Map as You've Never Seen It Before - <AUTHOR> https://www.nytimes.com/interactive/2019/12/02/nyregion/nyc-subway-map.html <comment><USER2> Looking at the 1978 subway map[1], I better appreciate the improvements since. It seems less daunting to someone who's never visited NYC yet.

[1] [https://www.nycsubway.org/perl/caption.pl?/img/maps/calcagno...](https://www.nycsubway.org/perl/caption.pl?/img/maps/calcagno-1978-system.gif)

<comment><USER3> Its stunning how geographically incorrect that map is. I can't believe the MTA/NYCTA/whatever would ever approve such a map.

<comment><USER4> That's a topic of a lot of discussion by transit planners. For example:

[https://humantransit.org/2013/11/should-transit-maps-be- geog...](https://humantransit.org/2013/11/should-transit-maps-be-geographical- or-abstract.html)

> _The geographic map helps you locate yourself and points of interest in the > city, but you need the structure map to understand how the system works._

</comment></comment></comment><comment><USER5> Huh, the title made me think there was a new map. This is just a deep-ish look at the current one.</comment>


The Road to Passenger 3: Phusion Passenger Lite - <AUTHOR> http://blog.phusion.nl/2010/07/01/the-road-to-passenger-3-technology-preview-3-closing-the-gap-between-development-and-production-rethinking-the-word-easy/

<comment><USER2> Good explanation of the differences between Passenger and something like Mongrel. To me, the ability to dynamically start and stop processes is what makes Passenger such a clear winner for what I do with it.

<comment><USER3> Just read the post. It confuses me a bit. It's mentioned in the beginning that the Lite version is a replacement for the local dev server. But later on in the post he emphasizes that it can also be used in production.

 _On the other hand, if you need integration into the web server, then Phusion Passenger for Apache/Nginx is for you_

Can anyone throw some light on the difference between using [Apache/Nginx]+Passenger and just Passenger Lite in the production environment? Why would I want to use a web server when Passenger Lite does what I require (serve the ruby app and also serve static files)

<comment><USER4> Several reasons: You might want to run other (possibly non-Ruby) apps on the same server; you might want to tweak settings, like the headers for certain files, to improve performance; you might want to do some URL mapping at the web server level; and you might simply want better static file serving performance (nginx is very, very fast).

That last point isn't an issue here because Passenger Lite has an "nginx core." So if you can configure that core, then the only reason you wouldn't want to use Passenger Lite in production is if you have non-Ruby apps you want to run on the same server.

</comment></comment></comment><comment><USER5> I know it's not planned (I asked them!), but for many small apps, it would be great to have a simple flag to tell Passenger "I need 1 worker (delayed_job, resque) for this app, please keep one alive", vs running monit or similar.

</comment><comment><USER6> While I think that Passenger Lite might be useful for development, I would think twice about deploying my production app without a full blown web server, just for the sake of being able to run non-ruby code if needed.

<comment><USER7> You could deploy it as a sibling process rather than a child. I would never deploy Passenger Lite really by itself -- I'd use god (like monit, but in Ruby) to run it, even if it's just one process. So making that two processes, one non-ruby, is easy.</comment></comment>


Literate SQL - <AUTHOR> https://modern-sql.com/use-case/literate-sql <comment><USER2> In defense of the "Performance Considerations" against postgres, I worked on a team that had a BI guy that regularly wrote giant multi page queries using WITH statements.

The main database was IBM DB2 9.7 on RHEL and it had about 3 months (800GB) of data in it (we pruned it nightly). We had a "reporting" database that was postgres 9.3 or 9.4 (can't remember). It was the same schema but was never pruned. It had about 15 billion rows total and about 5TB of data. About 700GB was indexes. The same query when ran on DB2 took 12 hours, on postgres (5x more data) it took 24 hours.

The query plans were mostly identical (neither one did much to optimize the WITH statements). The speed difference seemed to come from Postgres just accessing the disk better.

When doing an index scan, the disk read speed was about 80MBs, while DB2 was 10MBs. Full table scans in Postgres were between 180-220MBs while DB2 was around 60MBs. Same storage too (netapp over nfs). DB2 was using direct IO so it like to read in 4k chunks, but even disabling that didn't help much.

<comment><USER3> > The same query when ran on DB2 took 12 hours, on postgres (5x more data) it > took 24 hours.

You're doing it wrong. These type of queries should be run on a column store (e.g., Vertica).

<comment><USER2> All the money was flowing to IBM licenses. Hence when we needed another database for reporting, we went with open source. Vertica is big money++ And really, after my stint with that company, I really can't stand commercialized licensed software anymore.

<comment><USER4> Did you look inte monetdb? I'm curios about real world experiences with that one.

</comment></comment></comment></comment><comment><USER5> IMO, Microsoft got it right way back when with LINQ syntax. They did it for a different reason (to make things easier to convert to a sequence of plain, old fashioned method invocations), but the idea was the right one. For those who don't know, in a LINQ query you first specify the data source(s) and joins, then your filtering logic, then grouping and ordering, and then your projections, including projections into objects and anonymous structs. That's just the way it oughtta have been from the start. As a bonus, it also simplifies things like autocomplete, because you know the data sources up front.

</comment><comment><USER6> This is a gem of a website, thanks for posting. For all the noise about NOSQL and ORM tools, there will always be a humongous number of situations where SQL is unavoidable (or even the best tool for the job).

</comment><comment><USER7> A somewhat related tip that works in SqlServer (not sure about other dialects) is to put the column alias first rather than at the end of a calculated column. E.g. rather than:

      SELECT
        Foo,
        Sum(Baz) AS Bar
      FROM Quux

Use instead:

      SELECT
        Foo,
        Bar = Sum(Baz)
      FROM Quux

The advantage here is that the names also line up neatly and the shape (column names etc.) of the result is obvious.

<comment><USER8> I'm so used to using and reading the "AS" syntax for aliasing that if I came across this it'd throw me off.

It seems to me that sticking everything in CTEs would be equally as jarring. Writing SQL or reading and understanding someone else's SQL is almost always a non-linear process, not least of all because the processing order by the database engine isn't top-to-bottom.

<comment><USER7> It took a minute for me to accept it as well, but once I did the queries just look so much better.

</comment></comment></comment><comment><USER9> Completely agree with this - last week I was writing a query with one of our junior developers. Rewriting to use a couple of with clauses with very descriptive names immediately made the intention clear. The with clause is really the clean code enabler for my SQL.

</comment><comment><USER10> WITH statements seem convinient. But nested recursive SQL statements / subqueries can be an performance issue. Sometimes speed is more important than a SQL99 or SQL2003 feature, some implementations are fast with SQL89/92 syntax.

</comment><comment><USER11> Using SQL Server my normal pattern of development is to do what I need using CTE's (WITH) and then switch to temp tables if/when the queries start to show poor performance.

<comment><USER12> That's valid, but you want to keep in mind that SQL Server has ONE tempdb that is used across _all_ databases. TempDB is used for temp tables, but TempDB is used for a raft of other features (like snapshot isolation). You need to ensure you don't start getting tempdb contention.</comment></comment>


Java 8 Lambdas - <AUTHOR> http://datumedge.blogspot.co.uk/2012/06/java-8-lambdas.html <comment><USER2> 'sorted()' doesn't really act like that, does it - taking in a comparator function?

It's much better to have comparator functions for the most common types baked in, and use projection to select a list of fields to use to compare with.

Comparator functions are very easy to get wrong. The example given here - ".sorted((a, b) -> a.getValue() - b.getValue())" - won't work properly when the calculation wraps around.

<comment><USER3> > It's much better to have comparator functions for the most common types > baked in, and use projection to select a list of fields to use to compare > with.

Except that requires a sorting key for the result. Trivial for dynamically typed languages, but how do you handle the type of that key in a statically typed language? Mandate that the key be a string? Build a limited set of overloads against a dedicated type? And even then, how do you specify the relative constraints of the different values within that key, especially within the limitations of java's type system?

> The example given here - ".sorted((a, b) -> a.getValue() - b.getValue())" - > won't work properly when the calculation wraps around.

But that's less an issue of "comparator functions [being] very easy to get wrong" and more an issue of "integer is an asinine type to use as ordering result". Even more so in a statically typed language. Haskell uses a dedicated enumerated type[0] which does not have this issue.

[0] [http://hackage.haskell.org/packages/archive/base/latest/doc/...](http://hackage.haskell.org/packages/archive/base/latest/doc/html/Data- Ord.html#t:Ordering)

<comment><USER2> I don't know what you mean by "sorting key" in this context. The idiom I have in mind is how .Net implements "SortBy", "ThenBy" and friends. Overloads can be used for a comparator function based approach, but it should not be the first choice.

And I'll stand by comparators being easy to get wrong, particularly when values may be null, polymorphic, etc.

<comment><USER3> > I don't know what you mean by "sorting key" in this context.

The result of the projection which is associated with each value and used to actually sort the values.

> The idiom I have in mind is how .Net implements "SortBy", "ThenBy" and > friends.

I assume you mean OrderBy. I see, instead of having sorting as a single atomic operation it becomes a stateful multi-step transformation of the iterator. I can still see weirdness in it: what are the constraints on the return value of the key selector functions? The MSDN does not list any, but that can't be right: what if the key selector returns a value which can not be sorted itself?

> And I'll stand by comparators being easy to get wrong, particularly when > values may be null, polymorphic, etc.

Trivial key extraction does not make that any easier: instead of being hard, hard cases become impossible.

<comment><USER2> > > And I'll stand by comparators being easy to get wrong, particularly when > values may be null, polymorphic, etc.

> Trivial key extraction does not make that any easier: instead of being hard, > hard cases become impossible.

Perhaps you missed this bit:

> > Overloads can be used for a comparator function based approach, but it > should not be the first choice.

Key extraction makes trivial cases _less error prone_ than comparators; overloads can be used to make the hard cases possible. Comparators everywhere make all cases error-prone.

</comment></comment></comment></comment></comment><comment><USER4> Finally... and they even infer the type! Positively surprised. I will stick to Scala, though.

<comment><USER5> They can't _really_ infer the type. You just have to have one less set of pizzas. It doesn't work like scala's type inference.

<comment><USER6> It really does infer the type of the lambda. See Part F of the specification:

[http://download.oracle.com/otndocs/jcp/lambda-0_5_1-edr2-spe...](http://download.oracle.com/otndocs/jcp/lambda-0_5_1-edr2-spec/index.html)

<comment><USER5> ah yes I see what you mean. My bad.

</comment></comment></comment></comment><comment><USER7> Would have been a big deal - if they introduced 10 years ago

<comment><USER8> Java is still widely used. I'm looking forward to this -- there are some projects we can't take to Scala due to client concerns around a less mainstream language.

<comment><USER9> > Java is still widely used. I'm looking forward to this -- there are some > projects we can't take to Scala due to client concerns around a less > mainstream language.

I hope I am wrong but I smell a trap here. Some time ago I implemented a solution (for .Net, that is) that employed some more modern techniques ( reflection, recursive lambdas, etc). Unfortunately many of the programmers in charge of maintaining my code were either interns from a local technical school or an outsourced company in India. They couldn't get their heads around the techniques I used. They thrashed my code, I ended with a bad reputation and lost the client. Not something I regret, anyway.

<comment><USER10> I smell trolling, however considering this anecdote is genuine:

(1) interns should never be allowed to commit code in the master branch without a code review from a senior developer

(2) there are many competent developers in India, or around the world, so if your company needs to outsource, it can do so by being a little careful about who they employ

(3) if the above 2 are not possible, simply look for another job, because life is too short

<comment><USER11> I can give many examples where I've handed code over and later there was problems due to less-skilled developers.

One good example I have is being called by a client who had a bug they couldn't fix in some code I had written years before. After looking into it, I found something like this:

        // ABC 1/1/2001 removed this call as we don't understand why it was being called
        // x = performImportantCalculationABC();

There are lots of terrible programmers out there. The average level of programming skills on HN is considerably higher than you'll find at most companies.

I've seen so much bad code written by people with senior job titles; confusing, ugly, inflexible, but working code.

<comment><USER12> You're forgetting that the smarter programmers realise all they need to do is fix something really fast, so their managers are like, "oh my goodness, you're excellent!" but if you get caught up on the details, spend several weeks "fixing" something that your manager won't even see or understand, you're a shit programmer.

So really, you gotta get your priorities straight.

<comment><USER13> If your priority is "ingratiate yourself to your manager" then yeah, it's best to pick small superficial problems or prefer patch-job fixes. These decisions tend to be informed by how much technical debt the "short" fix makes.

But if a problem genuinely will take 6 weeks to solve, then it's probably a worthwhile problem to solve. Those sorts of problems tend to have far-reaching implications for sites and their ability to scale. The big question is _when_ to solve it. Competent engineers know when to do this.

Managers who can't see this? Bad managers. Bad managers can kill a startup just as effectively as 'rockstar' engineers.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> The idea of 'default methods' looks quite disturbing. It seems to allow implementation of some methods inside interfaces. Which is against the basic idea of interface, isn't it? Correct me if I'm wrong, but multiple inheritance problems form C++ are now going to be a brand new feature in Java.

<comment><USER15> There's no difference between implementing method dispatch with multiple inheritance versus multiple interfaces. What do you think C++'s multiple inheritance problems are? As long as Oracle doesn't add data members to interfaces, Java won't get any new problems.

<comment><USER14> I might be missing something, but what I see as a problem is a situation where: class C implements interfaces IA and IB, which both contain method doSomething() with default implementations, class C doesn't overrides this method, so which implementation is going to be called when method doSomething() will be invoked on instance of C? Will it behave the same way if it is called as instance of C and as instance of IA or IB? Clearly, there are rules in C++ to handle such situations, one may argue that they are problematic.

<comment><USER6> If there is no way to break the ambiguity the compilation will fail and you will have to override that method (in 126.96.36.199 of the spec). You can use IA.super or IB.super to call one of the default methods if one of them works for you and you don't need your own bespoke implementation.

<comment><USER14> Thanks for clarifying; although I don't really like this feature, compilation failure seems to be the best solution (and well I guess I should have RTFM to begin with, sorry).

</comment></comment></comment></comment></comment><comment><USER16> I was recently at a Java conference where Juergen Hoeller (of Spring fame) was a keynote speaker. In one of his talks he said something like "Once again, Java is solving yesterday's problems". The moment he said that, I thought to myself "Yes! So true!". The day before, Angelika Langer gave a talk on Lambdas in Java 8. I watched as the other developers listened with half-opened mouths (and some of them, with confused expressions on their faces) and wondered why, instead of bolting features other languages have had for decades onto Java (potentially leading to another fiasco like generics), Oracle doesn't instead continue to work on the JVM to give an even better support for languages that already do have these concepts (by, for example, providing support for TCO).

<comment><USER17> I don't understand or agree with your logic at all. Oracle shouldn't waste time on Java because it is already so far behind as to be hopeless? That notion seems silly at best, especially as 99% of code written on the JVM is still done in Java.

Also, generics fiasco? Generics may not be perfect, but I haven't met a single person who isn't glad that they are in the language. Who has done generics better? C#? Because C#'s type system is baked so heavily into the run time, the CLR actually has a harder time supporting languages with more powerful type systems than does the JVM.

See, for instance, this post: [http://olabini.com/blog/2010/07/questioning- the-reality-of-g...](http://olabini.com/blog/2010/07/questioning-the-reality- of-generics/). Both Ola, a JRuby developer, and Martin Oderskey, the creatir of Scala, prefer the JVM's type erasure to the reified generics of the CLR.

<comment><USER18> As a "language snob", I feel that Java is hopelessly behind among JVM languages. But I also think that C# is well-designed enough that it doesn't matter whether it's the only CLR language I'll ever use. I don't know if the grandparent poster feels the same, but your post actually _confirms_ my opinion.

Of course I have no realistic idea how Oracle would ever migrate millions of Java coders to a cleaner language. :(

<comment><USER19> >>As a "language snob", I feel that Java is hopelessly behind among JVM languages.

Java is designed by its existence to be a better C++, nothing much. Nothing changes that base design goal.

But this is a design goal for the late 80's and early 90's.

The fate of most Java-only programmers, which are uncountable today is pitiable to say at the least. Its like Dijkstra said, one must avoid prolonged exposure to bad tools. Because they permanently damage your brain. Oracle will never do away with Java, its their bait to sell their products. Most Java programmers will go the COBOL programmers way- "Employable only at MegaCorps"

<comment><USER20> > "Employable only at MegaCorps"

Usually it comes with a salary full with nice digits.

</comment></comment></comment></comment></comment><comment><USER21> I don't know how I feel about interface defaults. Why is that more important than say declared properties or unsigned types?

<comment><USER6> They are hugely important for introducing new behavior on existing interfaces without breaking compability. They are at the core of what is going to allow you to use all the new functional-style collection methods on your old collections without changing your implementation code at all.

Declared properties and unsigned types are relatively small changes. BTW, in JDK8 they have provided limited support for unsigned types, just not at the language level:

<https://blogs.oracle.com/darcy/entry/unsigned_api>

<comment><USER22> Agreed and it's an order of magnitude better than extension methods which .Net uses for the same functionality!

<comment><USER23> C# extension methods are used for considerably more than adding new methods to existing interfaces, though that is a valid use of them.

They also don't require you have access to the source (anybody can write an extension method on System.Collections.IEnumerable, not just the BCL team). That they work on any type (not just interfaces) also makes them considerably more general than default implementations.

I also find the idea of an interface carrying implementation a little weird, the abstract class/interface line gets a lot blurrier.

That said, lambda support that only worked on new code would be pretty lackluster; so it's good some thought has gone into getting them into legacy code.

<comment><USER22> The problem I have with extension methods is semantics and determinism, particularly in the collections framework (if you can call it that - it's a mess). Great example:

Look at System.Core's Count() inside reflector. Using pseudo code:

      def count(ref):
          if ref is ICollection:
              return (ref As ICollection).Count
          else
              n = 0
              for each item in ref:
                  n++
              return n

That hurts badly if you are not careful. Enumerables will be iterated and collections will return length so when you call it you don't know for certain if it's O(N) or O(1). If someone has downcast ICollection<T> to IEnumerable<T> then you really don't know where you stand.

It's shit like that which is hard to debug and brings your system to its knees.

<comment><USER23> What about interface defaults prevents or precludes that hack/optimization? You have exactly the same information after all.

For example (disclaimer, it's been a bit since I've touched these classes; but you should get the idea), an extension of Iterator that adds a longSize() method would probably want to make use of ArrayList's size() rather than iterating over the whole thing too.

As an aside, if your code absolutely and utterly depends on a certain operation's runtime performance you had better be using a type that actually guarantees that performance. List<T> guarantees Count is O(1) ( <http://msdn.microsoft.com/en-us/library/27b47ht3.aspx> ) , IEnumerable<T> doesn't ( <http://msdn.microsoft.com/en-us/library/bb338038> ); that's your bug.

<comment><USER24> You're missing the point. The problem is that as an author you have to implement an interface which is probably completely unrelated to what your class is doing, otherwise you get punished by bad performance.

Scala solves this problem nicely with traits, btw.

<comment><USER25> I may also be missing the point but what prevents you from putting a count method on an enumerable with a default implementation which does the same?

In terms of .Count() which will attempt to call ICollection.Count you can create the same thing as an extension method or a default implementation on Enumerable.

Either way you do it you will have ambiguity regarding time complexity.

Extension methods have the advantage that the langauge designers _could_ have left .Count() off IEnumerable and then people who wanted to use it could implement it themselves and those worried about the ambiguity wouldn't have to risk people enumerating their collection needlessly.

The problem with extension methods over default implementation interfaces is that the code regarding a class can be distributed in several (potentially non-obvious) locations and it reduces portability.

The advantage is that you can extend a class or an interface you don't own, and you can have implementations specific to a given namespace.

So for a (poor) example you might extend float so you could convert an angle to a 2d unit vector, but only in given bits of your program you want to be converting between angles and vectors.

<comment><USER24> > I may also be missing the point but what prevents you from putting a count > method on an enumerable with a default implementation which does the same?

Isn't that exactly what we're talking about?

The huge difference between C#'s extension methods and traits is that the first one is statically dispatched, the second one dynamically.

This means classes with a better implementation can just override Count() and suffer none of the problems of the extension method approach.

Scala also offers implicits to "enrich" existing types, slightly comparable to Extension methods, but a lot more general.

Whereas extension methods only support some ad-hoc "addition" of members to existing types, Scala's implicits allow you to use these methods to implement new interfaces -- and isn't that the reason why you add methods in the first place: to implement interfaces?

> So for a (poor) example you might extend float so you could convert an angle > to a 2d unit vector, but only in given bits of your program you want to be > converting between angles and vectors.

       implicit def floatTo2DUnitVector(angle: Float) = 2DUnitVector(...)

Done. Import where you need it.

Btw, C# has some limited form of implicits, too, but I haven't seen any serious usage of them for a while.

<comment><USER23> > This means classes with a better implementation can just override Count() > and suffer none of the problems of the extension method approach.

Instance methods are bound before extension methods, if someone provides an implementation of Count() in a subclass it'll be invoked instead (provided your reference is typed appropriately). More narrow extension methods are bound before general ones, so you can even "override" within extension methods.

Scala has some neat stuff, but it's not Java 8 so I don't see how it's relevant.

> Btw, C# has some limited form of implicits, too, but I haven't seen any > serious usage of them for a while.

C# has implicit conversion operators you can define, [http://msdn.microsoft.com/en- us/library/z5z9kes2(v=vs.100).a...](http://msdn.microsoft.com/en- us/library/z5z9kes2\(v=vs.100\).aspx) . You'd better have a really good reason for defining one though, silent conversions are generally frowned upon.

<comment><USER24> That's exactly the issue I'm talking about: you can't "enforce" the static type, so different methods get called depending on whether you pass List foo = MyList(...) or MyList foo = MyList(...), which is acceptable for static methods, but a source of bugs when they can be made to look like instance methods.

> Scala has some neat stuff, but it's not Java 8 so I don't see how it's > relevant.

Java's default methods are basically Scala's traits (just made a bit more cumbersome to make Java developers feel right at home), so what I said about traits applies to "interfaces with default methods", too.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER26> I do not understand how this really any different that what we already have with anonymous classes/interfaces. If we have to continue to define interfaces for our lambdas then we might as well continue to use anonymous classes and remove the final restriction (that's completely backward compatible). The final restriction wasn't required in the original design of anonymous classes before the community freaked out over memory allocation of primitives. The reason closures are a pain in Java is having to meet the static typing declarations using interfaces for our anonymous classes. The whole point to this was to create a compact syntax for declaring methods that take lamdas as parameters without resorting to interfaces.

I also wish that default mechanism could be extended to existing classes as well so we could add methods to classes because the real question is what are the API changes to collection, File, etc with respect to the addition of lambdas. The places where Java has fallen short in the past is the API (Collection.join? Collection.map, Collection.reduce, new File( String... paths), etc).

</comment><comment><USER27> It kinda sucks that you still have to declare an interface in order to pass functions around.

</comment><comment><USER28> Will you be able to _return_ lambdas or just _create_ them as function inputs? (I guess you can write a method which takes an object of interface X and returns it, but do you have to do this for every interface you want to use, or would there be a universal reify() method? Is there a universal interface which would allow these to be proper first-level functions?)

If there are competing lambda interfaces, does the system fail at compile- time?

</comment><comment><USER29> I'm curious to see what the implications are for other JVM languages given the promise of more efficient byte code.

<comment><USER6> That is already released in JDK7: the invokedyanmic bytecode -- JRuby is probably on the forefront of taking advantage of it.

</comment></comment><comment><USER30> Looks like they took a page from the Groovy language

</comment><comment><USER31> Nice - only 5 years late though.

</comment><comment><USER32> Hopefully no one with any sense will use these features.

</comment><comment><USER33> Congratulations to the Java-programmers for getting a feature that virtually every other OOP language has had for about 10 years.

<comment><USER34> Care to elaborate? Ruby had them from day 1, PHP has only had them since 5.3, not sure what the deal is with python.

<comment><USER35> C# has had them for a little while now.

<comment><USER36> OT, but all this language comparison got me wondering: has anyone implemented C# on the JVM? :-)

<comment><USER21> yes, Mainsoft Grasshopper. But given that the CLR is superset of JVM features, you can't easily convert .NET MSIL to Javabyte code (a few research projects tried but it's not pratical). Grasshopper did it at a language level and wrote a C# to Java bytecode compiler.

However going the other direction is really easy and straight forward. IKVM.NET has been running Java on top of .NET for years.</comment></comment></comment></comment></comment>


Ask HN: Web programming for a C++ server developer? - <AUTHOR>

I've been programming low-latency, high throughput C++ systems for more than 5 years now, but I wanted to try my hand at some simple web development. Compared to 5-10 years ago (I'm 26 and haven't programmed for the web in a while), the sheer number of frameworks and add-ons to those frameworks is a bit overwhelming.
I've started to implement my site using Django as I'm a moderately proficient Python programmer but would be open to switching to another framework for a compelling reason. Also, where can I find resources to learn the more client facing stuff (AJAX, CSS, basic layout and design, etc)?
As an aside, has anyone else been through this before (i.e. much more comfortable with back end work but want to implement an idea you've had)? What did you do in that situation? <comment><USER3> I went through that jump about a year back, so here are some of the things that I've gleaned:

\- You'll be doing a lot of JS. Just use jQuery. It's the most popular of the JS / AJAX frameworks, so even if you decide not to use it later on, it's a good starting point.

\- I dig Ruby / Sinatra. Never really got into Rails or Django. You can learn how to use Sinatra + Haml + Sass in a few minutes. I've also learned that, somewhat to my surprise given my previous perception of their fan-bases that I don't really like Python and much prefer Ruby.

\- For novelty there's Wt (<http://www.webtoolkit.eu/wt>), haven't brought myself to actually use it for anything though.

\- CSS grid layout "frameworks" make things easier. I used (<http://code.google.com/p/blueprintcss/>) for our new site, but can't say that I had much love for it -- though still much better than doing all of the layout by hand.

<comment><AUTHOR> What specifically about Ruby leads you to prefer it over Python? Are there better/more modules or is the language itself more expressive or powerful in some way?

Also, was there a specific reason you chose Sinatra over Rails? I'm not familiar enough with either to make an informed decision so it would be interesting to hear others opinions.

<comment><USER4> As to ruby or python, I think its a matter of taste. Both are powerful enough.

Coming from C++, Rails might drive you nuts. I like to be certain of what my code is doing. To achieve this with Rails, you either have to: 1 - <USER2> _loads_ of tests or 2 - dig through Rails source to ensure the DSL does precisely what you think it does. You don't want option 2 as Rails source is a nightmare. Option 1 may not fit your sensibilities if you're used to writing defensive code and writing too many tests seems a waste of time.

I can't speak for digging through Django source nor can I speak for how clearly documented the DSL-like things are.

If you want more control over your app behavior or simply see what's going on easier, the python world has webpy and cherrypy. The Ruby world has sinatra. Something in between Rails and sinatra is merb.

<comment><USER5> In general, Django is considerably more explicit about what it's doing (particularly after the "magic-removal" branch two years ago). The implicit trade-off is that some things that Rails does automatically you have to declare explicitly in Django, but it hits the sweet spot for me.

My understanding is that Rails has trended that way lately, but since I don't use it day-to-day I can't say whether that's the case.

I can't compare the Django source to Rails, having never really read the latter, but on its own it's pretty good. Like any large-enough pile of code, there are ups and downs, but whenever I've had to dig in and understand what's going on, it's been fairly straightforward to follow.

<comment><USER4> Rails has certainly become loads better. But the source is still cryptic to anyone but a ruby master. Rails 3 is in the works which is turning into mostly a full rewrite as near as I can tell. I expect Rails 3 code base to be much easier to understand. But that's not out yet and when it is, I expect you'll need to wait a year before enough of the libs and plugins are running smoothly.

It sounds like you have enough python under your belt and like django well enough. I'd recommend going with that. Your not missing out on some other framework/language pair that is more powerful.

I use ruby/merb. I occasionally look around for something I like better but nothing is worth the switching costs at this point.

</comment></comment></comment></comment></comment><comment><USER6> > _I've been programming low-latency, high throughput C++ systems for more > than 5 years now_

You _will_ cringe at the web stuff then. Lots and lots of CPU cycles are wasted to shorten the development cycle and simplify (dumb down) the life of the developers. Layers upon layers of abstraction. Using PHP to generate a _static_ HTML page is not a big deal. This sort of thing.

It certainly makes a lot of business sense as the hardware is cheap, and the labor is not. But if you are used to squeezing every last drop of performance from you code, it will be painful to look at some of the web stuff.

</comment><comment><USER7> I'm in the same situation. I've never really written a DB-backed web-based application, so I'm starting down that road. Been working mostly on C++ distributed multi-threaded servers with lots of asynchronous network communication.

I'm a big Perl fan and am comfortable with its object-oriented model so I've chosen to use it. Here's the environment/tools I've settled on so far: Apache on Linux (primary platform, might try to make sure works on Windows too); mod_perl 2 in Apache pre-fork; PostgreSQL 8.x for back-end; Rose::DB for DB persistence layer (apparently easy-to-use ORM, allows many-to-many relations unlike various other Perl-based DB layers); Template-Toolkit 2 for web template environment; going to layer on JavaScript later ... not sure which library to use yet.

To some this may not be the ideal environment or the most current or most up- to-date set of tools. For me though it seems the quickest way to seriously explore and understand web issues.

I have a big hole in my software experience where several web apps should be, and I need to fill it with something. Might try Django or some other Python tool later. I'd actually like to try Twisted some time (asynch Python network engine, not web-specific).

</comment><comment><USER8> Coming from C++, if you do not want to become crazy using untyped languages you might be interested by the haxe programming language.

A nice inference typed language which can be compiled down to neko bytecode (much like java bytecode), JavaScript (for the client side), Flash movies (idem), and even C++

Plus, haxe has a mod_neko for apache and lot of libraries to manipulate databases and templates.

<http://www.haxe.org></comment>


Building Habits with Reminders - <AUTHOR> http://kaisdavis.com/building-habits-with-reminders/

<comment><AUTHOR> Hey HackerNews,

I wrote a piece about how I'm working on habit change with reminders on my iPhone. Why HackerNews?

• Are you struggling to add a habit to your life (on- or off-online)? At my last job, I needed to force myself to take breaks / lunches and go outside.

• Are you forgetful? Do you wish you could have something else remember those little habits for you during the day?

Let me know if you have any feedback!</comment>


Jeff Bezos: we must leave the planet and send people to live on the Moon - <AUTHOR> https://www.independent.co.uk/life-style/gadgets-and-tech/news/amazon-jeff-bezos-moon-space-blue-origin-latest-resources-a8373151.html <comment><USER2> Any sort of non-toy moon colony is simply a toy for (super) rich

It is probably cheaper and safer to repopulate 100K back to Chernobyl/Fukushima than it will ever be to put 1000 on the moon.

It is cheaper to encourage systematic recycling (including subsidies, research, regulation and tax) than it is to mine anything in space.

It is cheaper and more effective to start an extinction level protection program here on earth (to save say 100K people) than it will ever be to build a true independent space colony.

Sure - it has scientific value and its progress, and its a stepping stone to Mars, etc.

But economically this is the equivalent of buying a Ferrari while you still have student debt.

<comment><USER3> Getting heavy industry off the earth soon may be a matter of survival. Not to mention the best extinction protection program we could reasonably hope for that might save other species as well.

I agree that we should take far better care of our cradle: but by now there's a mountain of evidence that we won't.

Do you think colonizing North America was a complete boondoogle?

Ben Franklin's reply is best, since he got the same kinds of criticism for spending money exploring the phenomenon of electricity: "Of what use is a new- born babe?"

</comment></comment><comment><USER4> If you're going to put workers in space its far more economical to put robots on the moon than humans. A fully automated space operation could be run without turning human lives into total hell. The mars robots are even able to self-repair to a degree. Humans living on the moon would be the worst job ever, but robots don't get cancer they don't need breaks or recreation areas or domed cities.

<comment><USER3> We'll get there, but they're still having to do spacewalks from the ISS; despite having some robot help there.

</comment></comment><comment><USER5> Leaving the planet is meaningless if you still must rely on Earth for support. The moon is not going to be self-sustaining in any feasible future we might live to see. We're stuck on Earth for now, let's try to deal with it. Besides, if we can't survive the fertile planet of our species' birth what kind of lunatic arrogance makes us think we'll survive a lifeless, airless rock?

</comment><comment><USER3> Bit better story IMHO: [https://nypost.com/2018/05/28/jeff-bezos-planning-for- moon-c...](https://nypost.com/2018/05/28/jeff-bezos-planning-for-moon-colony- within-decades/)

</comment><comment><AUTHOR> The moon: the ultimate company town, where all the workers are completely dependent on the corporation.

</comment><comment><USER6> Space reality shows are the future!

</comment><comment><USER7> >implying humans have ever been to the moon

This will never happen, at least using conventional technology. It's just a fantasy to placate the masses. After another decade or so of CGI videos, they will just say that Kessler syndrome has made spaceflight impossible, or they will create virtual reality simulation environments to fool people into thinking they are traveling in space, when they are really in an underground military base somewhere.</comment>


When the Weapon Was Pointed at Me - <AUTHOR> http://inessential.com/2015/10/17/when_the_weapon_was_pointed_at_me <comment><USER2> Not being familiar with the original context, this is unfortunately meaningless other than in the general sense of 'mobs are bad.'

<comment><USER3> Mobs are bad. Don't join them, even though it's really easy to do so. And don't take it personally when they attack you, because it's really easy for people to do that thoughtlessly, and they actually don't hate you nearly as much as they sound like they do.

<comment><USER2> I didn't have any problem understanding his point, but I have no idea what personal experience he's talking about so I don't know how to evaluate his description of getting piled on.

<comment><USER4> His experience doesn't matter. The result doesn't depend on what you've done.

Try to imagine how it feels to be one of the last two idealistic volunters who work on a critically important open source crypto library when a major security bug is found and many thousand people decide to tell you what a shit you are and what shit your code is. That's not what Brent did, but if Brent and those two idealists were to meet and compare their inboxes, I bet they would look similar.</comment></comment></comment></comment>


New developer YouTube Series: "Build Out" - <AUTHOR> https://developers.googleblog.com/2017/11/introducing-our-new-developer-youtube.html <comment><USER2> Thinly veiled ad for Google Cloud products.

The blog describes this as "a new YouTube series where real engineers face-off building fake products". But they do not build anything. They just describe the architecture.

I would keep watching if there were actual coding, or even if someone spent two days prototyping and simply described some of the gotchas they ran into along the way.

<comment><USER3> > Thinly veiled ad for Google Cloud products.

I skipped to the middle and this is my thought exactly. I skipped straight into one of the guys rattling off why chose to use three different completely unnecessary in this case Google cloud products by listing off the benefits of them... ugh.

Could be titled: "how to ridiculously over-engineer something using every Google cloud feature you can cram into one project"

Too bad, I had my hopes up.

</comment></comment><comment><USER4> It'd be cool if they, you know, built something instead of theory crafting convoluted architectures.

Also it's kinda a reverse ad when you need to hack around limitations of your product when trying to sell it. Oh, app engine 'standard' vs 'flex' \- or 'regular' vs 'cloud' APIs which is a distinction your customers shouldn't have to care about.

</comment><comment><USER5> First we find out the "Arbitrary requirement" of this episode is: Google cloud tasks API.

Then:

        Most DIY CNC arms are controlled by a Raspberry Pi,
        but for a smart garden, we need something that has
        easier interfaces to Internet connectivity and
        sensors, so I'd like to add an Android Things Hub.

What?

This is an ad for Google

<comment><USER6> I don't think they are hiding it either

[https://youtu.be/8uTcwgWhnb8?t=29s](https://youtu.be/8uTcwgWhnb8?t=29s)

</comment></comment><comment><USER7> Francesc Campoy's Just for Func series is much better [https://m.youtube.com/watch?t=420s&v=mTd3hHUy9OU](https://m.youtube.com/watch?t=420s&v=mTd3hHUy9OU)

Also by a Google engineer and using Google Cloud products, but it's actually a lot of fun to watch.

<comment><USER8> Thanks for this. I poked through his videos and I agree with your sentiment.</comment></comment>


Soyuz MS-10 makes emergency landing after a launch failure - <AUTHOR> http://russianspaceweb.com/soyuz-ms-10.html <comment><AUTHOR> Not a dupe, a detailed recap of the incident today.</comment>


Up to 80% of Covid-19 infections are asymptomatic - <AUTHOR> https://thorax.bmj.com/content/early/2020/05/27/thoraxjnl-2020-215091.full <comment><USER2> where's the follow up testing on this group of people to see if they eventually have symptoms. this has been done in other countries, such as italy and after 3 weeks 90% has symptoms. this data point alone only shows that there is an incubation period. drawing this conclusion that 80% will remain asymptomatic is misinformation.

<comment><USER3> The lack of follow up is indeed rather frustrating. On the plus side, the article reports that they kept the people in quarantine 8-12 days after the testing round. From other sources on the Web, "on average symptoms appear after 5 days and most people with symptoms had them by day 12". While the study has probably accounted for most of the symptomatic cases, a 30 day follow up would be of great value, including to validate the incubation period estimations.

[https://www.webmd.com/lung/coronavirus-incubation- period](https://www.webmd.com/lung/coronavirus-incubation-period)

</comment></comment><comment><USER4> Expert comments FWIW -

[https://www.scimex.org/newsfeed/expert-reaction-how- common-i...](https://www.scimex.org/newsfeed/expert-reaction-how-common-is- asymptomatic-covid-19)

<comment><USER5> No opinions needed, there are too many opinions already floating around. Fact is that the ratio is 1/10, according to all antibody tests worldwide. This also matches the IFR/CRF discrepancy of 0.3%/3.4%.

So 90% is more likely.

And to the opinions: The extremely high dark figure could explain the high reproduction rate of r3.5. People who think they've only got a cold happily will infect others.</comment></comment>


State of TV: It All Comes Back to Content...With Some 'Big Buts' - <AUTHOR> https://www.linkedin.com/today/post/article/20140325121553-302586666-state-of-television-it-all-comes-back-to-content

<comment><AUTHOR> As someone with 15 years experience building TV technology, my statement is: this is a must-read for _anyone_ who wants to build, invest in, or otherwise "play" in this space.</comment>


Instagram URL glitch leads to outage across Twitter, Facebook (update) - <AUTHOR> http://www.theverge.com/2013/3/21/4132146/instagram-photos-not-appearing-on-twitter-facebook-url-shortener-bug <comment><USER2> Here's a screenshot I took of the DNS propagation yesterday: <http://i.imgur.com/SVML7Wi.png> Looks pretty bad!</comment>


A Week of Mining Seattle's Craigslist Apartment Pricing - <AUTHOR> https://racketracer.wordpress.com/2014/12/23/a-week-of-seattles-craigslist-apartment-pricing/

<comment><USER3> Pretty cool analysis! Scrapy is great but if you're looking to extend this further, I recommend checking out the 3taps API. 3taps is the only API I've seen that breaks down the different components of a Craigslist post (e.g. heading, price, number of bedrooms) and makes it available for scraping. Using 3taps will also make it easy for you to extend the analysis to new cities (you literally change a single parameter). And you should set up a cron job (or Heroku scheduler task if a web app) so you don't have to run the scraper manually every day :-)

If you want to check out an example of automated Craigslist scraping, you can check out a search tool I built (craigslist-scraper.herokuapp.com) and the accompanying tutorial (baserails.com/apiscraper). Both are best viewed via laptop.

</comment><comment><USER4> I like the varied analysis! Though, if you want to build a prediction model, it's probably best to avoid variables that can be gamed, e.g. # of pictures in a listing... For the larger zip codes, a heat-map of prices might help cut them down to more consistent behavior for prediction. Keep iterating - <USER2> love to see your progress over time!

</comment><comment><USER5> Did you do anything to avoid an IP ban for the crawler?

<comment><USER6> I'm curious about this too, especially since OP says they'd like to continue scraping. I've heard of other people crawling craigslist getting banned pretty fast and even one site getting slapped with a lawsuit [0]. (Which looks like was not entirely successful for craigslist.)

Craigslist has even taken some measures to get their users to assign copyright of the content over to craigslist themselves [1].

[0] [http://venturebeat.com/2013/05/01/padmapper- craigslist-3taps...](http://venturebeat.com/2013/05/01/padmapper- craigslist-3taps/) [1] [http://www.on-site.com/what-you-need-to-know-about- craigslis...](http://www.on-site.com/what-you-need-to-know-about-craigslist- copyright-assignment/)

<comment><AUTHOR> I scraped it probably at least 50 times and nothing has happened. I heard that craigslist only blocks IPs that direct a lot of traffic toward their sites like Padmapper did.

</comment></comment></comment><comment><USER7> That's really neat.

Fun fact - many apartments run by management companies / owned by institutional investors dynamically price their units on a daily basis based on the number of phone inquiries, walk ins to the leasing office, occupancy rates in the neighborhood, and many other factors.

Ex: [http://www.realpage.com/yieldstar/](http://www.realpage.com/yieldstar/)

<comment><USER8> Yes, and scraping their publicly-posted apartment rents daily for a couple months can reveal patterns that'll save you a decent chunk of your lease.

Biggest determinant is supply of a particular unit size, though. If there's five one-bedrooms available in a yield-managed complex, you're getting a better deal relative to the building than if there's only one one-bedroom remaining - sometimes to the tune of hundreds of dollars a month.

<comment><USER6> A few other products out there apart from YieldStar include LRO and Rent Maximizer.

It's fascinating how much goes into the pricing. It's all based on quite a few variables, ranging from availability (like you mention), competing communities in the area, lease end date optimizations (I don't want >X leases expiring in one month, since that's a lot of work for my leasing staff), time of year, and price history. And on top of this, prices can change daily.

I've had the chance to work on a revenue management product myself--and I can safely say that it's changed my perspective as a renter. There's a lot that can go into the pricing.

<comment><USER9> My roommate swears that checking the posting a few times can raise the price. Is the number of clicks/views on a posting taken into account when prices are changed daily?

<comment><USER6> No systems I've seen use that specific data point. Sadly for communities (and probably good for prospective renters), the third party sites you might find listings on (Craigslist, Apartments.com, ForRent.com, etc.) don't share that data that I've ever seen.

However, demand, which is usually a variable in the pricing equations, will definitely be generated by the lead tracking the community does, which can include: # of incoming phone calls, # of walk-ins, # of incoming emails.

tl;dr: Clicking on the ads won't do anything. Taking action and reaching out to the community can do something. And a lead is usually tracked on a unique user basis--so one person calling 50 times vs. 50 people calling once is vastly different.

</comment></comment></comment></comment></comment><comment><USER10> Insightful read. Your mention of text mining in "Future Look" reminds me of Levitt's findings regarding sales correlations with keywords in real estate listings.

[http://www.nber.org/papers/w11053.pdf](http://www.nber.org/papers/w11053.pdf)

[http://freakonomics.com/books/freakonomics/chapter- excerpts/...](http://freakonomics.com/books/freakonomics/chapter- excerpts/chapter-2/)</comment>


The Wirecutter: the best technology to buy based on research and testing - <AUTHOR> http://thewirecutter.com

<comment><USER2> Love this site. It's a must-read.</comment>


The Panic Over Fukushima - <AUTHOR> http://online.wsj.com/article/SB10000872396390444772404577589270444059332.html?mod=WSJ_hps_LEFTTopStories <comment><USER2> The opposition into Japan is not about the exact number of cancers or deaths. It is about trust. To quote the official report [1]:

...the subsequent accident at the Fukushima Daiichi Nuclear Power Plant cannot be regarded as a natural disaster. It was a profoundly manmade disaster – that could and should have been foreseen and prevented. And its effects could have been mitigated by a more effective human response.

How could such an accident occur in Japan, a nation that takes such great pride in its global reputation for excellence in engineering and technology? This Commission believes the Japanese people – and the global community – deserve a full, honest and transparent answer to this question.

Our report catalogues a multitude of errors and willful negligence that left the Fukushima plant unprepared for the events of March 11. And it examines serious deficiencies in the response to the accident by TEPCO, regulators and the government.

For all the extensive detail it provides, what this report cannot fully convey – especially to a global audience – is the mindset that supported the negligence behind this disaster. What must be admitted – very painfully – is that this was a disaster "Made in Japan."

Its fundamental causes are to be found in the ingrained conventions of Japanese culture: our reflexive obedience; our reluctance to question authority; our devotion to 'sticking with the program'; our groupism; and our insularity.

(the rest is worth reading too)

If your government and industry had failed you like that would you trust them to continue with nuclear power without fixing the underlying problems?

[1] <http://www.nirs.org/fukushima/naiic_report.pdf>

<comment><USER3> > If your government and industry had failed you like that would you trust > them to continue with nuclear power without fixing the underlying problems?

And yet, the hottest spots seem to be healthier places to live than Denver... Is that a really big problem?

<comment><USER4> Sure, but who in his right mind would live in Denver?

</comment></comment></comment><comment><USER5> The author of the submitted article, Richard Muller, is the developer of a Physics for Future Presidents course at UC Berkeley, author of a book with the same title as the course, and author of a new book Physics and Technology for Future Presidents: An Introduction to the Essential Physics Every World Leader Needs to Know

<http://press.princeton.edu/titles/9226.html>

that is well worth a read. In other words, Muller has been thinking about how to apply the facts of nature to the contentious issues of public policy for a long time, and has a good sense of economic and political trade-offs in policy- making. The article submitted here is a great example of clear thinking on a scary issue, and I endorse it as well worth reading and thinking about.

P.S. I have just been to Colorado Springs, Colorado, transiting the Denver, Colorado airport to get there, and I am not worried about increasing my cancer risk by returning to the Front Range each year for the business that brought me there.

<http://www.epsiloncamp.org/>

I checked some of the statements made in other comments in this thread since posting this, and I can't find any confirmation that the country-wide shutdown of nuclear plants in Japan has been anything other than bad for the country. While Japan continues to need electricity (for life-saving medical technologies, among other uses), and until other sources of electricity become less expensive, it makes sense for Japan to be open to restarting the other nuclear plants in the country.

P.P.S. I live in one of the states of the United States in which an exceptionally large percentage of electricity is generated at nuclear power plants. Both plants are located along the Mississippi River, as is most of Minnesota's population centers. Electricity is unusually inexpensive here, and health statistics are unusually good here, compared to other parts of the United States.

<comment><USER6> "I can't find any confirmation that the country-wide shutdown of nuclear plants in Japan has been anything other than bad for the country. While Japan continues to need electricity (for life-saving medical technologies, among other uses), and until other sources of electricity become less expensive, it makes sense for Japan to be open to restarting the other nuclear plants in the country."

OK, I don't know if anyone else finds this to be a strange statement, but I do.

First, no one is saying that shutting down 50 of 52 nuclear power power plants, providing 30% of Japan's electricity supply is an economic benefit. Would that even make sense?

But "bad for the country" is a very different proposition.

"Japan has shut down over 95% of the power plants which produce radioactive waste which lasts for thousands of years."

Bad for the country?

While Japan continues to need electricity (for SHORT TERM CONVENIENCE) , and until other sources of electricity become less expensive, it makes sense for Japan to be open to restarting the PRODUCTION OF ENERGY WHICH RESULTS IN RADIOACTIVE WASTE THAT IS LETHAL FOR THOUSANDS OF YEARS).

Yeah. Right.

What IS good for the country? Short term consumption, or long-term sickness, death and mutation? What would Hoppe say, in terms of a time preference analysis?

<comment><USER7> The concept of a half-life explains why LETHAL FOR THOUSANDS OF YEARS is a bit of an overselling of the situation.

The more radioactive a substance is, the shorter its half life. That is, the sooner it will become less radioactive. And vice versa: if a substance has a long half life, it will simply emit less energy per unit of time.

It's just inverse formulae. Nothing magical.

But people imagine high-powered radioactivity lasting for THOUSANDS OF YEARS. It just doesn't happen like that.

<comment><USER6> Jacques, I feel reluctant to disagree with you, because to search out the supporting references is a bit of a chore, but I had a good education in physics, I was a very good student, and I am confident that _lethal for thousands of years_ is not overselling of the situation. If anything, thousands of years is _underselling_ , as hundreds of thousands would be more accurate.

<comment><USER8> Let me help you with that. Jacques is correct in his description of activity. I just checked my radiation detection text book to make sure (that would be embarrassing wouldn't it!)

However, "lethal" is a bit of an ambiguous term when applied to the waste from the nuclear power generation. After cooling down, the fuel assemblies will most certainly be emitting ionizing radiation that will be detectable for hundreds of thousands of years, as you suggest. This does NOT mean it is "lethal" for this time period. UNLESS you open one of the assemblies and make an industrial waste smoothie. Most of the long lived isotopes contained in the assembly will be deadly as heavy metals. So there is still danger, but it is easily manageable, just like the waste from many other industrial processes (like making solar panels, or batteries for hybrids for instance).

</comment></comment></comment></comment></comment><comment><USER9> "It is remarkable that so much attention has been given to the radioactive release from Fukushima, considering that the direct death and destruction from the tsunami was enormously greater. Perhaps the reason for the focus on the reactor meltdown is that it is a solvable problem; in contrast, there is no plausible way to protect Japan from 50-foot tsunamis."

It's amazing to be able to take such an arrogant attitude. The outrage regarding the Fukushima disaster is exactly that there would have been _no_ fallout if not for several human errors leading up to the disaster -- and the lies and misinformation following the disaster. There is a complete and justified lack of trust in the government and the industry -- and no indication that there will be no further accidents -- whether induced by natural disasters or just poor maintenance.

So yes, over engineering does indeed work -- and is a necessary measure when dealing with potential radioactive fallout -- but even then accidents do happen. I've seen people claim that the fact that human error is behind this and other accidents "proves" that nuclear power is safe -- this is of course rubbish. Human error will always be a big risk factor in any engineering project.

The author also ignores the fact that Japan has done an unprecedented job of mitigating the damage tsunamis can do -- but that the effort had been scaled towards what was assumed to be the likely threat -- a tsunami smaller than the one associated with this earthquake. He implies that this effort was for nothing -- which isn't true. It simply wasn't effective along large parts of the coast as it should (could) have been.

Consciously allowing a potentially huge risk -- the long time destruction of farmland and populated areas by radioactive contamination -- versus not mitigating all possible natural disasters and risks of war -- is a false dichotomy.

The problem with nuclear power isn't that a lot of people might die from cancer -- it's that _generations_ might be affected by a single accident -- and will be burdened with containing spent fuel for longer than human civilization have existed.

Finally, if it turns out that geothermal power is a viable alternative -- then it should be possible to fulfil Japan's energy need without any risk of nuclear fallout.

<comment><USER10> In addition, we as mankind know how to deal with the aftermath of a tsunami: We clean up, rebuild and so on …

After a nuclear disaster, we mostly remain helpless observers. As of today, the Japanese neither fully know what actually happened and still have no idea how to deal with the Fukushima aftermath in a long-term. The same goes for Tschernobyl and many other sites with nuclear fallout and waste. Nuclear energy is like a dragon awoken without any possibility to put him at sleep ever again.

</comment></comment><comment><USER11> > Looking back more than a year after the event, it is clear that the > Fukushima reactor complex, though nowhere close to state-of-the-art, was > adequately designed to contain radiation. New reactors can be made even > safer, of course, but the bottom line is that Fukushima passed the test.

He made a good argument that new cancer cases are statistically few, but I can't see what test Fukushima passed. As far as I know there were multiple meltdowns and dumping radioactive water into the ocean. From an engineering point of view, it was a clear-cut failure. If not of implementation, then at least of specifications and margins.

<comment><USER12> They were not designed to be able to resist an earthquake of that magnitude so I fail to see how it can be an failure from an engineering perspective (the fact that most plants handled it fine should if anything suggest that, from an engineering perspective, it was a success).

<comment><USER13> Could you forward your comment to the author of Dilbert, please?

</comment></comment></comment><comment><USER14> As an experiment, I volunteer to expose myself, my wife and my children to a yearly dose of radiation that is three times the maximum safe-level recommended by The International Commission on Radiological Protection. i.e. we happily live in the Denver area ;-)

<comment><USER15> Really? Are you serious?

BTW, there's a big difference between "background radiation" and ingested radiation (either through air, food, water, etc.)

The scientific consensus is that there is _no amount_ of radiation that is safe to ingest.

<http://www.rrjournal.org/doi/pdf/10.1667/RR2629.1>

Do you _really_ want to test your theory?

<comment><USER16> I'd happily ingest as much plutonium as you would caffeine.

<comment><USER17> Are you sure?<http://en.wikipedia.org/wiki/Plutonium#Flammability>, to me, indicates that it may not be a wise idea to drop the stuff in the acid inside your stomach, even if it is only, say, a gram a day.

<comment><USER16> I'm sorry. I didn't mean to imply daily. As professor Bernard Cohen meant it, as a competition with Ralph Nader, I was a one off meant to show that the equivalent mg dosage of caffeine would kill you much faster then plutonium. A daily ingestion is much different.

</comment></comment></comment></comment></comment><comment><USER18> Lately I've been reevaluating my predictable sci/techy pro-nuclear stance. I still roll my eyes at folks who don't really know what radiation is but think it's inherently bad, and I still think nuclear power is probably a lesser evil than fossil fuels. But two things I learned this week gave me pause:

First, that Fukushima was not as benign as I believed if butterflys are mutating [http://www.nature.com/srep/2012/120809/srep00570/full/srep00...](http://www.nature.com/srep/2012/120809/srep00570/full/srep00570.html)

Second, and maybe everyone else knew this, but I never knew that we haven't been able to produce low-background steel since 1945 <http://en.wikipedia.org/wiki/Low-background_steel>

And maybe those are both insignificant. But I think they both serve as non- partisan evidence that we can and have semi-permanently altered the planet with each nuclear mistake we've made.

<comment><USER19> The low-background steel seems to be a factor of nuclear weapon testing rather than nuclear reactors. Even the most ardent of nuclear power supporters don't argue for detonating more nuclear weapons!

Besides, essentially everything people do at any scale has altered the planet in permanent or semi-permanent ways. It _is_ an issue, but it is not an issue unique to nuclear power.

<comment><USER20> I am convinced that the nuclear power industry remains not only inextricably linked to nuclear WMD programs, but its expansion is in fact driven by the desire for the materials, technology and capability to develop nuclear weapons

<comment><USER4> Perhaps in places like Iran and Pakistan. For the last few years we've been using old Russian warheads as fuel here in the US, which is the opposite situation.

<comment><USER20> sure, in the us(a) it may be an intrinsic (historical) link, but where nuclear power is expanding, I see weapons as a driver.

<comment><USER4> Yeah, I think you're probably right about that. But there are already some 400 nuclear power plants around the world. As much as I'd rather the Iranians not have one, it's pretty difficult to say "Sure, we have 104 nuclear reactors in the US, but _you_ guys aren't allowed to have any."

</comment></comment></comment></comment></comment></comment><comment><USER21> Physicist Richard Muller should clearly demonstrate his beliefs by moving to Fukushima, instead of discussing the panic from the other side of the world. And he should also put nuclear risks in perspective, and contradict Seaborg:

[http://www.bbc.co.uk/blogs/adamcurtis/2011/03/a_is_for_atom....](http://www.bbc.co.uk/blogs/adamcurtis/2011/03/a_is_for_atom.html)

<comment><USER22> He should leave his tenured position at a major university to demonstrate his conviction? That's not a meaningful point or challenge.

<comment><USER21> we have the same point: why should he take a morally superior position and not mislead the public? this is what the documentary is about.

<comment><USER22> I'm not sure what you mean. My point was that challenging him to move to Fukushima doesn't show his hypocrisy or anything. He has very good reasons not to move to Fukushima that have nothing to do with the threat of radiation.

</comment></comment></comment></comment><comment><USER23> Handy radiation dose effect chart provided by Randall of XKCD (note: 1 microsievert = 0.0001 rem)

<http://blog.xkcd.com/2011/03/19/radiation-chart/>

Perhaps an interesting meta-discussion is the phenomenon of how choice of units affects the framing of a discussion. 0.1 rem doesn't sound nearly as dangerous as 1,000 μSv, though of course both numbers are completely meaningless to most lay people.

<comment><USER24> TEPCO measured radiation levels of 10 Sv in the basement of Reactor 1 in June this year [1].

In March TEPCO measured radiation levels of 73 Sv/h in the container vessel [2]. A Fukushima worker tweeted a radiation level estimation of > 1000 Sv for another part of the reactor (the endoscope used for radiation testing is only rated to 1000 Sv, so cannot be used) [3].

The radiation level next to Chernobyl immediately after the meltdown was 300 Sv/h.

Also in March, Arnie Gundersen of FaireWinds went to Tokyo to collect soil samples from parks and streets, and on testing the samples back in the US concluded they would be considered radioactive waste in the United States. [4]

The XKCD cartoon was produced during the perceived hysteria following the aftermath and reporting of the Fukushima radiation and fallout, but the history since then appears to indicate that the extreme concern over Fukushima radiation is depressingly justified.

[1] <http://www.japantimes.co.jp/text/nn20120629a7.html>

[2] [http://fukushima-diary.com/2012/03/73svh-in-container- vessel...](http://fukushima-diary.com/2012/03/73svh-in-container-vessel/)

[3] <https://twitter.com/Happy11311/status/184586152186097664>

[4] [http://fairewinds.org/content/tokyo-soil-samples-would-be- co...](http://fairewinds.org/content/tokyo-soil-samples-would-be-considered- nuclear-waste-us)

<comment><USER4> >...but the history since then appears to indicate that the extreme concern over Fukushima radiation is depressingly justified.

If you're living in the reactor containment vessel.

<comment><USER24> That's a stunningly ignorant risk assessment.

Unit 4 has significant structural damage, and contains the most (and most recently used) fuel rods, stored outside the containment wall. Another 7.5 earthquake could cause a collapse triggering a fuel rod fire that could not be put out. TEPCO's plan states that they cannot begin removing fuel rods until 2013, or possibly 2014. [1]. "There is as much cesium in the fuel pool at Unit 4 as there was in all of the atomic bombs dropped in all of the tests in the 1940's, the 1950's, the 1960's, and into the 1970's."

All that is required for a catastrophic release of radiation across the northern hemisphere is a significant seismic event.

Fukushima is now classed alongside Chernobyl as a category 7 reactor event, the area surrounding Fukushima will take decades to clean up, and the Japanese Government has admitted major human error within regulatory bodies, and within TEPCO and credulous government acceptance of the Nuclear industry's unfounded safety claims. [2]

And Muller claims that "Fukushima passed the test". You can't make this stuff up. But you can call it what it is, historical revisionism by an ardent supporter of the nuclear industry.

Considering the still perilous situation, it is a breathtakingly irresponsible and insensitive article to write. Truly astonishing.

[1] [http://www.fairewinds.com/content/fukushima-daiichi-truth- an...](http://www.fairewinds.com/content/fukushima-daiichi-truth-and-future)

[2] [http://en.wikipedia.org/wiki/Fukushima_Daiichi_nuclear_disas...](http://en.wikipedia.org/wiki/Fukushima_Daiichi_nuclear_disaster)

<comment><USER4> >That's a stunningly ignorant risk assessment.

Or maybe it's just a rational one. None of what you've brought up contradicts my point. The problem isn't ignorance on my part, but rather hysteria on yours. Really, if this is the way you approach life I'm surprised you have the courage to get out of bed in the morning.

>Unit 4 has significant structural damage, and contains the most (and most recently used) fuel rods, stored outside the containment wall. Another 7.5 earthquake could cause a collapse triggering a fuel rod fire that could not be put out.

Or it could do nothing at all. You do realize they spent the first part of this year pouring concrete and putting in steel rods to stabilize that building, right? Did you think they've been drinking sake and shooting the breeze all this time?

>"There is as much cesium in the fuel pool at Unit 4 as there was in all of the atomic bombs dropped in all of the tests in the 1940's, the 1950's, the 1960's, and into the 1970's."

Yes, the reactors and pools are contaminated. And it will take a few years to get all that ugly stuff into completely safe storage. And? As long as the fuel doesn't go anywhere it doesn't matter how long it takes to clean up.

>Fukushima is now classed alongside Chernobyl as a category 7 reactor event, the area surrounding Fukushima will take decades to clean up

I find it amazing people can say (presumably) with a straight face that because shares some subset of characteristics with Chernobyl that it's _OMG JUST AS BAD AS CHERNOBYL!!!!_ It's not as bad as Chernobyl by orders of magnitude. It never was.

As far as the exclusion zone goes, it's only 20 km. Even for a country as land-poor as Japan that's not much.

<comment><USER24> I wouldn't be so generous as to call your initial comment a point. More like an antagonistic expression of wilful ignorance.

That you would assert that the only people who need to be concerned with radiation are people 'living in a containment vessel' is simply absurd.

All you're doing now is applying the industry's standard response to rational concerns over a disastrous reactor incident: paint public concern as ignorant 'hysteria', engage in a bit of character assassination ("I'm surprised you have the courage to get out of bed in the morning"), and gloss over the seriousness of the situation, and impacts ("it's only 20 km").

Your stance also clearly indicates you've read little on the impact on the ground in Fukushima over the last year. I don't think there's much to be gained from discussing this issue with you, as at any point you'll be arguing with a concocted mental model of an opponent who is 'hysterical' and 'ignorant', and bring only arrogance and snark to the table. Boring.

</comment></comment></comment></comment></comment></comment><comment><USER25> I don't know of any authoritative resources on radiation->cancer risk, can anyone provide more information? The article starts out with a cool premise but I have a hard time swallowing the linear rem->%chance relationship described here

"If 25 rem gives you a 1% chance of getting cancer, then a dose of 2,500 rem (25 rem times 100) implies that you will get cancer (a 100% chance)"

<comment><USER26> Unfortunately, we don't have the data. Yep, it's non linear, but all of our data is basically on two ends of the spectrum. Low amounts of radiation on one end, accumulated from natural sources or working at nuclear plants, and high amounts of radiation on the other, accumulated from survivors of Hiroshima, Cherynobyl, and some nuclear accidents.

So, given those data points, with clusters on two ends of this spectrum you're stuck with interpolation. Ideally, we'd like a good, predictive, biological based model that explicitly showed how you go from biological damage to cancer or death. We don't have that (though there are people researching it), so we go with statistical techniques. This results in basically 3 different proposed models.

<http://en.wikipedia.org/wiki/Linear_no-threshold_model>

The Linear No Threshold Model:

Draw a line between the two regions. Bam! Done.

This is clearly wrong for very large doses, but is used mostly to try and estimate the effect of a small change in radiation exposure to predict increase in cancer incidence. This is very important for public policy. Of course, this makes all these models politically contested.

<http://en.wikipedia.org/wiki/Threshold_model>

Threshold Model

This model predicts that small amounts of radiation has zero effect on cancer incidence. According to this model, going to higher altitude, or taking a plane flight, won't increase your risk of cancer.

<http://en.wikipedia.org/wiki/Radiation_hormesis>

Radiation Hormesis

A little radiation is good for you! The biological argument is that your body gets used to dealing with damage from radiation. Don't tax it too hard and you'll be stronger. So take a plane trip, and enjoy the X-ray scans!

<comment><USER15> _A little radiation is good for you!_

The science says otherwise.

<http://www.rrjournal.org/doi/pdf/10.1667/RR2629.1>

[http://www.washingtonsblog.com/2011/04/low-level-doses-of- ra...](http://www.washingtonsblog.com/2011/04/low-level-doses-of-radiation- can-cause-big-problems.html)

<comment><USER8> Hate to keep taking issue with your comments, but they are pattently wrong. Using a study of atomic bomb studies and an anti-nuke web site do not constitute science.

Studies Ive read, completely contradict your statements ([http://ehp03.niehs.nih.gov/article/fetchArticle.action?artic...](http://ehp03.niehs.nih.gov/article/fetchArticle.action?articleURI=info%3Adoi%2F10.1289%2Fehp.1104294)) for one. There are others, and I am sure that I will not be convincing you, but I didn't want your voice to be the only one on the issue here.

</comment></comment></comment></comment><comment><USER27> To the author of this article: I will believe you if you agree to move to Fukushima and live there for the rest of your life.

<comment><USER14> As for me, I live in Denver with my family which according to the exposure map, is about the same as living within 25 miles of Fukushima

<comment><USER28> You don't have radioactive iodine floating around. Radon doesn't asbord into your thyroid glands.

</comment></comment></comment><comment><USER29> Maybe I was being ridiculously optimistic, but ~200 projected additional cases of cancer seems pretty bad.

<comment><USER11> You really have to put things in context, otherwise you get into the "think of the children" fallacy, where everything is worth the effort if it saves one life.

We die of three causes: cancer, heart problems and strokes. Well over 30% die of cancer. So this means some of those 200 will die of cancer before they die of something else (some of them will recover and live to die from heart attack later). This makes the new deaths a really tiny percentage, which means policy-wise it's hardly worth discussing.

<comment><USER29> I'm certainly not trying to imply any policy prescriptions. I'm strongly in favor of nuclear power. But if there's risk we should know what it is so it can be distributed/compensated for.

I'm not saying it's not worth the cost (or even trying to discuss things in those terms), but I'm not convinced this outcome is insignificant. If this article is right, many of these people will die N years sooner than they would have otherwise. How high does N have to be before it gets worth discussing?

<comment><USER21> The risk for the GE MkI was (is) well known, but physicist-socipath Seaborg chose to hand out the operating license:

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

</comment></comment></comment></comment><comment><USER30> With 2 reactors online and several thermal plants taken offline Japan is more than meeting it's current demand even though an exceptionally hot summer.

(Yes, I've been keeping an eye on the demand & availability numbers. Not just making stuff up in advance like others here.)

In fact if you took the 2 reactors offline they would still meet demand.

Now as the renewable energy industry actually gets a chance, rather than being squashed by the nuclear industry stranglehold on government the reactors are becoming clearly unnecessary long term.

Statements like many of the blog posts here are frankly ridiculous propaganda.

</comment><comment><USER31> Infertility and High Natural Background Radiation ...

 _"Conclusion: Findings of this study indicate that women's Primary infertility rate in the HBR residents was considerably less than in the area with ordinary background radiation."_

[http://docsdrive.com/pdfs/medwelljournals/rjbsci/2008/534-53...](http://docsdrive.com/pdfs/medwelljournals/rjbsci/2008/534-536.pdf)

"Y. Tabarraie , S. Refahi , M.H. Dehghan and M. Mashoufi , 2008. Impact of High Natural Background Radiation on Woman`s Primary Infertility. Research Journal of Biological Sciences, 3: 534-536."

</comment><comment><USER32> Random question: Could the altitude of Denver contribute to its lower incidence rate of cancer? Your body does have to work a bit harder to live higher up. Just curious.

</comment><comment><USER6> The conclusion of the WSJ was: "The great tragedy of the Fukushima accident is that Japan shut down all its nuclear reactors. Even though officials have now turned two back on, the hardships and economic disruptions induced by this policy will be enormous and will dwarf any danger from the reactors themselves."

The conclusion of The Corbett Report was: "Along with the tragic loss of life, the destruction of homes, farms, businesses and property, and the beginning of the Fukushima nuclear crisis, the 2011 Tohoku earthquake and tsunami exposed the biggest secret of all: that the myth of the necessity of nuclear power in Japan is just that. A myth."

[http://www.corbettreport.com/mp3/episode237_fukushimas_bigge...](http://www.corbettreport.com/mp3/episode237_fukushimas_biggest_secret.mp3)

<comment><USER33> I question that conclusion. The power shortages have been quite troubling.

[http://news.nationalgeographic.com/news/energy/2012/03/12030...](http://news.nationalgeographic.com/news/energy/2012/03/120309-japan- fukushima-anniversary-energy-shortage/)

[http://ajw.asahi.com/article/0311disaster/fukushima/AJ201207...](http://ajw.asahi.com/article/0311disaster/fukushima/AJ201207030064)

<http://www.bbc.co.uk/news/world-asia-18468685>

<comment><USER6> I read your links. I know the audio is almost an hour, so I don't expect you to have listened before you posted.

According to Mr. Corbett, who lives in Japan, the predicted shortages did not in fact materialize this summer, and in fact, a SURPLUS of power was reported. He doesn't assert that without the 50 plants currently offline there will be no power shortfall. Most of the report is about alternatives such as solar, geothermal, thorium, and wave power.

The point is that Japan has gone over a year now with almost NO nuclear power, and the sky has not fallen. There are alternatives. There are also large corporate/governmental interests who PREFER the present nuclear policy, and that policy is now opposed by a large number of the Japanese people.

Did you personally suffer any consequences? Are you perhaps suspicious of TEPCO, or the WSJ's motives?

<comment><USER33> Left out of that story are all the sacrifices people had to make to conserve power. That said, Thorium is a promising power source. Just don't tell anyone that it's nuclear power.</comment></comment></comment></comment>