Generating Feign Clients with Swagger Codegen and Gradle - <AUTHOR> https://blog.arnoldgalovics.com/2018/06/11/generating-feign-clients-with-swagger-codegen-and-gradle/ <comment><USER2> So the solution to:

      error: package org.springframework.cloud.security.oauth2.client.feign does not exist

is to manually add the lines:

        task deleteNonClientRelatedClasses(dependsOn: 'generateClient') {
            doLast {
                delete "${project.buildDir}/src/main/java/io"
            }
        }

to the Gradle build script? Sounds like Swagger is inserting itself into the complexity spiral dominated by Spring, Gradle, and Apache Groovy.

PS: This was already submitted to HN 12 hrs ago by the same user: [https://news.ycombinator.com/item?id=17332028](https://news.ycombinator.com/item?id=17332028)</comment>


Statistician Proves Gaussian Correlation Inequality - <AUTHOR> https://www.quantamagazine.org/20170328-statistician-proves-gaussian-correlation-inequality/ <comment><USER2> > Not knowing LaTeX, the word processer of choice in mathematics, he typed up > his calculations in Microsoft Word

...

> He opted instead for quick publication in the Far East Journal of > Theoretical Statistics, a periodical based in Allahabad, India, that was > largely unknown to experts and which, on its website, rather suspiciously > listed Royen as an editor.

I couldn't help but laugh at this part. He proved a classic theorem in statistics and then precision engineered the actual submission to be roundly ignored.

Makes me wonder if there's a proof of P=NP with ClipArt illustrations that's buried in the South Asian Journal of Mathematics.

<comment><USER3> > I couldn't help but laugh at this part. He proved a classic theorem in > statistics and then precision engineered the actual submission to be roundly > ignored.

He simply did not care:

"I am used to being frequently ignored by scientists from [top-tier] German universities," he wrote in an email. "I am not so talented for 'networking' and many contacts. I do not need these things for the quality of my life."

<comment><USER4> Sounds like a bullshit excuse. I don't understand why anyone would even argue that they intentionally do a poor job presenting their work because they somehow allege they are ignored.

The only reason why anyone would go through such pains to get ignored is if they intentionally want to be ignored.

And this does not make any sense, particularly in a "publish or perish" environment.

<comment><USER5> I on the contrary find it perfectly reasonable. Academic publishing has its own share of bullshit and I can well understand someone, specially a retired person, wanting to give up on that kind of prestige in order to save time and energy for actual science. For example, as far as I know, Grigori Perelman has not published the work that won him an offer of the Fields Medal in any journal.

</comment></comment></comment></comment><comment><USER6> A simple proof of the Gaussian correlation conjecture extended to multivariate gamma distributions by Thomas Royen: [https://arxiv.org/pdf/1408.1028.pdf](https://arxiv.org/pdf/1408.1028.pdf)

<comment><USER7> Mathematics has this funny habit of throwing around "it is easy to say that ...", or in this case, calling a proof that eluded mathematicians for decades "simple."

<comment><USER8> You just need to understand the language.

"Trivial" = "regularly covered in undergraduate courses"

"Easy" = "a good topic for an undergraduate honour's thesis"

"Non-trivial" = "a good PhD thesis topic"

"Distinctly non-trivial" = "a groundbreaking result which will establish a professor's reputation in the field"

<comment><USER9> I had a professor who liked to talk about how "elementary" did not mean easy, it just means "uses only the foundations."

This proof is a perfect example of that statement. Formulating the problem the right way -- which is most often the hardest part -- was the real challenge here, not the mechanisms needed to do the formulation or the proof.

<comment><USER10> Not sure why, but this reminds me how we had a professor that would say

      Let y(x) = a*x^4 + b*x^3 + c*x^2 + d*x + e,
      whereby e is not _necessarily_ the base of
      natural logarithm

<comment><USER8> My favourite along those lines was "let epsilon be a small number which is not necessarily greater than zero". Everybody who spent the preceding year on epsilon-delta proofs did a double-take at that.

</comment></comment></comment></comment></comment></comment><comment> d--b The proof is hard to read for non-statistician. Is anyone willing to give a short human-readable summary of how it works?

Also, the conjecture seems fairly simple, so it'd be great to understand what made it hard to prove.

<comment><USER11> Here is a blog post that I think clarifies why this conjecture had remained unsolved: [https://almostsure.wordpress.com/2009/09/27/the-gaussian- cor...](https://almostsure.wordpress.com/2009/09/27/the-gaussian-correlation- conjecture/)

There is also a 'companion' article on arxiv that provides a clear presentation of Royen's proof: [https://arxiv.org/abs/1512.08776](https://arxiv.org/abs/1512.08776)

</comment></comment><comment><USER12> terry tao has a great discussion of the entropy power inequality

[http://mathoverflow.net/questions/167951/entropy-proof-of- br...](http://mathoverflow.net/questions/167951/entropy-proof-of-brunn- minkowski-inequality)

</comment><comment><USER13> From reading the article, it seems that his proof is _straight from The Book_.

</comment><comment><USER14> > Imagine two convex polygons, such as a rectangle and a circle

Hrm....

<comment><USER15> You can think of a circle as an infinity-gon.

<comment><USER16> I like "infini-gon" :D

</comment></comment></comment><comment><USER17> I love stories like this one. Reminds me of the the twin prime story from a little while ago. Well written article as well!

<comment><USER18> As someone who has been funded by them, I think that I am nonetheless not being biased when I say that the Simons Foundation does a huge amount of good for the sciences, not least by funding this kind of consistently quality science journalism.

<comment><USER19> I'm not funded by them, and I generally think the Simons Foundation does great work.

</comment></comment></comment><comment><USER20> Here's another data point in one of HN's favorite topics, how academia and publishing are broken.

</comment><comment><USER21> > "It is like a kind of grace," he said. "We can work for a long time on a > problem and suddenly an angel — [which] stands here poetically for the > mysteries of our neurons — brings a good idea."

Had he learned LaTeX, I wonder if it would be a matter of justice.

</comment><comment><USER22> Could anyone explain why it is impossible for a Gaussian distribution to be anti-correlated with a group of N other Gaussians? This proof clearly implies that fact, but none of the discussion seems to remark on it. I can imagine a distribution such that the "random seed" puts things closer to the tails based on the measured variance of a group of other normal distributions. Intuitively it seems like that ought to be able to be a normal distribution itself; I don't follow why that is not true.

</comment><comment><USER23> I seriously can't believe that a problem that has evaded mathematicians for decades could turn out to have a 9 page elementary proof!

I don't know whether to be excited that, maybe, other hard problems in mathematics could have such elementary proofs, or depressed that mathematicians took so long to solve a problem with such a simple answer :)

<comment><USER20> Or it was ignored because it didn't have an author from Harvard or Princeton on it.

</comment></comment><comment><USER24> This conjecture seems to be easily seen as true by intuition. It's surprising that it took so long to find a proof.

<comment><USER25> Can you explain to me how this conjecture is intuitively true?

<comment><USER26> Let's say A has a 0.7 probability, and B has 0.6, and are independent. The compound probabilities are gotten by multiplying the individual ones:

Neither: 0.3 * 0.4 = .12 A, not B: 0.7 * 0.4 = 0.28 B, not A: 0.3 * 0.6 = 0.18 Both: 0.7 * 0.6 = 0.42

Now let's say that they're not independent; in fact, B absolutely requires A. You'd get something like:

Neither: 0.3 (this is reduced to the chance of not A) B, not A: 0 (B can't happen without A) Both: 0.6 (only other probability with B, has to make up the 0.6) A, not B: 0.1 (simply what's left to sum to 1.0)

Concrete examples of independent events: (fair) coin tosses -- the chance to come up heads is always the same, no matter the prior result. Related events: being dealt a face card in blackjack, and winning the hand -- whatever your normal chance of winning a hand, the odds of winning that particular hand just went up.

</comment></comment></comment><comment><USER27> Calling this a "famous long-standing mathematical conjecture" seems a bit of a stretch. It gives the impression that this would be comparable to Fermat's Last Theorem, the ABC conjecture, the Riemann hypothesis, etc. However, this conjecture doesn't seem to have a Wikipedia page. The discoverer, Thomas Royen, does not have a Wikipedia page either. The Loren Pitt paper establishing a special case of the conjecture was cited only 50 times.

The only justification for the importance of the problem that I see in the original article is that it was open since 1972 and someone is quoted as having worked 30 years on it and knowing other people who have worked long on it. That's something, of course, but it's not so much -- there are lots of problems in mathematics that remain unsolved after some decades despite serious efforts, and not all of them are famous ; it depends on how much attention they have attracted.

<comment><USER28> Citing the Wikipedia articles' existence is a curious argument to make when an article titled "40% of Wikipedia is under threat from deletionists" [1] was just on the front page.

[1]: [http://boingboing.net/2017/02/16/40-of-wikipedia-is-under- th...](http://boingboing.net/2017/02/16/40-of-wikipedia-is-under-thre.html)

<comment><USER29> Obviously obscure content will not survive unless it somehow gains fans willing to guard the page from these people, who pretend wikipedia is paper encyclopedia with limited budget for "notable" topics. They have to defend citations, perceived bias/neutrality and fight merge/deletion votes, gain allies with admins once it reaches arbitration and explain the article "notability" each time its questioned(and articles can lose "notability status" once one of these pedantic autists start questioning every line and word, deleting everything not following exact rules). In fact an isolated article, with new content or very few backlinks will not even be accepted and get speedily deleted before it gets worked into something acceptable to wikipedians. There has to be an alternative to this.

</comment></comment></comment><comment><USER30> The paper has only seven pages, but the actual proof is even shorter --- it spans from p.3 to p.5. So, it's a three-page proof. Really well done.</comment>


Is this the future of advertising? - <AUTHOR> wyzscan.com <comment><AUTHOR> I forgot it's April 1, ugh, it was very early when I received this email.</comment>


Ruby Still isn't dead - <AUTHOR> https://www.engineyard.com/blog/ruby-still-isnt-dead <comment><USER3> That said very little. It was just ruby 2.5 is going to be awesome, and we need people.

</comment><comment><USER4> I had to write Ruby (with no prior experience) as part of an interview exercise, about 10 years ago. Never encountered it or used it since. Not sure it has a purposeful niche or enough of a differentiation to grow in use.

<comment><USER5> This is one of dryest jokes I've ever seen on HN. Well done.

<comment><USER6> I am not aware of the joke here. Could someone please explain?

<comment><USER4> Obviously, not a joke. COBOL and Ruby have a lot in common, as far as I can tell.

<comment><USER5> It's definitely a joke, intentional or not. Hell, it's even funnier if it was unintentional.

</comment></comment></comment></comment></comment><comment><USER7> "Go, Visual Basic, Perl - all these are great, commonly used languages - <USER2> they dead or dying too? There's no reason to think so."

Go is fine but yeah those other two are, uh, well.

<comment><USER8> Perl isn't dead so much as it's primarily only used in production by older sys admins but it still has a community that loves it, VB.NET is alive and well in Microsoft shops and among noob malware authors.

My definition of fucking dead is smalltalk. But this is coming from a guy who's favorite pls are erlang, SML/NJ, and Ocaml lol.

<comment><USER9> > My definition of fucking dead is smalltalk

A curious definition. Not only Smalltalk is still used (e.g. in fintech), but it's intelectual virtues are always revisited and rediscovered by new generations who, invariably, try to come up with a "modern" version of it, or something inspired by it.

<comment><USER10> Like Ruby!

<comment><USER11> Like ruby? AFAIK nothing new ever came out of ruby. It was just a nice pure implementation of smalltalk on top of Perl. Of course the everything is a method strategy and unoptimized MOP burned them.

Just look at their new jit. Can anybody think of a worse strategy to implement a jit? There are serious technical and management problems. V Makarov at least wrote the register machine before the naive cc -> so jit, but then the Japanese came and even ripped that out.

</comment></comment></comment></comment></comment><comment><USER12> Why do we need a quarterly article to remind us about the obvious?</comment>


Thoughts on the new PayPal Developer Web Site - <AUTHOR> http://blog.jeffreymcmanus.com/3870/three-thoughts-on-the-new-paypal-developer-site/

<comment> yo-mf LOL, Hacker News roulette...

Nice article though and a change from the usual bashing of PayPal that generally masquerades as cogent discussion here. It is clear that PayPal is finally putting some effort behind the "Developer Community" rhetoric they have touted for a couple of years.</comment>


Ruby concurrency explainined simply - <AUTHOR> http://merbist.com/2011/02/22/concurrency-in-ruby-explained/ <comment><USER2> Here's mantra to repeat until you prove otherwise, "My application is not CPU bound it's IO bound". Even most applications that max the CPU are still IO bound because of their IO access patterns. Seriously, think about how your app is IO bound not CPU bound.

It's the cache thrashing / memory IO / disk IO constraints not the number of threads. People just increase the number of threads to increase the chance that there is data in the cache that the CPU can use.

Trim your data structures so they fit in a CPU cache line, make sure your data structures are properly aligned, make sure all the RAM slots on your server are in use. Put more RAM in your servers, throw out your spindle disk and replace them with SSDs, check your switches, can they actually handle a full 1Gbs burst? Or do they start dropping packets? Are you using all the network ports on your server? Are your switch interconnects 10Gbps? Is close-to-open cache coherence on NFS killing your cache hit rates? Are your indexes fragmented? Is your memory fragmented? Are your splitting your IO so that sequential IO goes to spindles and random IO goes to SSDs? Are your disk partitions aligned to your RAID block size. (Hint: If you're using RAID and your partition starts at sector 1 you're losing 15% of your IO performance) Do you have a cache in front of your app servers that will cache the response so the server thinks it's communicating with the client at a full 1Gbps? I'm not talking about something like varnish, just a simple store and forward cache.

The GIL is just a red herring so that people can point to something they have no control over and can give up hunting for performance.

It's not the GIL it's your IO subsystems. And turn your random IO into sequential IO, here's an example, lets say you have to store a whole bunch of 40K jpegs, instead of writing them as individual files put 1000 of them into an uncompressed ZIP file. Now your IO is sequential instead of random and you've taken a whole bunch of load off the kernel. If you're running on a 7200 RPM disk your throughput just went from 5-10MB/sec to ~100-200MB/sec

<comment><USER3> I use Ruby in a research lab for scientific computing, and in our case, most of our applications are definitely CPU bound. We end up re-writing many of them in C to speed them up and use threading but if we could keep them in Ruby while still using concurrency the faster development times would improve the lives of everyone in the lab. Ruby is not Rails. I for one would benefit immensely from being able to run threaded Ruby code.

<comment><USER4> You should not write CPU-bound scientific computing code in the language at the bottom of the Shootout: [http://shootout.alioth.debian.org/u64q/which- programming-lan...](http://shootout.alioth.debian.org/u64q/which-programming- languages-are-fastest.php)

The easiest move might be to NumPy, assuming it can express your computations in its methods because if you're reduced to doing math in Python you're hardly any better off.

If you're willing to pay the price for Ruby there are certainly other viable options that aren't C. Learning the minimum Haskell to do decently fast math wouldn't be that hard and would not involve to much of the "weird stuff", for instance.

<comment><USER3> Much of our code is not CPU bound, and the PI is something of a Ruby evangelist. If everyone jumps away from Ruby it will never improve. That being said, I don't think Ruby will ever be the fastest language, but speeding things up is always a good goal.

</comment></comment></comment></comment><comment><USER5> This is a great article, raising many valid points around concurrent programming. I can't speak to Ruby, but Python supports, and has never presumed linear programming.

Python has had POSIX threads since at least 1.5.1. The standard library contains a set tools for concurrent programming (see the threading module, queue, etc) and many included libraries are thread-safe.

The GIL's behavior is complex, but even so it's still possible to write performant, multi-threaded code in Python, especially for IO bound tasks. See David's excellent write up: <http://www.dabeaz.com/GIL/gilvis/index.html>.

Everybody wants the GIL to be removed, and several attempts have been made, but the collateral damage seems just too great at the moment - C extensions, and tons of libraries, frameworks, and programs would need to be re-written at the cost of greater complexity, for questionable performance gains in the average case.

Backwards compatibility is a core philosophy of Python, one which I think makes it a great programming environment. This makes removal of the GIL more a philosophical problem than a technical one. Python 3 has made some progress in removing GIL contention, but it's certainly here to stay for the foreseeable future.

Perhaps Python will be left behind in the future due to these decisions, but given all the work being done, I find it hard to believe any argument claiming that the Python community isn't actively invested in concurrent programming.

</comment><comment><USER6> I'm the author of cool.io and Revactor (the latter was mentioned in this article), and as much fun as it is to experiment with these ideas, the path of least surprise, especially for Rails applications, is to use threads. I wrote about that here:

[http://www.unlimitednovelty.com/2010/08/multithreaded- rails-...](http://www.unlimitednovelty.com/2010/08/multithreaded-rails-is- generally-better.html)

Have I gotten burned by Ruby libraries that aren't thread safe? Sure. I found a thread safety bug in my application just yesterday, and it was a pain in the ass to track down. However, once I tracked it down, it was extremely easy to fix.

With JRuby (and soon with Rubinius Hydra) you can deploy one VM and take advantage of all of the CPU cores in your server. Debugging a multithreaded application isn't an impossible task, and if you're a JRuby user you have access to a whole slew of JVM tools to assist you.

</comment><comment><USER7> Pushing a language, its libraries, and extensions which have traditionally presumed linear execution into a threaded/parallel world is a minefield. I'd like to offer a few thoughts on some factors which might have contributed to this complexity, to reframe the question of what might constitute the "best" concurrency strategy in terms of tradeoffs, and conclude with a call for us to take up the task of reasoning about our programs in a parallel context.

We've seen an explosion of interest in non-threaded, single-process approaches to concurrency in the Ruby and Python communities in the past couple years. Much of the difficulty here lies in frameworks, libraries, and development paradigms which were not designed to be threadsafe (or to teach threadsafe programming) from the start. Developers and library authors have for years been able to operate under the assumption that Ruby code in a single process is executed serially and not in parallel. In environments which permit parallel, concurrent execution inside the boundaries of a single process, authors must return to the foundations of what they've created and scrutinize every bit, reconceptualizing their programs in terms of shared state and mutation.

Individual developers relying on these libraries must also scrutinize each and every gem they require to ensure that the code is threadsafe as well. This is not an easy task, as reasoning about state is inherently difficult, especially when the original program may not have been designed with concurrency in mind, and even moreso when one was not the original author. Further, we haven't seen a significant chasm between things which "are" or "are not" threadsafe emerge in the Ruby community, and it is not common to certify one's code as "threadsafe" on release. That said, it's commendable that the Rails team has worked diligently to piece through each component of the framework and certify it clean.

I do not mean to suggest that multithreaded code written in Ruby is uncommon, unsafe, or a bad idea in general. Many applications running in environments without a GIL/GVL such as JRuby utilize this functionality effectively today. What I'm suggesting is that process-based concurrency (Mongrel/Passenger/Unicorn, et al) is often favored by developers because it eliminates a large swath of potential pitfalls (or rather, trades them for increased usage of system resources).

In light of this, we've seen developers in the Ruby and Python communities experimenting with and popularizing alternate concurrency models, not the least of which include cooperatively-scheduled fibers/co-routines and evented programming. These approaches avoid a specific subset of the challenges in concurrent multithreaded execution, while enabling limited concurrency in one process. Matt is quick to point out that these models don't achieve true concurrent parallelism, but do offer significant benefit over standard serial execution. At the same time, they impose a different sort of complexity upon the programmer -- either requiring her to reason about a request or operation in terms of events and callbacks, or to use a library to cooperatively schedule multiple IO-bound tasks within a single VM (which may hide some complexity, but introduce uncertainty by clouding what is actually happening behind the scenes).

I wish Ruby and Python the best here. I have a significant investment in both. But as long as developers must ask of libraries "Is it threadsafe?" with fear and negative presumption, traditional multithreaded concurrency might not be ideal given the investment required to achieve it safely and correctly.

More than anything, I hope for continued complex reasoning and thought on this question. We simply must move beyond reductionist statements such as "threads are hard!" to progress. I'd suggest that threaded programming in and of itself is not hard per se -- reasoning about shared state is, and the developer bears a responsibility to either eliminate, or minimize and encapsulate it properly in her code. Evented and coroutine-oriented programming brings its own challenges. Actor models are interesting and may be appropriate for some contexts. STM's pretty cool too, but it would not be proper to hang one's hopes upon something which is not likely to cure all ills.

There is no panacea for concurrency. There will always be challenges and tradeoffs involved in developing performant, efficient applications within the constraints of both hardware and programmer resources. We would do well to push ourselves toward a greater understanding of the challenges in developing such programs, as well as the tradeoffs involved with each approach. I think this article is a step in the right direction.

<comment><USER8> @cscotta as the author of the blog post, I can only agree with the concerns you raised and thank you for your kind words.

Concurrency is something both Ruby and Python have to take seriously pretty quickly if both communities want to mature and play a more important role in the coming years. As you pointed out, there are different ways to get some sort of concurrency and they all present challenges and tradeoffs while none will cure all ills. But at the end of the day what matters is a community of people embracing these approaches and pushing the language further.

By removing the Global Interpreter Lock most of the alternative Ruby implementations are making a statement and the community seems to react. If we educate the community, commonly used code will become threadsafe over time and developers will learn what it means to write threadsafe code. If made easy, co-routines and non-blocking IO will be used. If implemented well and properly explained, actors will be used more often when it makes sense to do so.

My goal was to try to simplify the concurrency problem so the community as a whole can discuss the topic. I think that the concurrency challenge can be improved by increasing the awareness, getting people motivated and having an open discussion. There is a reason why Ruby and Python still have a GIL and why removing it to improve concurrency would have its downside. I want to make sure people understand that before blaming Matz for not removing the GIL already. The Ruby implementation fragmentation also hurts progress done in MRI, if you look at it, alternative implementations often have more people working on them than people working on MRI!

Let's hope that this article is indeed a step in the right direction.

<comment><USER7> Absolutely - thanks, Matt. This is a very well-written, thorough article, and it provides a clear, thoughtful survey of the landscape for folks who are interested in parallelizing their programs and learning more about the advantages and tradeoffs implicit in different approaches. This piece has a lot of potential to catalyze thought within the community about how best to move forward.

The explosion of interest in the subject intrigues me. The work that's been going on in terms of making mainstream Ruby libraries threadsafe is great to see, along with fibers and evented approaches. MacRuby's exposure of Grand Central is especially unique. But interest and upvotes must also be followed by action. There will be a lot of false starts. We'll probably see a handful of approaches which bloom and fade from popularity. While the "fragmentation" issue is there, I tend to think of it in terms of spirited experimentation. In any case, people really care now, and it's that drive that forces a community forward. That's good to see.

Keep it up!

</comment></comment></comment><comment><USER9> No need for threads in JRuby. Just use actors and messages (and you can transform any object into an actor). I've wrote it about it here: [http://metaphysicaldeveloper.wordpress.com/2010/12/16/high-l...](http://metaphysicaldeveloper.wordpress.com/2010/12/16/high- level-concurrency-with-jruby-and-akka-actors/)

</comment><comment><USER10> As much as this was informative... "However these people often don't mention that the GIL makes single threaded programs faster" <\- how did they ever get that idea?

<comment><USER11> Because there is no need for locking in the fundamental data-types like hashes.

<comment><USER10> Why would you lock anything in a sigle-threaded code in the first place?

<comment><USER12> I don't know about Ruby, but in Python, the GIL is there to protect the _interpreter_ from complicated locking and memory management overhead that thread-safety would require of it: [http://mail.python.org/pipermail/python-3000/2007-May/007414...](http://mail.python.org/pipermail/python-3000/2007-May/007414.html)

@jessenoller has a great summary of concurrency in Python: [http://jessenoller.com/2009/02/01/python-threads-and-the- glo...](http://jessenoller.com/2009/02/01/python-threads-and-the-global- interpreter-lock/)

The two worlds seem very similar.

<comment><USER10> Sure, I understand the idea of GIL being faster than fine-grained locking for single-threaded apps. This is not how I read the article though (maybe that's what they meant...).

The speed can be sorted as (in most cases): single-threaded code, single- threaded with GIL, single-threaded with fine locks.</comment></comment></comment></comment></comment>


Ask HN: Programming/startup related podcasts worth listening - <AUTHOR>

So... help me! :D <comment><USER2> Jason Calacanis' "This Week in Start Ups" is always entertaining an insightful</comment>


Google's Waymo risks repeating Silicon Valley's most famous blunder - <AUTHOR> https://arstechnica.com/cars/2019/02/googles-waymo-risks-repeating-silicon-valleys-most-famous-blunder/ <comment><USER2> Xerox couldn't make a success out of the Alto because it was run by "tonerheads," as Steve Jobs called them, copier guys who didn't see how a PC would help their copier business which was already at the top of the game.

Could it be that Alphabet is run by advertising guys and so it can't successfully develop a self-driving car? I think that's one factor. Now I think about it, is there _any_ Alphabet/Google business that's successful that's not advertising-based?

Another factor is that self-driving cars are harder (and further off) than the industry pretends they are. Tesla is ahead of the pack and they still have significant problems. The latest Model 3 shipments in Europe had autopilot disabled.</comment>


MINE: Maximal Information-based Nonparametric Exploration - <AUTHOR> http://www.exploredata.net/Technical-information

<comment><USER2> Does anyone have access to technical details about this process? It would be nice to avoid paying for the info via: <http://www.sciencemag.org/content/334/6062/1518.abstract></comment>


JavaScript, We've Got to Talk - <AUTHOR> https://georgestocker.com/2016/09/27/javascript-weve-got-to-talk/ <comment><USER2> To be fair this is a criticism of Javascript package and library tooling rather than Javascript itself.</comment>


The Simple Answer to the Interview Question: What Is Your Greatest Weakness? - <AUTHOR> http://oberheim.se/interviews/2016/12/07/what-is-your-greatest-weakness.html <comment><USER2> "What is your greatest weakness?"

"Honesty"

"Uh... I don't think honesty is a weakness."

"I don't give a fuck what you think."

</comment><comment><USER3> I tell the interviewer that I will not answer that question since everyone has their pet answer which is just some kind-of strength masquerading as a weakness. No one actually tells the interviewer their 'greatest' weakness so the question is bogus, and in my opinion, the sign of a weak interviewer.

<comment><USER4> So your greatest weakness is the lack of diplomatic answers to bogus interview questions. :)

</comment></comment><comment><USER5> I usually re-frame the question to the chocolate cake context.

Like, I have a real weakness when I run into something puzzling, I can't help myself from solving all of it.

</comment><comment><USER6> I tend to focus too much on work and my projects at work.

<comment><USER7> i cringed while reading that.

<comment><USER6> it's a BS question so it deserves a BS answer.

<comment><USER7> That's a good point.

</comment></comment></comment></comment><comment><USER8> Am I the only one who kind of likes the proposed answer?

Sure, it's technically oriented, but a) there's no reason it can't be derived into something non-technical and b) it shows the absurdity of the question with tact and diplomacy. Not to mention that it still manages to actually answer the question!

I'm not a recruiter, but to me, point (b) is a sign of clear intelligence and social grace. Frankly, I like working with people like this.

</comment><comment><USER9> Some of us have weaknesses that can't just be overcome. They are continual struggles and probably always will be. You work hard to counteract these natural tendencies.

I'd go as far as saying everyone has these. The question is intended to tease out whether you're aware of yours and whether you actively work to counteract it.

</comment><comment><USER10> yup, the question is just asking you what you are currently consciously working on improving, thats all.

</comment><comment><USER11> Your greatest weakness isn't the technical edifice that you are least knowledgeable about - which will be constantly changing anyway due to the advent of new technical paradigms and the obsolescence of skills you once relied upon.

Your greatest weakness are the character flaws that reliably lead to poor decisions. For example (not based on you in any way) you might be an impatient person. When you're starting out and tackling relatively simple problems, this is no big deal. But as you graduate to working on more ambitious and complex endeavors, it could turn out to be a major limiting factor.

The real point f this question is to see whether you're the sort of person that will ask for help when you run up against your own limitations, or whether you'll project your shortcomings onto the problem at hand while you attempt to rectify them, reducing overall efficiency. This mindset is a major reason for projects going way over budget despite being glaringly flawed.

I don't like using this question in interviews, because it's neither realistic nor polite to invite a complete stranger to engage in deep character analysis in an asymmetrical commercial negotiation. Even a shallow person can sense the loaded subtext of the question being 'give me an excuse I could use to fire you if I felt like it,' and has a strong economic incentive to obfuscate their answer. So I'll generally ask 'what would you like to be better at?' which typically generates a more honest and useful reply.

When you're on the receiving end of this question, you can leverage it in your favor. For example 'I'm not great at time management - if I'm told a problem is important I'm likely to just keep working on it to the exclusion of everything else. I do better when I have an understanding of the big picture and the relative importance of different tasks.' This is an indirect way of inviting your future manager to share information which you might otherwise not be considered worthy to receive. As a general rule, offer a solution to the problem immediately after the problem statement. This shows you to be both a good team player and require little emotional maintenance, both of which are far more interesting to most managers than your primary competency - especially in tech, where your primary competency probably has a short life before it's made obsolete.

 _Your_ greatest weakness is a lack of long-term perspective. Your post suggests to me that right now you can't imagine yourself doing anything but pounding out code for the rest of your working life. That's not a sustainable trajectory because software development isn't a body of truth like mathematical knowledge, but more like a jigsaw puzzle where pieces are taken away and replaced at random intervals. In short, what you'll be doing in the future will almost certainly not be what you signed up for. For yourself, it's vital to have an answer to the question of what you'd do if you weren't writing code (another common interview question) because there's a good chance that at some point you'll get sick of it.

<comment><USER12> Sorry, but this seems like shitton of fake psychology. Maybe I'm too straightforward, but I can never tell anything about person's mind without giving him a chance to work 2-3 months before making full contract. Interview should cover overall sanity (i.e. basic mental health) and area knowledge/exp, otherwise you present your company as bunch of 'progressive idiots'. People are happy when you don't ask them things they're naturally unable to understand.

People who can win bogus interview have skill to win bogus interview, nothing more. I just can read your or someone else's tip comment and go apply seriously with that in mind. On 10th try I'll master it.

<comment><USER11> _I can never tell anything about person 's mind without giving him a chance to work 2-3 months_

I would enjoy such a relaxed pace.

</comment></comment></comment><comment><USER13> One answer I've been mulling for my next interview is something like the following: I lack whatever skills or traits are needed to advance at my current job. That's why we're having this conversation now.

<comment><USER14> And what skills are those? Your phrasing is pretty shallow if that's all you got!</comment></comment>


Show HN: Wololo CI/CD and release management for the gaming industry - <AUTHOR> https://www.wololoci.com <comment><AUTHOR> Hello HN community we're proud to launch our CI/CD platform focused on the gaming industry if you wanna get early access just ping me or join via our website.

Cheers, Jean</comment>


Where name of the countries come from [Image] - <AUTHOR> http://i.imgur.com/ex6Zu.jpg <comment><USER2> Wow, what a lot of misinformation. I found two mistakes right off the bat...

<comment><USER3> what are they?

<comment><USER2> Iceland, Norway and Spain are all incorrect.

Iceland has nothing to do with ice; in old Norse it is "Island", and means (duh) "island."

Norway has nothing to do with "way"; the Norwegian name for Norway is Noreg or Norge (depending on the language form you use) and in either case means "Northern Kingdom/Reich".

In the case of Spain, they have picked the most provocative way to phrase one of the more unlikely etymologies.

And that's just on first glance.</comment></comment></comment>


Show HN: A daily biography of a historical figure in your inbox - <AUTHOR> http://biographydaily.com <comment><USER2> Cool idea. I signed up. Also, I think you could add a sample bio to the site to boost your conversion rate.

Austin Kleon (the author of Steal Like an Artist, and Show Your Work!) talks about reading obituaries every morning as a tool to help clarify priorities and to remind yourself that interesting people often led non-linear lives.

[https://www.brainpickings.org/2014/03/12/austin-kleon- show-y...](https://www.brainpickings.org/2014/03/12/austin-kleon-show-your- work/)

</comment><comment><AUTHOR> pretty basic backstory: I read a biography every morning to inspire my day. My friends wanted me to create a newsletter about it. I don't know python or anything like that but managed to duct tape some plugins together on a static html page.

I used to run email marketing at Homejoy at one point so wanted to exercise those muscles before they atrophy (currently unemployed)

<comment><USER3> This looks pretty cool! Is there any chance you could include an example or two on the website? I clicked on the learn more button and was only presented with a field to enter my email address. It would be helpful to see an example of what I might be getting, before signing up.

(and from a service point of view, it would help people avoid being disappointed / annoyed if they didn't get what they were expecting!)

</comment></comment><comment><AUTHOR> awesome, thanks all! i agree with the sentiments about adding an example. i have a lot of features i want to include as I build this out.

</comment><comment><USER4> Damn sweet initiative. Signed up!</comment>


A Little Web Spider I Wrote Last Night (code included) - <AUTHOR> http://www.trailbehind.com/trips/view_report/118

<comment><USER2> Here is a web spider in 1 line: perl -MLWP::UserAgent -MHTML::LinkExtor -MURI::URL -lwe '$ua = LWP::UserAgent->new; while (my $link = shift @ARGV) { print STDERR "working on $link";HTML::LinkExtor->new( sub { my ($t, %a) = @_; my @links = map { url($_, $link)->abs() } grep { defined } @a{qw/href img/}; print STDERR "+ $_" foreach @links; push @ARGV, @links} )->parse(do { my $r = $ua->simple_request (HTTP::Request->new("GET", $link)); $r->content_type eq "text/html" ? $r-> content : ""; } ) }' <http://www.google.com>

<comment><USER3> I tested the above script - It works. You are good.

<comment><USER2> thanks, i didn't write it. I remembered that in some magazine from 1999. The link to the author is in the comment below

</comment></comment></comment><comment><USER4> Here's a little web spider I just wrote: "wget -r".

I haven't got a problem with people writing their own quickie scripts, but they aren't really worth putting online without some other compelling reason.

</comment><comment><USER5> It's hard to tell if you're after learning or something to use etc., but if you haven't seen it yet, check out <http://scrapy.org/> for ideas (or even something to use if that is what you are after).

</comment><comment> a-priori For completeness, and to keep with the recent meme around here, here's a web spider I wrote a while ago in Erlang.

<http://github.com/michaelmelanson/spider></comment>


Retrofitting a Claw Crane Game for Twitch Play - <AUTHOR> https://blog.hackster.io/retrofitting-a-claw-crane-game-for-twitch-play-6c5fc6f662a3 <comment><AUTHOR> This is apparently getting big in China.

 _Less than three months since the first online claw crane platform was established, over 30 online similar platforms appeared. New platforms continue to appear at doubling rate. The monthly revenue reaches over 10 million yuan with 30-60% of the gross profit margin currently from one million users. It is easy to see the profitable prospect. Thus, capital companies enter one after another. According to industry data, the market value of broadcasting catching dolls is nearly 60 billion yuan. Such large market has attracted companies and capital of all sizes to flood in._

[http://column.iresearch.cn/b/201712/819007.shtml](http://column.iresearch.cn/b/201712/819007.shtml)</comment>


The Open Handbook of Formal Epistemology - <AUTHOR> https://philpapers.org/rec/PETTOH-2 <comment><AUTHOR> This is an open-access handbook on formal models in epistemology, edited and written by leading figures in the field. I thought it might be of interest to some of the more theoretically inclined HNers.

This is a direct link to the pdf (it can be found on the main page, but it's somewhat hard to spot): [https://philpapers.org/go.pl?id=PETTOH-2&u=https%3A%2F%2Fphi...](https://philpapers.org/go.pl?id=PETTOH-2&u=https%3A%2F%2Fphilpapers.org%2Farchive%2FPETTOH-2.pdf)

</comment><comment><USER2> Have there been any good epistemological studies on the impact of instant messaging and social media? I keep thinking of the book "Amusing Ourselves to Death" and wondering what the authors would have thought of smart phones and micro-burst communication tools like SMS, Twitter, and FB. Clearly it emphasizes the importance of the Sound Bite over fully exploring and developing ideas but I'm hopeful that the medium of podcasting, especially long-form interview podcasts like the Joe Rogan Show, could start to swing things back the other way.

<comment><AUTHOR> I can recommend Misinformation Age: How False Beliefs Spread, by Cailin O'Connor and James Owen Weatherall. O'Connor precisely specializes in applications of formal models, game-theoretic typically, to problems of social epistemology.</comment></comment>


Great, now there's 'responsible encryption' - <AUTHOR> https://www.engadget.com/2017/10/27/great-now-theres-responsible-encryption/ <comment><USER2> How about the government agencies and administration leads in this area? They can use "responsible encryption" for all their stuff, with access granted to relevant oversight committees. If after several years nothing is compromised, and no agency _ever_ encrypts anything "irresponsibly", then this discussion about implementing these laws can start.

</comment><comment><USER3> Time to embrace, extend, and extinguish this terminology: the only responsible encryption is an implementation which is built to be as secure as is known how to design. Backdoors are known to be insecure and are irresponsible.

I wholeheartedly embrace responsible encryption: designs which are both secure and easy to use.

</comment><comment><USER4> Clearly they don't seems to know what is encryption.

Because there are only two types of encryptions: Ones that work, ones that don't.

It's a none or everyone deal: Once an encrypt algorithm got cracked, everyone can then access to the encrypted data.

"responsible encryption", ha! why don't call it "illusional encryption"

</comment><comment><USER5> ...no there isn't. It's just another boring retread of key escrow, and we already vehemently discarded that terribly bad idea in the 90s.

But hey, as the world's about to destroy Net Neutrality and overturn Roe v Wade, why not. Tis the season for terrible ideas and throwing away decades of progress.

</comment><comment><USER6>
        > If companies are permitted to create law-free zones for their customers,
        > citizens should understand the consequences.  When police cannot access
        > evidence, crime cannot be solved.  Criminals cannot be stopped and
        > punished.  There is an alternative.  Responsible encryption can protect
        > privacy and promote security without forfeiting access for legitimate
        > law enforcement needs supported by judicial approval.
        >
        > Technology companies almost certainly will not develop responsible
        > encryption if left to their own devices.  Competition will fuel a
        > mindset that leads them to produce products that are more and more
        > impregnable.  That will give criminals and terrorists more opportunities
        > to cause harm with impunity.  Sounding the alarm about the dark side of
        > technology is not popular.  Everyone who speaks candidly about "going
        > dark" faces attacks by advocates of absolute privacy.
        >
        > Some advocates are motivated by profit.  Others demonstrate sincere
        > concern about the benefits of privacy. They are not concerned about
        > preserving law enforcement capabilities.  Those of us who swear to
        > protect the rule of law have a different motivation.  We are obliged to
        > speak the truth.
        >
        > The truth is that "going dark" threatens to disable law enforcement and
        > enable criminals and terrorists to operate with impunity.
        >
        > Allow me to conclude with this thought: There is no constitutional right
        > to sell warrant-proof encryption.  If our society chooses to let
        > businesses sell technologies that shield evidence even from court
        > orders, it should be a fully-informed decision.

I never thought about it like that. /s

<comment><USER7> will you remove the initial spaces before the angle bracket? makes it hell to read on mobile

<comment><USER8> Not OP, but:

> If companies are permitted to create law-free zones for their customers, > citizens should understand the consequences. When police cannot access > evidence, crime cannot be solved. Criminals cannot be stopped and punished. > There is an alternative. Responsible encryption can protect privacy and > promote security without forfeiting access for legitimate law enforcement > needs supported by judicial approval.

> Technology companies almost certainly will not develop responsible > encryption if left to their own devices. Competition will fuel a mindset > that leads them to produce products that are more and more impregnable. That > will give criminals and terrorists more opportunities to cause harm with > impunity. Sounding the alarm about the dark side of technology is not > popular. Everyone who speaks candidly about "going dark" faces attacks by > advocates of absolute privacy.

> Some advocates are motivated by profit. Others demonstrate sincere concern > about the benefits of privacy. They are not concerned about preserving law > enforcement capabilities. Those of us who swear to protect the rule of law > have a different motivation. We are obliged to speak the truth.

> The truth is that "going dark" threatens to disable law enforcement and > enable criminals and terrorists to operate with impunity.

> Allow me to conclude with this thought: There is no constitutional right to > sell warrant-proof encryption. If our society chooses to let businesses sell > technologies that shield evidence even from court orders, it should be a > fully-informed decision.

</comment></comment></comment><comment><USER9> I've been seeing the 'responsible encryption' meme popping up quite a bit recently. Like this bloke, who thinks people that want working encryption are extremists. [http://www.circleid.com/posts/20171024_legal_controls_on_ext...](http://www.circleid.com/posts/20171024_legal_controls_on_extreme_end_to_end_encryption_ee2ee/)

</comment><comment><USER10> Do they have any real proposals? It would be interesting to see what they want to do. It sounds a little like "clean coal" which never materialized.</comment>


The advertising equivalence principle? - <AUTHOR> http://laserlike.com/2008/09/14/the-advertising-equivalence-principle/

<comment><USER2> I wish more people would do this math before launching a startup than plans to monetize via advertising. It's just a quick back-of-the-envelope calculation, but I'm surprised at the number of startups that naively think they'll get rich with Google AdSense.

One small thing this calculation ignores is that the CPM, CPC, and CPA models shown aren't exactly equivalent. It depends on how much risk the advertiser is willing to take. With the CPA model, there is no risk - you only pay when the action happens. With CPM and CPC, you may get better or worse leads, so there is some variability.

On the whole, this post makes an argument that needs to be made more often: Have a monetization plan other than advertising.</comment>


Welcome to Mongolia's New Postal System: An Atlas of Random Words - <AUTHOR> http://www.npr.org/2016/06/19/482514949/welcome-to-mongolias-new-postal-system-an-atlas-of-random-words <comment><USER2> It seems like a major drawback to this approach is that the address for nearby locations have nothing in common. That makes it harder to get a sense of where something is based on the address alone.

</comment><comment><USER3> Previous discussion here: [https://news.ycombinator.com/item?id=11894368](https://news.ycombinator.com/item?id=11894368)

I'll repeat my opinion: this is a really dangerous move for Mongolia, and one I hope will not be emulated by other states.

</comment><comment><USER4> Very cool idea! Just wondering if it's feasible to do something similar with two words?

<comment><USER5> Sure but the area covered by each pair would be much larger due to the drastically smaller number of combinations available.</comment></comment>


The Dual-Core, ARM-Powered Commodore 64 - <AUTHOR> http://hackaday.com/2016/07/02/the-dual-core-arm-powered-commodore-64/ <comment><USER2> Even more interesting as it's not dual-core as in two 6502 cores, but one 6502(or 6510, I expect, as bank switching and the tape port won't work on the C64 otherwise) and one Z-80...

This is similar to the level of "brain transplants" it seems most remaining classic-Amigas has these days (accelerator boards with FPGAs + a graphics core and what-not on the FPGA in addition to the CPU core + fast RAM), to the extent that the original boards are increasingly mostly a fat keyboard with IO ports.

On one hands these hacks are quite cool. On another hand many of them are pretty much full computers where going the whole hog and replacing the motherboard is increasingly looking like the better alternative..

E.g there's a "emulator in a C64 cartridge" that's powerful enough to emulate Amiga's, where the C64 is basically just turned into an IO device when it's plugged in - but at least there's some poetry in that, as some Amiga models - A500(+) and A2000 at least - had a 6502 compatible SoC as the keyboard controller.

<comment><USER3> > Even more interesting as it's not dual-core as in two 6502 cores, but one > 6502(or 6510, I expect, as bank switching and the tape port won't work on > the C64 otherwise) and one Z-80...

There was a bbc setup with a second CPU on the other side of the 'tube' which had a Z80 option.

[http://mdfs.net/Software/Tube/Z80/](http://mdfs.net/Software/Tube/Z80/)

[http://www.primrosebank.net/computers/bbc/bbcz80.htm](http://www.primrosebank.net/computers/bbc/bbcz80.htm)

<comment><USER4> ...the 32016 is almost available too (pity that the Master 512 and TMS5220 Speech Generators are not implemented)

[https://github.com/hoglet67/PiTubeClient/tree/master/NS32016](https://github.com/hoglet67/PiTubeClient/tree/master/NS32016)

...hopefully they will find their way back to BeebEm for Unix and run PanOS with BCPL

[http://cpu-ns32k.net/Panos.html](http://cpu-ns32k.net/Panos.html)

<comment><USER3> I still have a 32016 chip stamped 'pre-production' somewhere in storage.

</comment></comment></comment></comment><comment><USER5> Years ago I tried running my old C64 games on faster hardware was disappointed that many games from back then seemed to assume a particular CPU speed. For instance all the D&D boxed set games (like pool of radiance/curse of the azure bonds) would have characters move during combat based on the the speed of the computer. On a faster processor combat was over in a blink of an eye making the game unplayable.

I believe most of the software emulators slow down the clock speed so games are playable, but on actual faster hardware, there's prob a lot of non- playable games. I really don't know why this was the case :/

<comment><USER6> Ah yes... it's finally been long enough... in the old days we used to see the first attempts to make programs run at the same speed everywhere or at least on two different PCs.... and it was a huge pain... wasted extra cycles to figure out how fast things were moving....

And no consistent sw arch to run things at a steady rate. And even when they did run at mostly the same rate in most of the sections of the program heh, they usually did so by wasting cycles, so the prg ran no better on faster hw....

But that was a long time ago, before sw libraries were common! And when APIS were scarcely heard of, at least for home computers and also took too much overheard....

It was the best of times, the worst of times hahaha. No one could foresee the techniques and platforms we have now. :) ah the good old days...

<comment><USER7> Alley Cat managed just fine, and that's a game from 1983-1984

> _One of the most amazing things about the game is that it actually sets its > own clock speed so that the speed of your computer is irrelevant. This means > you don 't need Moslo to enjoy the game :)_

[http://www.myabandonware.com/game/alley- cat-1q](http://www.myabandonware.com/game/alley-cat-1q)

<comment><USER8> Ooo... I remember playing that a LOT on the good ol' Tandy 1000 (8088/4.77 MHz/256KB RAM/9-pin CGI/MS-DOS)!! Sure brings on the nostalgia... :-)

</comment></comment></comment></comment><comment><USER9> I've always wondered what made the C64 so lasting in our memories. My Commodore 64 days were 1986-1990 when I switched to IBM clones. I still hold my C64 days as the "good ole' days," some 26 years later. Perhaps it was because I was young.</comment>


Was Wittgenstein Right? (2013) - <AUTHOR> https://opinionator.blogs.nytimes.com/2013/03/03/was-wittgenstein-right/ <comment><USER2> This reminds me of someone who once told me that the vast majority of philosophical problems are self-inflicted and caused by the intentional use of vague and ambiguous definitions, and therefore could be solved trivially simply by agreeing on a definition for something.

One example given was the Theseu's Paradox (or The Ship of Theseus): [https://en.wikipedia.org/wiki/Ship_of_Theseus](https://en.wikipedia.org/wiki/Ship_of_Theseus)

The entire problem only exists because you're intentionally using a vague term in the problem, therefore causing the problem itself.

At least that was the commentary, I'm not an expert in the subject, and I'm sure many will disagree. But then, even the disagreeing is just pointlessly creating a problem for the sake of the discussion.

<comment><USER3> I think you're missing something really profound here. I wrote my masters thesis on identity problems in version control systems (Git, Mercurial, Subversion, and the like). These systems are forced to take a stance on the Ship of Theseus problem — they're tracking the identity of files/documents whose entire contents, name, and format may change over time.

Different systems have chosen to take very different stances on this. As it turns out, taking a stance on what makes a file a file (or a ship a ship) — being explicit rather than vague — does not solve the problem. Not even close. In fact, one of the many little things that make Git a brilliant piece of software is that it refuses to take a stance on identity. Git is intentionally vague about what makes a file a file. It doesn't actually track it at all — file identity is determined retroactively. It's a question for which Git intentionally doesn't have a straight answer.

What I think is really fascinating about all of this is that computers are forcing us to deal with age-old philosophical problems head on. These are not just interesting riddles anymore. They're real problems that need concrete solutions. Event more interestingly, there is something in this that establishes computing as categorically different from just pure mathematics. Computing forces us to bridge abstraction with the real world — to answer questions like what is the relationship between an abstract model and the thing that is being modelled. This to me is really exciting, and what follows from it can't be easily dismissed with a comment like "most philosophical problems only exist because language is vague".

<comment><USER2> > These systems are forced to take a stance on the Ship of Theseus problem — > they're tracking the identity of files/documents whose entire contents, > name, and format may change over time.

But that's my point: when you choose to make a call on the definition os "the same", the problem no longer exists. SoT only exists while you refuse to provide a more precise definition for "the same".

> Different systems have chosen to take very different stances on this.

Yes, and _any_ stance will solve the problem. You could say that it is the Schrodinger's Cat of philosophy: the moment you decide to go one level deeper (open the box and observe the cat), the problem ceases to exist.

> These are not just interesting riddles anymore

Agreed, and the point of the original commentary was that they were never interesting riddles to start with, they were only riddles at all because we purposefully forced them to be riddles. We avoided the fact simply to carry on the discussion.

Similarly, any judge won't care about the SoT, because at the end of the day, that judge will have to make a call if the ship in question is Theseus' or not.

And just like quantum mechanics, the moment you look at it, the "wave function collapses" and you have a solution.

SoT is only a problem for the same duration as Schrodinger's cat: while you refuse to open the box.

<comment><USER3> I think you missed the part where I said that Git intentionally _doesn't_ take a stance. Or rather, it defers the commitment, a bit like Schrodinger in regard to his cat. I guess what we agree on is that the problem goes away (kind of) as soon as that deferred commitment is made — but the problem goes away only for that particular instance, not in general.

What I'm arguing is that dismissing these philosophical problems as just nonesense rooted in the vagueness of language is missing the point. If nothing else, these paradoxes lay bare the vagueness of language, but moreover they beg the question of why language is so vague. What's more, it turns out that making language more precise — as we've tried to do with computers and mathematics — doesn't seem to solve the problems at all. In fact, it seems to lead to even more trouble, as, for example, the designers of Subversion or Mercurial eventually discovered.

<comment><USER2> > What I'm arguing is that dismissing these philosophical problems as just > nonesense rooted in the vagueness of language is missing the point.

Oh, I agree, I don't think they are nonsense at all, and they do force us to think about the way we communicate and so on.

That's why I call them the Schrodinger's Cat of philosophy, while they only exist until you decide to solve them, they do force us to think about how we view the world.

But then you end up in another problem for philosophy: if what remains after you remove all the natural sciences is just the problems that humans create due to language, law, understanding, etc. and all of those are covered in subject-specific human sciences (law, linguistics, psychology, behavioral economics, etc.), what is left for philosophy?

Apparently, this is covered partially by this week's NPR Philosophy Talk:

[https://www.philosophytalk.org/shows/does-science-over- reach](https://www.philosophytalk.org/shows/does-science-over-reach)

</comment></comment></comment></comment></comment><comment><USER4> Another angle on Wittgenstein's rectitude, by the folks at Existential Comics :

[http://existentialcomics.com/comic/245](http://existentialcomics.com/comic/245)

In which W's talking lion shows a taste for English pop groups and Ultimate Frisbee

</comment><comment><USER5> The argument about science replacing philosophy is constantly presented as a nuanced conundrum.

But there really are scientific questions and there really are philosophical questions.

For example, when two cars crash, science can in principle tell us exactly at what speeds they were traveling, what the drivers were doing, and all the physical details.

But as humans we want to find not just what happened but who's at fault.

When we ask questions about guilt, we're asking a non-scientific, philosophical question.

Understanding precisely what happened is important in assessing guilt, but only up to a point. I don't mean questions of physical cause and effect, or even of legal guilt, but actual culpability. If you think that question is answerable, then you're in the realm of philosophy.

Questions of credit and blame lead to questions of good and bad. If you believe that ethics are a real thing, then every decision has an ethical dimension, and science can't really help with that.

The best attempt I've seen at reconciling science and physics is by Bob Doyle at [http://www.informationphilosopher.com/](http://www.informationphilosopher.com/)

<comment><USER6> Why do you think that guilt is a non-scientific question? Is it only because it is too inadequately defined to produce a consistent interpretation?

And guilt probably has little to do with fault.

<comment><USER7> The comment was presumably talking about guilt in the ethical rather than factual sense.

E.g. Trolley Problem [https://en.m.wikipedia.org/wiki/Trolley_problem](https://en.m.wikipedia.org/wiki/Trolley_problem)

<comment><USER6> Do you mean guilt-the-emotion, or guilt as a causal relation? Neither of those are beyond the pervue of science. The only troubles you get -- the reasons scientists don't engage in this kind of theorizing -- is that the domain is both complex and culturally sensitive, and thus work doesn't receive funding and appreciation. It's not because it can't be done.

<comment><USER7> I meant guilt the causal relationship.

As you note, a large portion of it depends on value judgements. If I wilfully murder 1 person to save 3 from being accidentally killed, am I guilty? What if I take no action and allow 3 people to be accidentally killed?

Without attempting to Asimovly define the value of all possibilities, I'm not sure how science _can_ answer these questions in any meaningful sense.

Without tumbling into a morass of complexity (e.g. a life is worth this because of GDP per capita and birth rate and lifespan, and taking an action is to be valued this way because of neuroscience and experimental psychology) that, should it be fallen into, would start to look more like ethical philosophy than post-Enlightenment science.

But then, that's why they were both the same field before experimental repetition was enshrined...

</comment></comment></comment></comment></comment><comment><USER8> Einstein, Bertrand Russell and even Wittgenstein himself were all armchair philosophers. They just formed their deductive powers in the modern scientific era.

Wittgenstein is well-known for changing the origin of mathematical problems to the most convenient in his mind - about as close to philosophy as you can get.

</comment><comment><USER9> Funny that this is being posted here. Don't the foundations of computing come from Philosophy?

<comment><USER2> For any X, the foundations of X come from Philosophy.

</comment></comment><comment><USER10> Yes I was.

</comment><comment><USER11> Which time?

</comment><comment><USER12> To save you the click:

"Wittgenstein claims that there are no realms of phenomena whose study is the special business of a philosopher, and about which he or she should devise profound a priori theories and sophisticated supporting arguments. There are no startling discoveries to be made of facts, not open to the methods of science, yet accessible "from the armchair" through some blend of intuition, pure reason and conceptual analysis. Indeed the whole idea of a subject that could yield such results is based on confusion and wishful thinking."

<comment><USER13> In other words, philosophy is a form of mental "self-stimulation." It feels like you're accomplishing something when actually you aren't. That matches my views at any rate. Not that there's anything wrong with a bit of self- stimulation. I'm here commenting after all. But philosophy is pretty unique in that they present their fun as some kind of noble pursuit.

<comment><USER14> More like, philosophy is the extreme version of the 'Uncategorized' box of science -- it's almost the leftover pile which gets slowly picked up and put into neat boxes of knowledge. Mechanical nature of life was once philosophical musings, now is biology. Atomic nature of matter were philosophical musings, now physics. Nature of consciousness is now philosophy, will sooner or later become neuroscience and artificial intelligence.

Philosophy isn't useless. It is a ground for preliminary discussion before the matter is ready to shift into more solid ground -- mathematics, logic, or hard sciences.

That it suffers from (a degree of) infinite dwelling on pointless topics is inevitable, because it is very hard to judge what will one day be useful or legitimate of discussion; making the false positive nil will increase the false negatives too much. Plus if philosophy decided on a too strict topic regime, soon another field would be born to house the outcasts of academic philosophy, thus becoming the new leftover pile of reason.

<comment><USER15> Pretty much this. It's like pre-science. I could see how a lot of modern philosophy could be rehashing issues that have already been extensively formalized though

<comment><USER16> There is plenty of knowledge that is non-scientific. Not all knowledge is accessible through the scientific method. Ethics, metaphysics, etc.

</comment></comment></comment></comment></comment><comment><USER17> I think he was right when he wrote "Wovon man nicht sprechen kann, darüber muß man schweigen."

I once read a book by a Zen Master called "Wanting Enlightenment Is a Big Mistake" and by the end of it, I agreed. Hence the book was worthless.

Edit: so is it fitting if this post earns me negative karma?</comment>


Medicine needs to embrace open source - <AUTHOR> https://www.zdnet.com/article/medicine-needs-to-embrace-open-source/ <comment><USER2> I'm not an expert in drug development, but even I was really skeptical when reading the Washington Post article on Pfizer "burying" the Alzheimer results. Derek Lowe (an actual drug discovery chemist) did put out on article with his thoughts on the article, which were similarly damning: [https://blogs.sciencemag.org/pipeline/archives/2019/06/06/a-...](https://blogs.sciencemag.org/pipeline/archives/2019/06/06/a-missed- alzheimers-opportunity-not-so-much)

The impression the original article gave was that the company ignored compelling evidence because they couldn't make any money off of it. But the "compelling evidence" actually comes across more like the sort of thing you'd find here: [https://www.tylervigen.com/spurious- correlations](https://www.tylervigen.com/spurious-correlations) . As Derek Lowe puts it, "One of the biggest objections to the idea inside the company was that this finding was unlikely to be real because Enbrel doesn't really penetrate into the brain."

A final coda: the actual data may not have been public, but the potential correlative results were published in 2010: [https://www.ncbi.nlm.nih.gov/pubmed/20478733/](https://www.ncbi.nlm.nih.gov/pubmed/20478733/). So much for being buried?

<comment><USER3> Exactly. People tend to overstate the importance of spurious, surprising findings that don't make scientific sense. Some of these may lead to breakthroughs, sure. But the overwhelming majority are just noise. And it takes experts to decide which are worth investigating. To wit, anti-vaxers love subgroup analysis without supporting scientific logic (ie more autism in this population of 5 boys from the study).

I'd hate to see old, frail people getting Etanercept (an immunomodulator) to prevent Alzhemier's based on very questionable evidence when all they really get are the costs (increased risk of serious infections leading to death-- an FDA black box warning).

</comment></comment><comment><USER4> There is an Awesome List[1] of open source healthcare projects. Also a quite nice blog[2] about various FOSS initiatives. Some of the important medical projects were accepted[3] in the Google Summer of Code this year.

[1] [https://github.com/kakoni/awesome- healthcare](https://github.com/kakoni/awesome-healthcare)

[2] [https://medevel.com/](https://medevel.com/)

[3] [https://summerofcode.withgoogle.com/organizations/](https://summerofcode.withgoogle.com/organizations/)

</comment><comment><USER5> Fun fact, it costs hundreds of dollars, just to LOOK at some safety standards in medical devices, for example:

[https://webstore.iec.ch/publication/2606](https://webstore.iec.ch/publication/2606)

<comment><USER6> Weirdly, this can also be true in FOSS software. Despite e.g. DBMSes like Postgres being open-source, SQL-the-standard costs ~USD$180 to read: [https://www.iso.org/standard/63555.html](https://www.iso.org/standard/63555.html)

<comment><USER7> Here's a related discussion:

[https://news.ycombinator.com/item?id=20174847](https://news.ycombinator.com/item?id=20174847)

</comment></comment></comment><comment><USER8> If you are interested in open source medicine there are two amazing HOPE talks you should watch:

1) How to torrent a pharmaceutical drug - [https://youtu.be/Py5TkirrO-U](https://youtu.be/Py5TkirrO-U)

2) Torrent more pharmaceutical drugs (follow up 2 years later to video 1) [https://youtu.be/cfrfs7W-K_k](https://youtu.be/cfrfs7W-K_k)

</comment><comment><USER9> This is one of the better examples of where the use of 'open source' rather than 'free' distracts everyone from the end goal.

This particular case may well be a beat-up, but there's undeniably a regular habit within pharma to not publish neutral or negative results, and we don't know how useful those data may be simply because we don't have access to them.

AFAIK no country has laws requiring this, so it's not a regulatory / enforcement problem - it's a legislative one.

</comment><comment><USER10> > Because Pfizer believed it would lead others down a wrong path.

Call me a sceptic but I don't believe that for a minute.

Instead I'm sure they acted on some other ulterior motive.

<comment><USER11> Believe me: if you had a drug that had _any_ positive effect on Alzheimers you'd be rich beyond the dreams of Croesus. What possible incentive could Pfizer have to suppress something they thought could be useful?

Read the link to Derek's Loew's analysis in Science for deeper analysis: it's posted elsewhere on this discussion.

<comment><USER12> Valacyclovir

[http://www.virology.ws/2018/11/08/herpes-simplex-virus- and-a...](http://www.virology.ws/2018/11/08/herpes-simplex-virus-and- alzheimers-disease/)

<comment><USER13> At the end of your article:

"I understand that AD affects many families who would very much like to have an intervention for the disease, and are anxious to see this trial clinical proceed. Nevertheless, I do not feel that this trial is warranted based on the existing data. Additional studies are needed to understand the mechanistic connection between HSV-1 infection and AD, and specifically to clarify whether infectious virus, or viral proteins are involved."

Sounds like it's not yet in the realm of proven effectiveness.

</comment></comment></comment></comment><comment> forgot-my-pw I think it will be cool if there's a pharma company that would use crowdfunding to decrease the medicine costs. So each tier/goal will unlock additional benefits.

For example, if they created drug X with the research cost of $10M. When sales/crowdfunding reaches:

\- $1M: drug margin is reduced by 10% \- $5M: drug margin is reduced by 50% \- $10M: drug is sold at cost & recipe is now open-sourced

These clear goals will be big incentive for people and organizations to donate. A successful fundrasising could drive new medicine cost way down or open-source it.

But of course, the system can still be exploited by inflating cost numbers, etc.

<comment><USER14> Maybe it could work for a non profit, but the medical world has so many methods they start exploring but find are unfruitful (with many thousands to hundreds of millions invested). You essentially have to make boatloads of money on some products over a long time frame to continue the research and development efforts.

<comment> forgot-my-pw For sure. This will only work if someone wants to fund an "ethical" / non- profit pharma research company.

</comment></comment></comment><comment><USER15> We should start with an open source drug interaction database...

<comment><USER16> DrugBank contains interactions: [https://www.drugbank.ca/interax/drug_lookup](https://www.drugbank.ca/interax/drug_lookup)

And is downloadable under a CC license: [https://www.drugbank.ca/releases/latest](https://www.drugbank.ca/releases/latest)

The US National Library of Medicine provides an API to query drug interactions based on DrugBank: [https://rxnav.nlm.nih.gov/InteractionAPIs.html#](https://rxnav.nlm.nih.gov/InteractionAPIs.html#)

<comment><USER15> This is not useable for electronic prescription of drugs in the US. That is the problem I want solved.

<comment><USER16> Could you explain more what you mean, both about what problem you want solved and why this is not useable?

<comment><USER15> There is currently a monopoly in electronic prescriptions in the US. Surescripts runs the only network that connects electronic health records to pharmacies. (over 99% of electronic prescriptions are sent using them) They dictate that you must have a contract with an approved commercial prescription drug database vendor.

I want the industry to come together and make an open source drug database so that it can become the world standard. This way a lot of legacy businesses will no longer have a reason to exist and charge exorbitant licensing fees.

<comment><USER16> I am still having trouble understanding the specific problem you want solved, and what an additional open drug database would add that DrugBank lacks but that is required to accomplish your solution.

It seems like your frustration is mostly with the Surescripts monopoly on electronic prescribing. You say that they dictate an approved commercial vendor. This is a very different problem, and would have very different solutions, than the problem _We don 't have any open source drug interaction database_, which is where this thread started.

<comment><USER15> The difference is quality. The existing open source solutions are frankly not good enough. Industry should come together to sponsor an open version that matches the quality of vendors which will become the canonical source of truth for the world.

<comment><USER17> What's the monetary benefit to the industry in doing that?

The open source solutions aren't good because validating and fixing this data is very time consuming (read: expensive) and carried legal liability (read: expensive). Open source tends to not be good at requiring many people to do tedious things (see: most open source documentation). Companies could pay people to do it but then you've recreated a commercial vendor except competitors who don't pay get a benefit. Companies tend to open source things which are not direct competitive advantages for others in the same industry while this would be exactly that.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> I know it's off-topic, but with all the attention FOSS and other Open-Source projects get these days, I've been thinking about the final consequences and paradigm changes they impose on businesses and societies. In a world where FOSS has won, what new businesses emerge and how do they operate? It's an interesting question for me, because I believe one reason we're not there yet is not that business owners have philosophical problems with the idea of Open- Source, but rather most don't know how that'll be profitable for them. I know there are successful examples in which Open-Source has helped the business model (RedHat, etc.), but the bigger question is how can it be successful in other businesses and contexts (such as medicine)?

<comment><USER19> you might look at the novel Autonomous by Annalee Newitz for her take on such a world, it's quite interesting

<comment><USER18> Thanks for telling me about it! I'll sure give it a look.

</comment></comment></comment><comment><USER20> This is a case of reading the headline, but really, no one other than developers embrace open source, if were honest with ourselves.

<comment><USER21> Physicists seem to be doing a pretty good job, mathematicians as well.

<comment><USER20> For some areas of physics. In my field(plasma physics modelling), non-open source codes abound.

<comment><USER22> Why? Who owns them?

<comment><USER20> There are some understandable reasons, some of them related to them containing potentially export controlled models. Even then, you could strip out those bits but for some reason, no one does it because they see no need to once they have access to the code. Often a hefty (for academics) license of 4 figures a year gives them access to modify the source code but they can't share their modifications with others.

</comment></comment></comment></comment></comment><comment><USER23> This news site is absurd! Reminds me of [https://news.ycombinator.com/item?id=20172214](https://news.ycombinator.com/item?id=20172214)

</comment><comment><USER24> Medicine in America will never do this, at least not for the foreseeable future.

They moved from 'cures' decades ago.

Plus add a big heaping spoonful of the FDA and the red-tape that must be jumped through.

Anytime someone ingests something, someone, somewhere, will die from it.

When you work in pharma, you learn that there are teams of lawyers and budgets just to deal with the inevitable deaths.

Just getting to human trials during the experimentation phase takes years.

I'd say look more toward real-working natural cures and improving our lifestyles and environments would be more realistic in the short term.

<comment><USER25> "According to industry watchdogs, reducing clinical trial costs will not help curb list prices because those prices are not determined by investment costs; they're determined by what the makers think the market can bear, which helps explain why profit margins are so high."

[https://www.nytimes.com/2018/06/08/opinion/drug-approval- cut...](https://www.nytimes.com/2018/06/08/opinion/drug-approval-cutting- prices.html)

<comment><USER26> isn't that a bit circular? If investment costs (lets include capital, time, and risk)were low, wouldn't there be a influx of motivated innovators to create a greater selection of new drugs, which would either drive down price of equivalent drugs (or produce better drugs with are more efficacious/less toxic)? If investment costs/risk aren't limiting abundant new drugs, what is?

<comment><USER24> The FDA.

IIRC approval time takes about 10 years minimum. Then you have 20 years to cash that cow out before the patent runs out.

<comment><USER26> So the FDA should be more lax on requirements for approval? Should they reduce the Preclicnal PharmTox requirements? How long should a cancer trial take if it has 500 brain cancer patents to enroll and it measures improvements in survival that takes over a year? Should Pharma just one study or should they do a coulple of serially run clinical studies to understand the toxicities and how the drug works best? I'd love for development timelines to be quicker, but I need a Gantt chart to better understand where the time savings would come from without compromising the safety and data supporting efficacy. Help me understand.

Also. Most substantial patents are filed way before the approval of the drug. Rarely if ever has a drug had, for example, a composition of matter patent for 20 years after approval-- even with the extensions for regulatory delay that the USPTO allows. Not to say that Pharma don't extensively engage in product life-cycle management, sometimes very questionably extending exclusivity of products, and that is something that should be addressed.</comment></comment></comment></comment></comment>


Is it Politically Incorrect to Criticize Open-Source Software? - <AUTHOR> http://www.cforcoding.com/2009/07/is-it-politically-incorrect-to.html

<comment><USER2> He explicitly states in his conclusion that "whether or not anyone has the right to criticize open-source software is an irrelevant distraction". Well I must say he picked a great title! It ought to be "My Complaints About Spring Batch and Some Thoughts On Sexism"

</comment><comment><USER3> I don't know about the _political_ implications of harshly criticizing volunteers, but it sure makes those who do it come of as unpleasant people.

</comment><comment><USER4> It's not obvious that the difference in computer science degrees by gender is due to brain chemistry. With the "politically correct" idea that everyone should be able to pursue whatever field they want without social barriers, researchers are looking ([http://www.seas.upenn.edu/~rpowell/documents/sigcse204-powel...](http://www.seas.upenn.edu/~rpowell/documents/sigcse204-powell.pdf)) at ways to improve the teaching of computer science.</comment>


Ask HN: How to download, archive and search your favorites in your own library - <AUTHOR> I want to remember as much as possible as quickly as possible. One of the ways I remember stuff is to save amazing articles I read as favorites. The idea is, if I need to refresh that knowledge I go to that article.
There are two issues: 1. I don't have a local copy. 2. There are too many good educational resources / articles that I read.
Solving 1 is doable. But how do I solve 2? I have so many things on security, math and other stuff that I read or saw throughout the years that I don't even remember what I have.
My idea to counter this is to create a personal search engine. A mindmap might work as well. I'm not fully sure what the best approach is, but to create a personal search engine would be handy anyway.
So I was wondering, does anyone know about an app that is able to save your favorites in such a way that it also downloads it to a computer and adds it to a local search engine that you also have running on your computer?
And my second more broad question is: how would you solve this problem in general? <comment><USER2> Hi! On Bubblehunt ([https://bubblehunt.com](https://bubblehunt.com)) you can get what you need - this is the search engine for your favorites.

But this service works in the web - and you can have access to your information on any devices, not only on your PC.</comment>


Ask HN: iOS or Android for a beginner? - <AUTHOR>

I'd like to build a mobile application for a personal side project, but I've never done any app development before. I don't really care which platform I use. I'm just looking for the one that will be the fastest and easiest to pickup. There seems to be a lot of disagreement on the web so I thought I'd ask here.
The core parts of the app will be parsing a QR code and accessing GPS to relay the user's location.
If it is at all relevant, I have a MS in mechanical engineering and I've done a fair amount of C++ and Python coding for other projects. I would say I'm probably just past the beginner stage for HTML/CSS/jQuery, but not comfortable enough to go write a web app without a lot of questions.
Thanks in advance for input. <comment><USER2> Full disclosure: I'm biased as I'm primarily an Android engineer. But, I've led teams and developed extensively for both platforms, so I'll tell you a couple things I've observed.

1\. If you already own an iOS or Android as your primary device, that should play big into your decision. You'll have a much easier time maintaining interest in your project as well as being more likely to create a more compelling product if you live on the platform.

2\. Google's Android documentation and guides are on a _completely_ different level than Apple's for iOS - Google's is just so much more extensive. It's really not even close IMHO. If you're a beginner I think this will make a very large difference.

3\. The iOS developer program and provisioning system is a PITA, even for experienced developers. Often times when learning something new, all it takes is a small roadblock to become frustrated and lose interest. With Android, building apps for you and your friend's devices is very easy, and submitting to Google Play is _much_ easier, with no review process and again just one guy's opinion, but despite a recent (and dearly needed) makeover, iTunes Connect is still inferior w.r.t usability compared to the Android Developer console.

4\. I used Eclipse + the ADT plugin for years and while it wasn't terrible (I was come from J2ME development for BlackBerry so the bar was quite low), I was always jealous of Xcode. Google has now addressed this with Android Studio. It's still a bit of a moving target, but I now consider on par or better than Xcode.

5\. Don't let the haters scare you away with the fragmentation arguments. "Fragmentation" is a feature :) Truthfully, if this is just a side project, I would set a minSdk for your app a minimum 14, or even 19 if you want to, and be amazed by how your app works so well on the 100s or 1000s of devices out there that it supports.

Couple words on iOS:

1\. Whereas with the x86 emulator and Genymotion, the Android _emulator_ has dramatically improved, the iOS _simulator_ is still superior with respect to ease of use and pace of development.

2\. If you go the iOS route, I would strongly suggest to go directly to Swift. It's where the puck is going and you've got a chance at this point to be a relative expert among a sea of objective-c developers, who will need to learn it as Apple increasingly shifts the platform.

3\. This is very subjective and nebulous, but after using both platforms extensively, I've found the iOS APIs are simply better. You'll find things _just work_ and you'll be continually surprised to find the puzzle pieces just fitting together. (ie "hey I wonder if there's a way I do X...oh perfect there's just a simple method call for it")

4\. As others have noted, if you don't have a Mac then the point is moot, Android is your only option.

Hope this helps!

<comment><USER3> While I mostly agree with what you have said, I just want to clarify #3. Now with TestFlight, I've found it to be very easy to get apps on other people's devices and update them whenever I want.

<comment><USER2> Sure, testflight makes it easier (it's been around for years...). But you still have to invite people to testflight, after theyve signed up _and_ added their device, you can provision the app for each device, after adding it to your developer account. Finally you can upload the build and have people install it. Obviously the process gets easier with time, and if you're not adding new people to the team.

But, with Android you build the APK and send out as an email attachment to whoever and you're done. Set up a shared directory on dropbox or google drive or w/e if you want.

<comment><USER3> I apologize for the delayed response. HN really needs reply notifications like Reddit. Anyway...

Apple bought testflight. No more provisioning on up to 1000 devices. Android is still much simpler, but I was just pointing out that you don't have to provision devices or add their udid anymore.

</comment></comment></comment></comment><comment><USER4> I'd recommend Android for the following reasons:

1) The official documentation is way better and much more extensive.

2) It's $35 one time vs $99 a year. Maybe not a big deal to you but something to consider.

3) In my experience it is much easier to get 'Hello World' up and running on an Android device than on an iOS Device. You can use Eclipse or Android Studio on any platform rather than having to learn XCode.

4) Publishing is WAY easier. You can finish your app and have an apk live on the Play Store within an hour. With Apple this process takes ~1 week and you might get rejected.

5) You get to code in Java. While it may or may not be a 'better' language than ObjC it is definitely better documented.

For fairness, here are some advantages of iOS:

1\. The simulator is much faster if you don't have a physical device.

2\. Layout design is definitely easier because of the small number of screen sizes and form factors.

3\. If your goal is to make money, iOS is still ahead.

</comment><comment><USER5> It's a coin toss, but I went with iOS and don't regret it. The biggest reasons I don't regret it have nothing to do with the platform itself and have everything to do with having resources like raywenderlich.com and the articles on that site. I found that community and environment to be very very helpful.

The only frustration I really had was that, in the Apple world, things change fast. When I'd Google something, I'd find some code from 4 years ago that would show ways of doing things that were outdated. There are also minor disputes here and there on what's "the best way" to accomplish things, but overall, coming to -a- solution in most cases never took more than a day or two of frustration.

</comment><comment><USER6> If you have a Mac then iOS is practical. Otherwise, only Android is practical. Android is also practical of course if you have a Mac. Having an Android device is another reason to look at Android programming.

In my opinion, a web app is probably easier to write than a mobile app because:

\+ Web apps have a longer history and therefore more information about their design and construction.

\+ There is more choice of frameworks and more choice of language e.g. something as simple as Bottle for Python [1]

\+ Basic web apps can be written without learning a framework, just some library calls.

Of course, getting GPS and QR codes directly isn't really possible for a web app. Though processing them is.

[1] [http://bottlepy.org/docs/dev/index.html](http://bottlepy.org/docs/dev/index.html)

</comment><comment><USER7> It doesn't matter. :-)

If your criterion is "fastest and easiest to pickup", the expected marginal advantage of one or the other is smaller than the time you'll spend choosing between them. The only way to really find a preference is to dive in, learn one, and then maybe learn the other later.

There may be some _other_ criteria that decide the issue for you, e.g. market conditions or owning a Mac. But really I'd just pick whichever gives you greater enjoyment.

Best of luck!

Edit: I did want to say that if you go with iOS, the O'Reilly book Programming iOS by Neuburg is excellent. I felt their Android book was pretty weak.

</comment><comment><USER8> I'm surprised people are putting emphasis on programming language. You can use frameworks to code in LUA or C# for either IOS or Android.

As others have mentioned, to compile for IOS you'll need a Mac. Personally I develop for Android, but use a Mac. My recommendation is to look at which devices your consumers (including you) have and go with it.

Read as others commented regarding Amazon's annual fee vs. Android's one-time (lower) fee. The PO box comment is interesting, but only if you're going to sell your app or have in-app-purchases - free apps/ad-apps do not require any address.

<comment><USER3> *Apple's annual fee

<comment><USER8> Thank you, I'm preparing app for Amazon, and it's just on my mind.

</comment></comment></comment><comment><USER9> I think the following should be considerations:

What phone do you have? What phone do you think your testers and users will have?

Do you have a Mac? You will need on for writing an iOS app.

What languages do you favor? For iOS, mainstream ones are Objective-C and Swift (arguably not yet, but it likely will be fairly shortly). For Android, Java. You can use C++ on both, but you will need something else for the UI on iOS and, I would guess, on Android.

Did you google for libraries you would want to use? AFAIK, iOS doesn't that overly parse QR codes; Android may or may not.

</comment><comment><USER10> Because you know a little bit of HTML/CSS/jQuery, why don't you try to build it as a cross-platform HTML5 mobile web app using Cordova/PhoneGap?

There's a bar code scanner plugin for Cordova:

[https://github.com/wildabeast/BarcodeScanner](https://github.com/wildabeast/BarcodeScanner)

And location can be accessed using the standard geolocation plugin for Cordova.

Because it's a side project, it won't matter that the user interface is non- standard/quirky.

</comment><comment><USER11> Go with Android.

1) The fee is less for publishing ($35 vs. $99) and you're guaranteed tobe able to publish.

2) You can use Eclipse or Android Studio (intellij) and not have to learn XCode.

3) If you didn't want to learn java, you could write your android app with python or use a wrapper and just use HTML/CSS/JavaScript.

<comment><USER12> You forgot the required $62/year for a PO Box since your address is published on your Play store page ready for easy Swatting, Pizzering, or other harassment from strangers you upset.

Also the $35 is one off, the $99 is per year. The $62 is per year also however.

</comment></comment><comment><USER13> If you can, do both. If it's just to learn though, i'd do whatever has the lowest barrier to entry for you. Which phone do you have yourself? Make it for that. Good luck!</comment>